We can also set different system properties for a specific product. A “package”, for this matter, can be an app, a system component, sounds, locales, fonts or even just a regular files that are copied to the final product. We can include only some of the packages in the system, or all of them, depending on the “flavor” we want our new ROM to be. PRODUCT - This part describes the set of modules to be included, among other configurations. A configuration name is structured this way: The lunch command can take the configuration name as an argument, or picked by the user from a list. In order to pick the desired configuration, we’ll use lunch. There are several devices we can build our new Android ROM for ( remember what ROM is?), with different feature combinations and build types that we can use. If you know otherwise - let me know, otherwise - I highly recommend this configuration regardless of AOSP work. From my experience, I can tell that I never ran into a problem. When running this command from a shell other than “bash”, you’ll get a warning that only bash is supported. Note: I’m using Mac OS with “ oh-my-zsh” and “zsh” as my default shell. To initialize your environment with those new functions and environment variables, you need to run the command: $ source /build/envsetup.sh The nice guys in Google brought us some nice utilities to help with that. Now that we have all the code locally, we need to get all those lines of code into a nice package we can eventually install on a device. The _repo _tool and the Manifest project goes hand-in-hand, managing the 200+ git repositories, all part of the AOSP. On the previous post, we got the AOSP code into our environment and learned how that process works.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |