Code management when customising Android - Android Q&A, Help & Troubleshooting

Hello,
I have a question about the best way to manage an Android software project that will involve modifying core Android code.
My question is not a normal "how to do this in Android", but rather, concerns the code management process and the build procedure. Has anyone any experience with this, or can point me somewhere?
We are starting a project to implement an audio application on Android phones, the various ARM architectural flavours. This will involve modifying and extending the C/C++ code in the Media Framework library, plus some supporting Java code. In other words, relative to the complete Android codebase, the amount of code that will be affected is quite small. We will need to support various Android versions and various phone manufacturers and models per manufacturer. Our development process concerns using the pure AOSP as a basis, and initially targeting the Google Nexus as a reference platform. After that, customisations needed for real-world phones will be done in cooperation with the phone manufacturers.
From a code management viewpoint, my idea was to maintain a git repository for our Media Framework files, that will be branched for each maintained version of Android. Separately, we will check out from the Google AOSP repository the code for each supported version of Android, and overlay/merge our Media Framework code onto this codebase. The resulting codebase for each version of Android will be built targeted to the range of Android phones that we support, initially the reference Google Nexus.
Some development approaches that come to mind:
- For each Android version, we could patch Android's Media Framework with our code, and then maintain the entire merged AOSP in a local git repository. This would be a huge undertaking, when branches are included, but would at least guarantee that the codebase is always up to date. Howoever, merging our code changes across difference Android versions would be difficult.
- Another option is to only maintain our Media Framework files in a local git repository, branched for each Android version. Before building a specific Android version,we could checkout the Android version from the Google repository (or keep it cached locally on our build system or on developers' machines) and then patch Android's Media Framework files with our files.
Many thanks,
polomora

Related

About custom kernels

This is about the toolchain kindly posted by chulri in http://forum.xda-developers.com/showthread.php?t=891056 . Since I'm apparently not allowed to post in the devel forum (grr), I'm posting this here.
Chulri's instructions work fine, and I've successfully compiled me a kernel with IPv6 support -- thanks chulri. Beware, though, if building userspace binaries -- this toolchain does not create portable Android binaries.
Apparently there are two sets of Linux libraries available on Gen8 devices. The libraries in /lib and /usr/lib depend on uClibc, while the libraries in /system/lib depend on the usual Android "bionic" libc.
The toolchain posted by chulri builds against uClibc; binaries built that way will most likely not work on other Android devices, although they might work on uClibc-based Linux distributions (e.g. OpenWRT). In order to build binaries portable across Android devices, you'll want to use the toolchain included in Google's "Android NDK" (see the file docs/STANDALONE-TOOLCHAIN.html if you don't want to use Google's somewhat idiosyncratic build system).
Since chulri's toolchain is based on uClibc, most Unix utilities build out of the box. Typically, you just need to do:
Code:
cross ./configure --host armel-unknown-linux
make
(A side note -- Archos' libc is compiled with no IPv6 support, just like their kernel.)
Google's toolchain is more tricky, since it uses a non-standard libc. I've been fairly successful with variants of the following command-line:
Code:
make CC=$NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc CFLAGS="--sysroot $NDK/platforms/android-5/arch-arm -Os -mthumb"
--jch
Wow does this ever seem appropriate for the development threads...
It sure does. Problem is you have to have ten posts before you can post in Dev sections. Real PITA for new users that aren't noobs.
Sent from my HTC Vision using XDA App
Moved to android development

[GPL SOURCE] GPL source code for the Android 4.0 / r14 SDK

kernel, platform, dev-tools, and "extra" source code!
here
to answer the most obvious question:
Jean-Baptiste Queru said:
Here are the GPL source files that match the 4.0 / r14 SDK.
Like we did for all Honeycomb release, this is NOT the full source tree for IceCreamSandwich, these are only the GPL parts that are in the SDK (along with a few associated files), and they're not enough to build the whole IceCreamSandwich for a device.
Click to expand...
Click to collapse
thanks for the link, but the code is useless - no UI libraries, no dalvik to boot JAR's,
no applications... still waiting until google releases the full sources in november
I agree it's mostly useless, but the kernel source at least provides the basic patches needed for the newer version.
the basic patches are for the emulator only.
we need drivers from LG for our hardware, at least a kernel dev like franco can port the drivers to the 3.0
tree, but its a lot of work ... and currently he didnt have a lot of time.

[LineageOS][Docker][CICD] LineageOS Build system served via Docker with OTA support

Lineage CICD Project
This is my personal effort given to you, the community, which spends a lot of hours to craft a fully-functional and perfectly tuned ROM for our beloved Smartphones!​
What is it?
This project aims to provide a Build system for Android Developers which will be able to build an Android ROM for a different set of Codenames given, automatically for you, ( by default ) every night. Not only built stock sources that are already available on LineageOS Github account, but feel free to build even your custom code thanks to the support of local_manifests/*.xml fully supported by this Docker.
Where can I find it
CICD
- Github: https://github.com/julianxhokaxhiu/docker-lineage-cicd
- Docker Hub: https://hub.docker.com/r/julianxhokaxhiu/docker-lineage-cicd/
OTA
- GIthub: https://github.com/julianxhokaxhiu/LineageOTA
- Docker Hub: https://hub.docker.com/r/julianxhokaxhiu/lineageota/
- XDA: https://forum.xda-developers.com/showthread.php?t=2636334
Why?
As you all remember the transition from CyanogenMod to LineageOS was not smooth. Even today we are not granted with Nightly Builds, but with Weekly, because of capacity issues on providing such an amazing plethora of supported Devices ROM ZIPs ready to be flashed.
Therefore this projects aims on providing an easy-to-use build system which may help you on providing a Ready-To-Flash ZIP at the end of each Build round.
How does it work?
This is a pre-packaged Docker system based on Debian, with all the dependencies in place to correctly build ( even in an optimized way ) any LineageOS codename ROM. A cronjob will take care to start the build script on the configured time ( by default 10:00 UTC ~= 02:00 PDT ), which then will take care to build every codename given with an environment variable to the Docker.
All you need from now on is just the Docker Engine installed on your favourite Linux distribution.
Bonus!
Of course the ZIP that will be produced needs to be transferred to the device in order to flash it. Such a boring task...what if we can automate it through OTA?
As you all know, my first big project I've ever started for XDA was the OTA Server which perfectly emulates all the required calls to make it working with ( old and deprecated now ) CyanogenMod ROMS, as well as with ( long life to ) LineageOS, right now, today!
All you need to do is to configure an Environment variable in the Docker to say where your OTA Server is located. The URL will the be added automatically for you inside the build.prop file as cm.updater.uri=$OTA_URL.
...but wait, there is more!
Since the OTA Server is written in PHP, you all know that is a headache to prepare the system to make it working. A lot of user complained in the original Thread that was difficult for them to understand how to setup it correctly, therefore a fully working autonomous Docker is there for you, ready to serve the OTA Layer for you built ROMs!
I want to use it right now!
I am pretty sure you want! The Docker has now been tested for a nearly a Month and I'm successfully installing my own builds for a couple of weeks on my devices ( really a great satisfaction! ).
If you want to run it as well, I suggest you to take a look at this Bash script that will run for you the Dockers, already talking to each other. Since the script has been studied to work on top of the "VPS Powered By Docker" project, I suggest you to take a look at it. Although nothing is preventing you to use it in your favourite way.
Requirements
See the detailed list on the project README.
What about License
All my projects are always developed with MIT license, which means feel free to do what you want with it. I don't really care if you do business with it, it was a great challenge for me reaching this autonomous entity to run, therefore I don't mind of possible outcomes of it. Although Issues are always welcome for improvements, if any found, of suggestion for a possible feature enhancements.
Future plans?
At the moment I have some ideas, which I may, or may not, be able to implement as I am not a professional Android Developer. Although some nice to have points are:
- Possibility to build ANY Android distro ( from AOSP to any fork of it )
- Possibility to have changelogs of every nightly build ( attached as *.txt and *.html format, next to the built ROM )
- Maybe a logo?
Thanks for Awesome Work
Thanks for awesome work.

[TWRP][Docker][CICD] Docker microservice for TWRP CICD

TWRP CICD Project
This is my personal effort given to you, the community, which spends a lot of hours to craft a fully-functional and perfectly tuned ROM for our beloved Smartphones!​
What is it?
This project aims to provide a Build system for Android Developers which will be able to build a TWRP recovery image for a different set of Codenames given, automatically for you, ( by default ) every night. Not only built stock sources that are already available on TWRP Github account, but feel free to build even your custom code thanks to the support of local_manifests/*.xml fully supported by this Docker.
Where can I find it
CICD
- Github: https://github.com/julianxhokaxhiu/docker-twrp-cicd
- Docker Hub: https://hub.docker.com/r/julianxhokaxhiu/docker-twrp-cicd
Why?
At the current status I find very time consuming the task to always setup the environment the right way to build a sporadic recovery for any kind of device, depending on the tree.
Therefore this projects aims on providing an easy-to-use build system which may help you on providing a Ready-To-Flash IMG at the end of each Build round. The same you would download from twrp.me website.
How does it work?
This is a pre-packaged Docker system based on Debian, with all the dependencies in place to correctly build ( even in an optimized way ) any TWRP codename image. A cronjob will take care to start the build script on the configured time ( by default 10:00 UTC ~= 02:00 PDT ), which then will take care to build every codename given with an environment variable to the Docker.
All you need from now on is just the Docker Engine installed on your favourite Linux distribution.
I want to use it right now!
I am pretty sure you want! The Docker has now been tested for a nearly a Month and I'm successfully installing my own builds for a couple of weeks on different devices ( really a great satisfaction! ).
If you want to run it as well, I suggest you to take a look at this Bash script that will run for you the Docker. Since the script has been studied to work on top of the "VPS Powered By Docker" project, I suggest you to take a look at it. Although nothing is preventing you to use it in your favourite way.
Requirements
See the detailed list on the project README.
What about License
All my projects are always developed with MIT license, which means feel free to do what you want with it. I don't really care if you do business with it, it was a great challenge for me reaching this autonomous entity to run, therefore I don't mind of possible outcomes of it. Although Issues are always welcome for improvements, if any found, of suggestion for a possible feature enhancements.
Enjoy!

How can I enable /dev/watchdog functionality when compiling Android from source?

I'm trying to compile Android for a dragonboard 410 clone, and would like to enable a firmware level functionality so that the device reboots if there is some kind of OS level failure.
I noticed on the Linux Github (Documentation/watchdog/watchdog-API.txt) that the Linux source has exactly what I'm trying to implement. (sorry, new user so can't post links)
I'm unfamiliar with compilation from source on Android, is there a compilation flag or option I can use to enable this functionality on Android?

Categories

Resources