Currently I'm using the the AOSP ROM Builder image on Amazon AWS to build Android.
The point is, I'm only interested in the external tool grxmlcompile that is built for the host (linux) in the path: aosp/out/host/linux-x86/bin
where the source is at aosp/external/srec/tools/grxmlcompile
I'm not very familiar with Linux and make files, hence my difficulty to get this going.
I would like to copy the source (if needed the whole tree) and build just this tool on another linux machine.
I can't find the make file I need to run to build just this part.
UPDATE:
Looks like make out/host/linux-x86/bin/grxmlcompile would do the job. I would still like to be able to port only the needed parts of the source tree to the build machine
cd to the top of your Android build source.
source build/envsetup.sh
cd external/srec/tools/grxmlcompile
mma
...or any directory, or sub-directory a makefile. From AOSP build/envsetup.sh
m: Makes from the top of the tree.
mm: Builds all of the modules in the current directory, but not their dependencies.
mmm: Builds all of the modules in the supplied directories, but not their dependencies.
To limit the modules being built use the syntax: mmm dir/:target1,target2.
mma: Builds all of the modules in the current directory, and their dependencies.
mmma: Builds all of the modules in the supplied directories, and their dependencies.
external/srec was removed from the platform/manifest after android-5.1.1_r4 tag. So later, if you are using a manifest such as revision 5, 6 or later, you may need to do git clone https://android.googlesource/platform/external/srec external/srec to include that directory.
Related
Is there a way to build an Android system app from AOSP without having to clone the entire code tree and having to build the entire OS?
Just being able to build the unmodified app from a Linux shell is sufficient, with any toolchain that will do the job. Being able to make modifications in an IDE (Eclipse or Android Studio) is not a requirement (a text editor will do for making changes).
The app in question is CarrierConfig. Most of the app is just assets, the code consists of just one single Java class (~400 lines of code), but with four internal dependencies not exposed through the SDK API:
android.annotation.Nullable
android.os.PersistableBundle.restoreFromXml(XmlPullParser)
android.telephony.TelephonyManager.from(Context)
android.telephony.TelephonyManager#getCarrierIdFromMccMnc(String)
These are what prevents me from simple adding a generic build.gradle and running it through the gradle toolchain. The build artifact is a simple APK file, with which I would then patch the system image.
So how would I build this app without needing the entire AOSP source code (just the actual dependencies, and dependencies of dependencies etc.)?
Not a complete answer (yet), but some snippets I was able to find out so far:
Downloading just individual projects from the source tree
This is what I have been able to piece together from various instructions—untested so far:
mkdir <dir>
cd <dir>
repo init -u <url> -b <branch>
repo sync <project-list>
Where
<dir> is a dir on your system where you are going to keep the source
<url> is the URL for your build, e.g.:
AOSP: https://android.googlesource.com/platform/manifest
LineageOS: https://github.com/LineageOS/android.git
<branch> is the branch to check out (omit -b to check out the master branch)
AOSP branches are found at https://source.android.com/setup/start/build-numbers#source-code-tags-and-builds
LineageOS branches are found at https://github.com/LineageOS/android/branches
<project-list> is a list of projects to fetch (if omitted, repo sync will fetch the entire source tree). Projects can be indicated either by their name or by their path within the source tree, separated with spaces.
(source 1, source 2, source 3, source 4)
Figuring out which repos you need can get tricky, and if your dependencies have further dependencies, this can become a time-comsuming process.
Also I haven’t figured out if the next step actually works with a source tree stripped down in this manner.
Building individual projects
If you just need to build a single project, you can use mmm for that:
. build/envsetup.sh
lunch
mmm path/to/the/project/
(source)
For a project, I am using Android gradle scripts with CMake, gradle plugin is version 3:0:0, CMake version 3.6. Both gradle and CMake files are pretty simple and uninteresting (just defining the files used - I can still copy-paste them as required).
I have the following project structure; basically a codebase producing a few tens of .so files (the native part for the Android packages that get packaged into an apk, thereby called 'Executables'), which all depend on the same shared library code (static libraries, thereby called 'Libraries'). The Library code is still (relatively) volatile, so I wish the Executables to have project-level dependencies on them, so that whenever the Executables are built, the Libraries are rebuilt on-demand every time their code is changed.
The structure looks like:
+ LibProjects/
---Bin/ (Originally empty)
---Lib1/CMakeLists.txt (+sources files, same level as the CMakeLists.txt)
...
---Lib10/CMakeLists.txt (same)
+ Executables/
---Executable1/CMakeLists.txt (source files here)
--------------/AndroidFiles/build.gradle (and other android project files)(points to the CMakeLists.txt)
...
---Executable40/CMakeLists.txt
The Libraries' CMakeLists redirect their output into the Bin folder using
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY {CMAKE_CURRENT_SOURCE_DIR}/../Bin/${ANDROID_ABI}/${LibraryName})
The executable's projects add dependencies on the libraries "as normal"
add_subdirectory(${PROJECTS_ROOT}/LibProjects/${LibraryName} ${PROJECTS_ROOT}/Framework/Bin/Android/${ANDROID_ABI}/${LibraryName})...
Everything almost works, in the sense that I can get sensible executables and the Executables trigger builds of the libraries.
The problem is that when building the executables sequentially, each one does NOT reuse the library project outputs of the other ones: When I build Executable1, it will build all libraries (normal) and then it will build itself. Afterwards, when I build Executable2, it will NOT reuse the libraries that were already built for Executable1, and so on - this effectively increases my build time by a factor of ~10.
I can find the output of the build of each library inside the /Bin folder as expected, but they are not reused across executables - there are no CMake "project files" (is this the correct term) in the bin folder, all of them get generated inside the executable build directory.
The problem I am trying to resolve is the build times stemming from the fact that each library gets rebuilt for each executable.
At the moment the solutions I am considering is to somehow instruct CMake to use the Bin folder (or another folder) as a working folder for each library in its own folder instead of with the executable, hoping that the gradle android plugin will be smart enough to then spot that neither the cmakefiles nor the object files need to be regenerated, and avoid the rebuild.
The restriction that I have is that I cannot restructure the codebase itself, and that each Executable must be buildable separately of the others - there is absolutely no possibility of a top-level CMake - each Executable should be able to be triggered on its own.
CMake can guess if the build is up-to-date by reading informations froms the current build directory.
When you run CMake manualy in Executables/<x> directory, cmake retrieve information from the build directory associated to Executable/<x> directory. It then check if the timestamp of the built file correspond to the last build performed in this build directory. If not, it rebuild. What happen is that: Lib1 library file is built after you build Executable1, then you run cmake in Executalbe2, it compares the timestamp of Lib1 target file, see that this file was not produced by this instance of the cmake build and then rebuild the lib. And so on.
So you have two options:
1- Either you build the library and install their target files in the bindirectory (using install cmake command and make install bash command for exemple). Then in the Executalbe<x>/CMakeLists you use find_library command instead of add_subdirectory.
2- Or you create a super project which has the following structure:
+ supper_project
---CMakeLists.txt #add_subdirectory(LibProjects/lib<x>)... add_subdirectory(Executables/Executalbe<x>)...
+ LibProjects/
---Bin/ (Originally empty)
---Lib1/CMakeLists.txt (+sources files, same level as the CMakeLists.txt)
...
---Lib10/CMakeLists.txt (same)
+ Executables/
---Executable1/CMakeLists.txt (source files here)
--------------/AndroidFiles/build.gradle (and other android project files)
(not any more:points to the CMakeLists.txt)
...
---Executable40/CMakeLists.txt
I managed to work around this problem - but in the end it was by working around rather than with CMake.
I removed the CMakeFile-level dependencies (add_subdirectory) and only left the libraries at the linking level (target_link_libraries Executable [the library files])
Afterwards, I created gradle scripts for each library and added dependencies to these scripts in each application gradle script, so that the building of the libraries gets triggered by gradle dependencies instead of CMake dependencies. It's slower than it would be if gradle could be avoided, but much faster than rebuilding every time, and the overhead is at least constant (a few seconds per project).
I think problem lies in the way you have defined your dependencies.
For each executable you are creating separate targets using add_subdirectory.
e.g. for executable 1 you have add_subdirectory(${PROJECTS_ROOT}/LibProjects/${Library1}) and for executable 2 also you have add_subdirectory(${PROJECTS_ROOT}/LibProjects/${Library1}), so cmake will create two separate targets for same library1 in each of the executable's subdirectory and thus it will create separate timestamp and cache files. That is why it looks that it is building the same library for multiple times, but in fact for cmake they are different targets.
To fix this you can include all libraries in top level CMakeLists.txt using add_subdirectory and them in each executable's CMakeLists.txt add the dependency using add_dependencies command.
I've synced the entire Android repo, and set up a build environment per the instructions here:
https://source.android.com/source/building
The build instructions seem to be assuming that you want to build the entire Android platform. I'm really interested in building a specific AOSP app, like contacts, SMS, camera, etc. I've seen mirrors of the stock app's code on GitHub, but there doesn't seem to be any build instructions within those, for example:
https://github.com/android/platform_packages_apps_contacts
https://github.com/android/platform_packages_apps_calendar
Is there a build guide for doing this? Am I stuck downloading, modifying, building this huge (100+GB) code set?
Just as you have 'mm' to build a certain target, you can also use 'mma' to build that target with its dependencies. For example:
$ mma Settings -j16
This will scan the project for the dependencies of the Settings app, and will afterward build the dependencies first before commencing the build of the Settings app.
here are compile and module-based compilation commands:
lunch: lunch <product_name>-<build_variant>
tapas: tapas [<App1> <App2> ...] [arm|x86|mips|armv5] [eng|userdebug|user]
croot: Changes directory to the top of the tree.
m: Makes from the top of the tree.
mm: Builds all of the modules in the current directory, but not their dependencies.
mmm: Builds all of the modules in the supplied directories, but not their dependencies.
To limit the modules being built use the syntax: mmm dir/:target1,target2
mma: Builds all of the modules in the current directory, and their dependencies.
mmma: Builds all of the modules in the supplied directories, and their dependencies.
cgrep: Greps on all local C/C++ files.
jgrep: Greps on all local Java files.
resgrep: Greps on all local res/*.xml files.
godir: Go to the directory containing a file.
you can look here for other and more build commands : https://source.android.com/setup/build/building
and here :https://elinux.org/Android_Build_System
And check "build/envsetup.sh" file's comments to see full list.
I'm building a PhoneGap app which needs to play AAC audio. It works well using the native WebView, but I would like to use Crosswalk on a build targeting APIs 16-20 because some CSS features in my app do not work at all on Android 4.x.
When I make a copy of the project to add Crosswalk Lite, I can see that the app works except for the <audio> element pointing to a AAC file. This is because Crosswalk does not ship with proprietary codecs by default.
The linked page says:
To build Crosswalk with these codecs, a developer must run the build
with the “must accept a EULA” switch turned on:
$ xwalk/gyp_xwalk -Dmediacodecs_EULA=1
Then build Crosswalk. The ffmpegsumo.dll or libffmpegsumo.so in
the build output directory will contain the proprietary codecs.
Refer to Crosswalk Build Instruction for more details.
However, I am adding Crosswalk using the suggested plug-in, thus I get pre-built libraries without proprietary codecs:
phonegap plugin add cordova-plugin-crosswalk-webview --variable XWALK_MODE="lite" --save
How can I integrate proprietary codecs in the Cordova Crosswalk plug-in?
I managed to understand the (convoluted) process of building everything. This answer deals with the process of compiling a custom build of the full Crosswalk (not the lite version).
Actually, I decided to finally use the standard build and replace AAC audio with MP3s, but I thought this answer could be useful for future reference.
Environment
I compiled Crosswalk in a Ubuntu 16.04 Docker container to avoid "polluting" my system and to ensure I had the right Linux version. The standard image is pretty barebones so I installed some dependencies. I also set up a shared folder to access the compiled files:
docker run -it -v /home/andrea/shared:/shared ubuntu:16.04 /bin/bash
apt update
apt install -y python git nano lsb-release sudo wget curl software-properties-common
export EDITOR=nano # life it too short to learn vi
Finally, it is necessary to add the multiverse repositories:
apt-add-repository multiverse
Note: this procedure needs a lot of space. Make sure to have at least 25GB of free space before continuing.
Requirements
Install the depot_tools as outlined in the documentation:
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH=$PATH:/path/to/depot_tools
Initialize a working directory with:
mkdir crosswalk-checkout
cd crosswalk-checkout
export XWALK_OS_ANDROID=1
gclient config --name src/xwalk https://github.com/crosswalk-project/crosswalk.git
Then edit the config file with nano .gclient and add the following line:
target_os = ['android']
Save the file.
Fetching the source
Attempt a first sync with:
gclient sync
This command will fail but it's OK. The instructions say:
Do not worry if gyp_xwalk fails due to missing dependencies; installing them is covered in a later section, after which you can run gyp_xwalk manually again.
Adjust the install-build-deps.sh file and then run it:
sed -si "s/msttcorefonts/ttf-mscorefonts-installer/g" src/build/install-build-deps.sh
sudo ./src/build/install-build-deps-android.sh
Run gclient sync again and wait until it finishes correctly.
Building
By inspecting the files src/xwalk/build/common.gypi and src/tools/mb/mb_config.pyl, we can see that we need to add ffmpeg_branding="Chrome" in the build arguments.
To prevent an error later on, install the development package related to libnotify:
sudo apt install libnotify-dev
Move to the src directory and open the configuration:
cd src/
gn args out/Default
Ensure the content is as follows:
import("//xwalk/build/android.gni")
target_os = "android"
is_debug = false
ffmpeg_branding = "Chrome"
use_sysroot = false
The parameters use_sysroot = false prevents yet another error. When saving the file, you should see something like this:
Waiting for editor on "/home/utente/crosswalk-checkout/src/out/Default/args.gn"...
Generating files...
Done. Wrote 6060 targets from 1003 files in 2416ms
Issue cd .. and run gclient sync again.
Finally, to build the core library do:
cd src/
ninja -C out/Default xwalk_core_library
This will build the library for ARM, producing an AAR file located at:
src/out/Default/xwalk_core_library.aar
Copy this file in a safe place.
Building for x86
Get back to the args with:
gn args out/Default
Add the following line:
target_cpu = "x86"
Save the file, run gclient sync again and then repeat the ninja command. Make a copy of the new AAR file which now contains the x86 libraries.
Using the AAR files
The standard Cordova Crosswalk plug-in uses a single AAR file with libraries for both platforms. This message by Raphael Kubo da Costa suggests how to produce this single archive:
AAR files are just zip files; given the only difference between the ARM
and x86 AAR files are the different shared libraries, you can use
something like zipmerge or anything that merges zip files (or even
extract everything into some directory and then create one new zip file)
to build one final, multi-architecture AAR archive.
Finally, to use the custom built AAR file in the Cordova plug-in, see How to change the Crosswalk version used by the Cordova Crosswalk Webview plugin.
I am working on an android source code which I have downloaded from source.android.com.
After a full build I went through this site http://elinux.org/Android_Build_System which explains the android build system.
When I make changes in external/webkit code and build it with
make -j4 libwebcore it compiles the corresponding file and updates the libwebcore.so, and it save me a lot of time.
The same thing is applied to applications and also for building apks.
The problem arises when I make changes in the framework and give the command as
make -j4 framework its not compiling the corresponding files.
Can any one help me!
The folder frameworks contains many things, you have to be more specific about telling make what to build.
For example I made a change in:
frameworks/base/cmds/input/src/com/android/commands/input/Input.java.
Now the corresponding Android.mk file is located in:
frameworks/base/cmds/input/Android.mk, which contains a line saying: LOCAL_MODULE := input.
Thus the module being build from the source is called input, so I call:
$ make input
Which rebuilds that specific module.
As a bonus info, you can use the mmm helper and you can specify the path of the module to build like this:
$ mmm frameworks/base/cmds/input
or using mm which just builds the module in you current working directory:
$ cd frameworks/base/cmds/input
$ mm
I normally use mmm as my preferred tool.
Update
Oh, I see you might be talking specifically about the module called framework
I just tried to modify: frameworks/base/core/java/android/app/Dialog.java, and do a: make framework.
This seems to recompile the framework just fine. Which file exactly are you making changes in before running make framework ?
In response to your comment
I just tried to modify frameworks/base/core/java/android/webkit/WebView.java. mmm frameworks/base as well as make framework works perfectly fine for me.
If it does not work for you, can you update your question with additional information about which android version you are building, which commands you are typing exactly, and the output your are seeing?
Here are fuller descriptions of mm, mmm, and other convenient functions provided by sourcing the build/envsetup.sh file:
Invoke . build/envsetup.sh from your shell to add the following functions to your environment:
lunch: lunch <product_name>-<build_variant>
tapas: tapas [<App1> <App2> ...] [arm|x86|mips|armv5] [eng|userdebug|user]
croot: Changes directory to the top of the tree.
m: Makes from the top of the tree.
mm: Builds all of the modules in the current directory, but not their dependencies.
mmm: Builds all of the modules in the supplied directories, but not their dependencies.
To limit the modules being built use the syntax: mmm dir/:target1,target2.
mma: Builds all of the modules in the current directory, and their dependencies.
mmma: Builds all of the modules in the supplied directories, and their dependencies.
cgrep: Greps on all local C/C++ files.
jgrep: Greps on all local Java files.
resgrep: Greps on all local res/*.xml files.
godir: Go to the directory containing a file.
Plese check build/envsetup.sh file's comments to see full list of functions.