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.
Related
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
I have run android CTS test case for ics on custom board. AOSP had their own cts/ folder under android/ folder. I'm having two questions.
What is the use/role of cts/ in building and flashing android on board?
Why we download CTS from site to run cts test cases, instead of using source code's cts?
For your first question, CTS doesn't play any big roles in flashing android onto a device. It gets included with the build when you repo sync so it stays synced with your version of android.
As for why you download it off the site, there's 2 good reasons. One, most people who run or execute CTS are not interested in downloading, and building, an extremely large project just to make sure their device is compliant with that version of the android sdk.
Two, the CTS package you get off the site is what is going to be run by everyone, and not the CTS that gets built from your machine. If you create an AOSP fork, the the person who uses your ROM will still want to make sure that it is CTS compliant. They need to use the package from the site because they need to know it hasn't been tampered with. You could easily change CTS so your device passes your version of CTS, but that doesn't help anyone else.
I have been working with standard android for some time. Recently I have been building android sdk for windows and find some interesting things in Android build env. There is a command called lunch which can be used to list all available targets to build. However, it does not list sdk and its variants,even though they are valid options.
Does anyone know why is that the case?
Also can I build any specific module in Android sdk without building the whole sdk. (It could be a great help as I dont wanna build the whole sdk, if I gonna do a small change in one component.)
Thanks
Under the hood, lunch uses make, so if some pieces of SDK do not change, they won't be rebuilt.
My speculation about your first question: rebuilding SDK was never considered a major task of lunch. It is most often used to port or mod the system and produce an installable system image, and receive the ADK as by-product. Later, people realized that often (with root access to the device) you can iterate over one component without need to reinstall the whole system image.
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 downloaded the c4droid app for Android and am running commands through system();. I'm learning that somethings work while others don't. Most of the cool stuff don't work and this appears to be due to my user profile not being given the rights to execute such commands at the Linux OS level.
So tried another experiment. I got a special Gnu compiler for the arm processor and compiled a simple hello world app. Then I put on my phone and tried to execute it through the c4droid app like system("./myapp.bin"); . I got a permission denied message.
So I'm just trying to understand what I can do and what I can't do on my phone that paid good money for? Can I execute such a hello world app or not? Do I really need root access to execute an application I made? Is there a way to get my code to run by wrapping it in android/java code? Do I have to go through the Dalvikvm to get this to run?
I'm really looking for a way to do this without rooting it or downloading something like busybox and using su.
Many many different issues.
permission denied is one of the few error messages the primitive shell knows, and it's used for many other types of failures including not finding the requested command.
The toolbox suite is missing many typical unix commands. People sometimes install busybox as a more comprehensive supplement
Some of the things you may want to do will actually require permissions that the shell (or even more so, application user id) accounts do not have. Only on an emulator or engineering device does the adb shell run as root by default, though on a 'rooted' device you may be able to get to a root shell.
You do not need root access to run compiled code, however the code must have a suitable ABI, must have all it's library dependencies satisfied, and must be installed in a file with the executable flag, on a partition which is not mounted with non-executable flag. Some of the issues you face there are glibc (or other) vs Android's bionic libc. Executable scratch directories vary by android version, though the private storage area of an app is an option if the app sets the file to world readable and executable.
The usual (and only "recommended") means of running native code is to build it as a shared library linked against android's Bionic libc, and call into it from a dalvik/java app using JNI.