I am newbie to ROM development. I have a Moto e 1st gen device sitting around. I wanted to give it another life. So I was trying to build Android Go from AOSP Q Beta 1 source code. I don't know how to add a product and how to configure it to build Android Go. Please help me to configure and build it.
To build a rom from scratch, you need the device trees, kernel source code(or pre-built image), vendor blobs and the required HALs. From your question I understand you don't have any device tree lying around for your device. First try to build roms like LineageOS using the existing trees for your device. Also the Q source code is not the real deal. It is only the master branch and the full source code will only be released once Q is announced.So as I said, try building roms like LineageOS first.
Related
How can I install a debug build of Android 5.0 AOSP on my Nexus Device? Where do I get the debug build? I tried Googling but still can't find step-by-step instructions to download and install debug build.
You would need to pull down AOSP in source form and build it for the desired Nexus target (assuming it is supported). Start here:
http://source.android.com/source/requirements.html
Once you are setup, look into the details of building for a specific device, found here:
http://source.android.com/source/running.html
Note that if you load your device with a custom image you'll be voiding any warranty, etc. Also, you probably don't want a full debug build, it will be very large and most likely not loadable on the device. You'll want an "eng" build, which has a reasonable amount of debug capability in place, even for system processes and frameworks.
Good luck!
Specific infos:
Devices: Nexus 7 (2013) & Nexus 4
Both using google_msm as a base (3.4.0)
As the time of writing the latest stable kernel from kernel.org is 3.19.1
It is possible to do minor updates (like 3.4.0 -> 3.4.106)
Is it possible taking the latest stable release from kernel.org as a base instead of directly pulling from google_msm for my devices and build upon it?
Are there some tools like diff/patch to detect the Android/device specific files and stuff them in in the correct folders without looking through each folder seperately? (Or at least prints it out, so i can do it manually)
I'm a kernel modder at best , so my experience is very low with the kernel itself, tough i'm willing to learn to archive this.
So after further digging around i found this:
http://www.linaro.org/blog/android-blog/androidization-of-linux-kernel/
I tried doing this with the repo below as a base, but failed miserably at git --rebase.
I've cloned https://android.googlesource.com/kernel/common.git/+/android-3.18 and will try building on that, as it is already an "Androidized" kernel. I think i'll just have to put in the chipset specific stuff, defconfigs and so on.
My only concern is that the chipset specific stuff will refuse to work with this, but i can't know for sure until i've actually tried and failed, so i'll do that.
If anyone can share some knowledge i'll be grateful.
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.
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'm aware of the android-x86 project and as far as the end result (bootable live/install iso), I am looking to do the same thing. The difference is, I'm looking to do this with the ice cream sandwich branch from android master repo. Ice cream sandwich adds full support for x86 hardware and even sports a build target specifically for running the OS in virtualbox. So my question is, is anyone aware of any documentation for building and deploying to that target?
Just in case it's not clear, I'm not just using the android-x86 project because they haven't yet put up a build for anything later than android 3.
Okay so I was going to just delete my question because a few minutes after posting it, I found a tutorial! So, I figured I'd share this info here rather than just deleting, since that's a bit of a waste. Here is a link, plus an excerpt from the tutorial in case the link is ever lost:
http://ricston.com/blog/?p=1705
The second approach gives you direct access to the latest Android
code. However, it’s barely documented due to the fact that previously
you couldn’t build ‘out of the box’ an Android VDI (Virtual Disk
Image) with the AOSP. To build the Android VDI and install it in your
VM, follow these steps:
Get the Android source code from the AOSP site and follow the online
instructions to setup the environment.
When you are ready to build the project, execute the following command to set the environment variables for Make: “lunch vbox_x86-eng”.
Run “make installer_vdi” to
build the project. Make will build the project and produce a VDI named
“installer.vdi” located in “out/target/product/vbox_x86″. This VDI
contains Android plus its installer.
Create a Linux VM and add the
“installer.vdi” as an extra HD to the VM.
Start the VM and press “F12”
during bootup.
Select the HD which represents the “installer.vdi”.
Choose the first option, that is, “Android Install to /dev/sda from
/dev/sdb”.
When installation is complete, enter the command “reboot”.
After that, you should be able to launch Android from your VM.
I want to expand on this approach and end up producing a live CD rather than a VDI so I'm going to post this answer as a community wiki so it can be expanded by myself and others in the future.
Edit Nov 26/11
The above method of building right from the source alone is lacking features like proper keyboard and mouse support. Here is a link to an article (in Japanese but you can use google translate) of an individual who has compile the ICS sources with added in keyboard, mouse and network support. http://d.hatena.ne.jp/td2sk/20111125/1322192772
The precompiled VDI disk can be downloaded from here:
http://kie.nu/26G