I followed official Google`s tutorial to build my own AOSP and succeeded in all steps: I have a "Pure AOSP version" running on a nexus emulator. https://source.android.com/source/building.html
The story is I have some rare device came with some Android version full of a pre-installed app's obviously I don't want. I want to port Pure AOSP to my device - without any improvements or new features (So, for example, I don`t want to know how to build CM git repo).
Is it working just add to my local above master branch correct files into /device/vendor/model and then under cwd of master branch execute $ . build/envsetup.sh ?
If so, what are the files and their content I need to put under /device/vendor/model? I found a lot of guides how to pull already existing tree of CM or something else (http://xda-university.com/as-a-developer/porting-aosp-roms-using-source-code) and including this Android device configuration for AOSP and looking on some git repo's of several devices, I tried to figure out the minimum complete set of files & their content but I didn't find a correlation. I think there must be the minimum complete set and there is programming reason for the existence of each file. And what I saw in existed git repo`s was this set + custom extras each developer added for his own reasons.
Aftermath How do I determine the Build name & Buildtype to execute $ lunch <Build name>-<Buildtype >?
How to integrate $ make otapackage in order to build the familiar one zip file to load via recovery like CWM?
This is following my previous post: Porting AOSP to specific hardware device, But here the questions are more specific.
Process of adding new device to AOSP:
First the device definition should be placed in device/vendor/model path. and then you should add AndroidProducts.mk file with COMMON_LUNCH_CHOICES which specify the name and the build type of your AOSP (Eng,userdebug,release) and PRODUCT_MAKEFILES which should point to you main device makefile.
What goes to device/vendor/model:
device/vendor/model contains the core configuration of the device itself such as Bluetooth configs, audio_policy configs, wpa_supplicant configs, device-tree, prebuilt hardware firmware or prebuilt images for boot or recovery. Also it contains The framework overlays that you can configure some of the framework parameter and for example decide the your android should have a navigation bar or what type of status bar you want. It also contains the SELinux policies that you can make rules for different processes, defines new contexts, and even ban some processes of running or having access to some resources. and at last it contains the makefiles that you can include what packages you need for you AOSP (aosp.mk) or what is you device configuration (BoardConfig.mk) for example what is the cpu architecture, gpu driver name or should it use hardware composer or does you system have wifi, bluetooth and if it has what is the address and the name of the required drivers. Also we have the init (in case that you want to add some additional changes to android boot process), fstab (describes the android partition and how should they be mounted) and ueventd and some udev rules that should be in this directory.
Look at the number 1.
For OTA update packages, first you need to generate the required keys that is essential for generating a zip for ota updates. if you are starting now , I suggest that you use fastboot. but if you want I put a link that shows how you can encrypt the required packages. when the encryption is done, you can generate your OTA image by this command:
img_from_target_files signed-target-files.zip signed-img.zip
OTA update guide: https://source.android.com/devices/tech/ota/sign_builds
I think what you are looking for are not OTA packages, but how to form the unified zip. OTA packages will have changes made after the system was installed once. My OTA package has ~500mb of files (payload) etc. This was Full Update. Incremental Updates are much smaller. However when I build a flashable package, I get ~2.6gb of files. Flashing varies device to device. QCom (Qualcomm) requires QFil Tool to flash the full system. Or you flash the individual images through fastboot. So I don't know how 4. works for you.
Looks like the original Answer was based on the poor documentation from Google. When it comes to AOSP, experience is must, documentation is never enough
Related
I downloaded android device open source from Samsung OSRC.
It was composed with Platform.tar.gz and Kernel.tar.gz
It seems to do with building AOSP, found mk files.
I'm curious whether it can be used(directly or indirectly) to build newer android version for device and whether I have to build new kernel based on this files.
Thank you.
If you want to build for a newer Android version, you do not need to build another kernel. Just use the kernel provided by Samsung for your device (or the prebuilt kernel from your phone).
When porting a device to a newer Android version you need to adjust the init configuration (init.rc files from your product configuration located in device/<vendor>/<your_device>), but not the kernel specific parts of your init.rc files.
You also need to add the hardware specific vendor binaries to your resulting flash image. Therefore you can extract these libraries from your device. Most of them are located in /system/vendor/lib, but there could be also some libraries in /system/lib and all subdirectories.
It is also possible that some vendor binaries does not work within another software stack. Possible reasons are incompatible HAL interfaces and incompatible libraries. The solution for these cases can be very different and should be evaluated individually.
If you are facing such issues you can have a look at the CyanogenMod sources for a hint. There you can find lots of ports. Best place to look is the product configuration of the particular device. You can also look into another of my answers regarding this topic.
I am going to buy the Nexus 5 when it is available in my country. I then want to make changes (mostly UI) to the Android source code and run it on my phone.
My question is: how do I fastest test the code I have modified? Do I need to compile and create a ROM and flash it after every change to my phone or may I use the emulator and "quick-build" to it?
To clarify: I will download the Android source code and modifiy it. I will change UI stuff so that it suits me. After that I would like to test what I have written, preferably in the device but the emulator is also feasible.
I want to test the Android platform changes. Because I modify the source code I have to create a ROM and flash it to the device as the Android system cannot be installed as an .apk.
What is the fastest way to test the changes? It would be annoying to have to create a ROM and flash it EACH time I make a change to the source code, for instance test that my new UI works accordingly.
Is there some way to do this faster?
It depends at what level you are doing changes. If you are doing frameworks/base/core changes then you can navigate to your frameworks/base/core portion of your AOSP project and do an incremental build by doing (ensure that you initialized your build environment: . build/envsetup.sh in the root of your AOSP source directory):
mm -B
This will build the component you are in, which will be framework's framework.jar/ext.jar/etc
After this compiles then you can do (Be on the lookout for Errors during compilation):
adb root;
adb remount;
adb sync;
adb shell stop;
adb shell start
This will update the framework jar file on the device and then you should be able to see your changes.
Note
This will ONLY work if your current build is the SAME as the AOSP code you are building, otherwise you will have to push the framework.jar file into the system/framework/ portion of your device (which requires root).
I think it's better to recompile the whole source code after the modification.
I suggest to use the AOSP instead of hacking the factory image, no ROM will be needed, just flush with ADB.
The first build will cause a lot of time and space, but the android build system will only build the modified code when rebuilding.
Note: GPS, Sensor are not functional by default, as third part device driver is not included in AOSP.
As you may know there are three ways to deploy a Qt application on Android :
Use Ministro service to install Qt
Deploy local Qt libraries to temporary directory
Bundle Qt libraries in APK
The first method takes about 30 seconds and it also needs to install an extra apk . Ministro.
The second takes about 1 minute for me ! And anytime I try to run the program Qt creator pushes Qt libraries to the device.
The third one makes the .apk file really big and again takes about 1 minute for me.
I think with this situation that's not reasonable to develop Android application using Qt. Is there a way to make the deploying process faster?
Almost a full year since the OP and things have not changed at all. Deployment of a 7 MB APK takes over minute and a half for a project that compiles in 5 seconds. The reason I am answering is not that the problem got resolved, but to offer an alternative solution.
I've implemented a "workaround" consisting of two applications that work in tandem - one on the PC and one on the device - I created this mostly to compile files remotely, but it turned out to be a much faster alternative for deployment as well. On the host create an application that launches compilation in a separate process, when done copy the product file over network to the device to deploy. Besides remote compilation this reduced the time to deploy to like 10 seconds, I can live with that.
(Not a complete and fully tested answer yet, but I'll update if I find out more …)
Option 1: Copy the changed libraries to a rooted device
A new build will most often result only in one changed file: your libAppName.so, the native library containing your application's code. At least in 2015, it was possible to simply copy over this library to the Android device, without having to re-build the APK package. This only works with rooted Android devices (note that all emulators are rooted by default).
Step by step, according to this blog article and updated with the paths as I found them on my device:
Run the cross-compilation step on your build host system. So just make or the equivalent in Qt Creator.
Copy the resulting libAppName.so to the rooted Android device:
adb push build/path/libAppName.so /data/app/com.example.appname/lib/arm
Restart the application on the Android device.
If that works, you might even be able to integrate it as a custom deployment step in Qt Creator.
I did not test this technique yet due to lack of a rooted device. But it should still work given that (1) rooted Android devices still allow to overwrite all files and (2) debug builds of APKs can still be installed without code signing, so overwriting a library in an APK without code signing should be possible.
Option 2: Desktop targets as a workaround
I found out by chance that Qt's multi-platform character can be used to avoid the slow Android deployment 80% of the time. You just set up another compilation target; under Qt Creator you'd add a target under "Projects → Build & Run", using a kit for "Device Type: Desktop".
Now when you want to test anything that is not Android-specific, test instead in the Desktop version. Building and starting that will only take a few seconds.
This approach is further supported by using a framework for convergent application development so that the same user interface is usable both in the desktop and mobile versions. KDE Kirigami and MauiKit are two libraries for this purpose that build on Qt. Documentation for getting started is a bit scarce, but for Kirigami I wrote an extensive README for the setup of an example application.
I have downloaded the android source code. And i want to make some modifications to the source code to embed some functionality which currently does not exist. But the problem here is that i am not able to understand how the source code is organised, what kind of files could be find where. So if someone could help me understand that it would be really helpful.
Here is short version of what you will find when you download the Android source. I will leave out some minor directories and dig deeper into a couple of the important ones. Basically what you will get (based on the current Ice Cream Sandwich release), in alphabetical order:
Bionic - the C-runtime for Android. Note that Android is not using glibc like most Linux distributions. Instead the c-library is called bionic and is based mostly on BSD-derived sources. In this folder you will find the source for the c-library, math and other core runtime libraries.
Bootable - boot and startup related code. Some of it is legacy, the fastboot protocol info could be interesting since it is implemented by boot loaders in a number of devices such as the Nexus ones.
Build - the build system implementation including all the core make file templates. An important file here is the envsetup.sh script that will help you a lot when working with the platform source. Running this script in a shell will enable commands to setup environment variables, build specific modules and grep in source code files.
Cts - the compatability tests. The test suite to ensure that a build complies with the Android specification.
Dalvik - the source code for the implementation of the Dalvik Virtual Machine
Development - projects related to development such as the source code for the sdk and ndk tools. Normally not a folder you touch when working with the platform for a target.
Device - product specific code for different devices. This is the place to find hardware modules for the different Nexus devices, build configurations and more.
External - contains source code for all external open source projects such as SQLite, Freetype and webkit.
Frameworks - this folder is essential to Android since it contains the sources for the framework. Here you will find the implementation of key services such as the System Server with the Package- and Activity managers. A lot of the mapping between the java application APIs and the native libraries is also done here.
Hardware - hardware related source code such as the Android hardware abstraction layer specification and implementation. This folder also contains the reference radio interface layer (to communicate with the modem side) implementation.
libcore - Apache Harmony.
libnativehelper - Helper functions for use with JNI.
(Kernel) - not part of the default source download but you can get access to this code either by downloading it manually or by adding the repository to the repo tool. Contains the sources for the Android version of the Linux kernel.
Out - the build output will be placed here after you run make. The folder structure is out/target/product/. In the default build for the emulator the output will be placed in out/target/product/generic. This is where you will find the images used by the emulator to start (or to be downloaded and flashed to a device if you are building for a hardware target).
Packages - contains the source code for the default applications such as contacts, calendar, browser.
Prebuilt - contains files that are distributed in binary form for convenience. Examples include the cross compilations toolchains for different development machines.
System - source code files for the core Android system. That is the minimal Linux system that is started before the Dalvik VM and any java based services are enabled. This includes the source code for the init process and the default init.rc script that provide the dynamic configuration of the platform
tools - Various IDE tools.
Beyond the above you also have the hidden .repo directory that contains the source for the repo utility. It also holds the manifest specifying what git repositories you want to track for this Android source project. If you have your own additions you could automatically track them by adding a local manifest here.
For modifications of the platform framework there are some instructions available in the device/sample folder of the source code tree. That will show you how to add APIs to Android without having to modify the core framework.
I am trying to get a specific package (Launcher2) from the google git repo and compile it. Planning on changing a few things and create a custom one.
After installing git i used this to get the source from the tag of the 2.2 sdk:
git clone https://android.googlesource.com/platform/packages/apps/Launcher2 launcher2
git checkout android-sdk-2.2_r2
After all done and the files exist, I am creating a new android project in eclipse and choosing the 2.2 target framework and marking the "use existing source". The project is opening but with many compilation errors like invalid imports and unrecognized fields and so on ...
It looks like the source I have does not match the framework.
What am I missing?
if you want to compile in Eclipse, you will not be able.
Because it uses internal classes (com.android.internal.*) and private APIs.
See Launcher 1 (until android 2.1) : http://code.google.com/p/android-launcher-for-sdk/
Otherwise, you can have a look on the source code of ADW Launcher 2 which is based on Launcher2. You will see the modification made to be compliant with the public APIs
Ahhh... But you do know if you have the entire repo and the device tree in place, that you can build just one package. Assume for a moment, that your environment is Linux based and that your device handset is a Samsung i9000 (Galaxy S), then in your source tree you would have device/samsung/galaxys, which contains proprietary libraries and extra code related only specifically to the hardware for the Samsung i9000.
Then its a matter of having to do this as a once-off operation -
. build/envsetup.sh
lunch
Pick Samsung Galaxy s from the lunch menu. This is the tricky bit in ensuring your device handset appears on the lunch menu!
make -jX
(Replace X with the appropriate number of cores your processor has)
Your entire system.img/boot.img would be deposited in out/target/product/samsung/galaxys after a couple of hours depending on how fast your machine/environment is.
Now, to build one package you simply enter this:
make Launcher2
Now you will have a new android app called Launcher.apk that will be deposited in out/target/product/samsung/galaxys/system/app directory.
How?
Simple, when after doing a 'lunch', and invoke this command
make modules > modules_list.txt
The resulting output will contain the names of modules in that file modules_list.txt, that can be built on the command line - modules in the context of the entire AOSP source tree, it can be a (static|shared) library, native executable or even Android Java app.
Now, do not bother cleaning out the entire out/ tree (even though that can swallow up a lot of space), leave that in there to speed up the build process of individual modules.
If you really really want to delete them, issue this:
make clean && make clobber
and the entire out/ directory is removed and gone for good.