Suppose I have an Android Project, and already compiled.
If I add an printk in kernel, and recompile make bootimage, it should be done quickly.
But Android Build System will still read bunch of makefiles, is there any way to skip this and just start compiling?
You can try using the same hack as here:
https://github.com/realdmitchell/condor-vendor-cm/blob/master/bootimage/Android.mk
This should allow you to use mmm make <path to bootimage dir> without parse all the makefiles in the tree
Related
I'm porting a project from NDK build to Android Studio.
Currently the project has a precompiled header attached (with NDK build), which speeds up compilation time a lot.
I'm looking for a way to add precompiled header (.pch) to my external native build within Android Studio project. I'm using CMake.
I am in the same situation and I have found several user-made script to do that.
I would recommend this one:
https://github.com/larsch/cmake-precompiled-header
In order to make it work for the latest ndk-tools which uses clang, copy paste the content of this pull request:
https://gist.github.com/leeor/316168500765cf51ae97
into the PrecompiledHeader.cmake file (replace everything in this file, except if you want to keep GCC/ MSVC compatibility, then just you will have to merge the two files which shouldn't be hard).
It should work, except some special CMAKE_CXX_FLAGS that triggers an error in the export_all_flags function, and that I don't know how to fix yet. I'll keep you updated with my progress.
I want to make some changes to LatinIME. I got the code from git repository-
git clone https://android.googlesource.com/platform/packages/inputmethods/LatinIME
But I don't know how to build the apk file from the code. If anyone has build the LatinIME from the code, can you please share instructions.
Specifically I want to know how to build the dictionary tools (I guess I would need ndk), how to build the native code (again I guess it would required ndk) and finally how to build the java code by using the lib file from native code.
I tried creating Android app project in eclipse (using existing code option) by giving root directory as LatinIME/java I was able to compile but since it didn't have libjni_latinime.so, it crashed. I then got the .so file from emulator and put it in the libs/armeabi-v7a folder. Now I get this exception:
10-15 12:54:55.289: E/AndroidRuntime(32253): FATAL EXCEPTION: InitializeBinaryDictionary
10-15 12:54:55.289: E/AndroidRuntime(32253): android.content.res.Resources$NotFoundException: File res/raw/main_en.dict from drawable resource ID #0x7f070003
I think I may have solved this...
Having encountered a similar problem in another project where resources were being unnecessarily compressed due to their file extension I renamed the dictionaries (.dict) to .jet - an extension excluded from compression. Voila, dictionaries are now working. Not sure how good of a resolution that is seeing as the dictionaries are now uncompressed but it's a step in the right direction at least?
So far i have customised the LatinIME many times for different projects. I never faced this problem.
But i never used eclipse to create apks. I downloaded whole AOSP code onto my machine and compiled the modified source with AOSP. And mm creates the apk file in out folder, and can be installed with adb install -r latinime.apk
Here is how to download AOSP :http://source.android.com/source/downloading.html
And here is how to compile it initially : http://source.android.com/source/initializing.html and http://xda-university.com/as-a-developer/getting-started-building-android-from-source
And the LatinIME can be found in <android roo>/packages/inputmethods/LatinIME, Modify the code ther and cd to the same path and run mm (you need to do source build/envisetup.sh and lunch full-eng done in same terminal before doing mm)
First some background. As also suggested by the other answer issue seems to be related of .dict files being compressed. For example you can see how official Android builds solve this in project's tests for LatinIME
# Do not compress dictionary files to mmap dict data runtime
LOCAL_AAPT_FLAGS += -0 .dict
A quick searching the web reveals that to day this kind of directive or instructing aapt from Eclipse isn't trivial. You would probably end up creating a build.xml in case you want to handle don't-compress-dicts case properly.
One nice suggestion is this answer/question on how to instruct aapt to not to compress certain files.
If you want to build this from official git link you provide, you'll end up building whole Android repo, which you can by following building-running instructions.
If using gradle, add this
android {
aaptOptions {
noCompress 'dict'
}
Can somebody help me write Android.mk for LibXtract or point me in correct directoin?
Here is source for lib - https://github.com/jamiebullock/LibXtract.git
Or mayby there is a way to use linux generated shared objects in Android?
Especially for bigger established projects, crafting Android.mk files is quite an effort. More so, if you are not familiar with Android NDK build architecture whose understanding requires digging deep into the documentation and Android NDK make files. I would suggest trying to use existing make files by setting CC to point to your NDK tool chain, and CFLAGS += -sysroot $(SYSROOT) where SYSROOT=${NDK_INSTALL_DIR}/platforms/android-<level>/arch-<arch>/ (depending on targeted Android API version and architecture). Even without knowing about your library, I would bet you should have good chance of success this way. Android NDK documentation (${NDK_INSTALL_DIR}/doc/STANDALONE-TOOLCHAIN.html) details the use of independent tool chain and also instructs how to create a standalone tool chain that will not require the use of -sysroot argument to xxx-gcc.
If you decide to use Android.mk instead, you might check existing projects -CSipSimple comes to my mind (PJSIP converted from standard form GNU make files).
Important is to create the shared objects using Android tool chains. It is possible to build them outside of your application source tree, and then just copy the shared objects into the package source libs/<architecture>/ directory.
Integration with your build system depends on details that are not known (including how smooth you desire this whole integration to be e.g. because of other people working with the same project). If you are creating an application from command line, the easiest would be to have GNU make file or shell script in the package root directory ensure libXtract.so and your application package is up-to-date by calling libXtract make file and ant to build and pack your Java application. If you are using ant there should be a way to specify using make to take care of libXtract.so. I am not sure if eclipse is completely relying on ant for building an application to know if this would be enough for enabling complete build by clicking mouse buttons from within eclipse, too.
The answer to this question says you could use cmake script to build Android.mk files - I have not tried this approach.
I wish to back port the Android RTP APIs introduced in version 3.1(Honeycomb) to earlier versions. I downloaded the source of version 4.0 and found that it these APIs had both java and native code. In order to build the native code with the NDK, certain shared libraries are required.
According the Android.mk file, these are libnativehelper, libcutils, libutils, and libmedia. Though the source of all of these are present in the source code, building them was difficult. Each required many other shared libraries. For eg, libmedia requires these shared libraries: libui, libcutils, libutils, libbinder, libsonivox, libicuuc, libexpat, libcamera_client, libstagefright_foundation, libgui and libdl.
So my question is, is there some way of obtaining the original 4 shared libs? Does it involve building the entire source?
Say I need to build a piece of native code which is going to use standard Android shared libraries such as libutils, libcutlis, libmedia. I would perform following steps:
Install AOSP repository with target version.
Add my source code to appropriate directories under ./frameworks/base. In your case it might be easier to create a separate folder and put proper Android.mk of course.
You might get compile errors if required functions from those standard shared libraries are not present in the previous version.
When you build the code as part of AOSP it will build required libraries and link them for you automatically.
P.S. To accomplish that you're better to use a Linux-based build host.
using cygwin terminal, build native part i.e. jni folder. To build using cygwin, goto jni folder using cygdrive command. Then type ndk-build. After successful completion, shared libraries i.e. .so files will be created in libs folder.
I can understand your problem, you can pull the libraries from /system/lib of device or emulator. But you need a system permission. But you can do it by installing application.
Otherwise build your source code on linux platfor. Building process is very easy, just using 2 or 3 command. First time it is needed long time to build. After that you need very short time to build, it will build only according to the timestamp of modified code.
Please have a look here
I am working on the contacts app from android open source project. My android version is 2.3.5_r1. And using mm to make the module, but the making speed is quite slow, so i doubt if there is a method to speed up the making.
PS:Actually if i compile this module in eclipse, i will speed up a litter because the auto build feature of eclipse. But i don't like work with eclipse so give it up.
For instance, I use the following command from the root folder of your Android project:
mmm frameworks/base snod -j4
And I think that this is the best choice. Try it but substitute frameworks/base with your project name (relative path where Android.mk is stored).
In order of least cost to you:
Don't make clean so much. Allow the makefile to determine what to rebuild.
Use CCACHE export USE_CCACHE=1. You're only likely to see the effects of CCACHE upon having rebuilt multiple times. If your project is large set a higher CCACHE size e.g. 10GB ${ANDROID_DIR}/prebuilt/linux-x86/ccache/ccache -M 10G
Get a better processor and run with higher -j parameter
1. Build module + dependencies
mmma is slower than mmm, as the former make sure all dependencies are met for the module, and if they are not it compiles them as well. So, initially instead of a full make command, build the dependencies concerning the module you are interested in using the following:
mmma -j4 adir/yourmoduledir
2. Build module
Now that dependencies have met, keep recompiling just the module you are interested in. Skipping check for dependencies saves precious time. The directory you are using though, might contain more than one compilation target. To compile a single target, use something like:
mmm -j4 adir/yourmoduledir:moduletargetname
Example
Build libart
Build library and all of its dependencies once:
mmma -j4 art/runtime
Modify libart's code and quickly build it:
mmm -j4 art/runtime:libart
You will get half compilation time in comparison to Yury's approach as for example the debugging flavor of libart (libartd) will be omitted altogether.
Further speedup?
You should of course enable caching as suggested by aultbot.
Also, depending on the modules you are interested, there might be compilation targets you might want to disable by digging up in the makefiles. For example libart is compiled for both the host and the target. If you modify a variable in the makefiles can force compilation just for one of the 2, saving you half of the time.
Additional info:
Checkout out the outdated build guide in aosp:
build/core/build-system.html.
N-Preview google is switching to a new build system that aims to speed up incremental builds. I hope the documentation gets updated as well.
I found that when I use my laptop ssh to my desktop computer and build module, I can build it very very fast. I don't know why.