I built Chromium browser successfully with the instructions (https://www.chromium.org/developers/how-tos/android-build-instructions) and it works fine. The only problem is that the performance is horrible. I even tried to build it with the option "arm64" in args.gn:
target_os = "android"
target_cpu = "arm64"
is_debug = true
enable_incremental_javac = true
The file is located in /src/out/Default which is where I built the apk files with this command
ninja -C out/Default chrome_public_apk
The animations are laggy and webpages are loading awfully slow. Is there something I'm missing here?
You're building a debug binary, if you want a usable build set is_debug = false as that will enable release optimizations. This is enough to get acceptable performance though I think official builds are even more heavily optimized.
Related
I had to build a version of boost for Android using NDK r18b, I had a hardtime achieving this so I post Question+Answer here as it may help other persons.
Firstly, I tried https://github.com/moritz-wundke/Boost-for-Android, but this was unsuccessful, see How to build boost 1.69.0 for Android with NDK r18b using moritz-wundke/Boost-for-Android?.
Secondly, I tried https://github.com/dec1/Boost-for-Android, but this was unsuccessful too, see How to build boost 1.69.0 for Android with NDK r18b using dec1/Boost-for-Android?.
What are the steps to follow to achieve compilation of boost?
Actually, those scripts were designed for Linux, and they hardly work under Windows. Then, I started from scratch and could finally find the good config under Windows to achieve this. I basically checked how other libraries are compiled (I use QtCreator to deploy on Android, so the compilation window reported me how clang++ has to be invoked, so I write a user-config.jam based on that.
Here are the steps to follow to compile boost 1.68.0 for Android armeabiv7 and x86 using NDK r18b:
Download boost 1.68.0 from boost.org: https://www.boost.org/users/history/version_1_68_0.html
Apply moritz-wundke's patch, else it won't compile (thanks by the way). Take it from here: https://github.com/moritz-wundke/Boost-for-Android/tree/master/patches
Run bootstrap.bat (you'll need it to find a compiler, I have VS 2015 installed so it works just fine)
Then set some environment variables:
set ANDROIDNDKROOT=C:\Android\android-ndk-r18b (change this accordingly)
set NDKVER=r18b
set CLANGPATH=%ANDROIDNDKROOT%\toolchains\llvm\prebuilt\windows-x86_64\bin
Copy user-config.jam to boost folder tools/build/src:
import os ;
local AndroidNDKRoot = [ os.environ ANDROIDNDKROOT ] ;
local AndroidBinariesPath = [ os.environ CLANGPATH ] ;
using clang : armeabiv7a
:
$(AndroidBinariesPath)/clang++
:
<compileflags>-fexceptions
<compileflags>-frtti
<compileflags>-mthumb
<compileflags>-ffunction-sections
<compileflags>-funwind-tables
<compileflags>-fstack-protector-strong
<compileflags>-Wno-invalid-command-line-argument
<compileflags>-Wno-unused-command-line-argument
<compileflags>-no-canonical-prefixes
<compileflags>-I$(AndroidNDKRoot)/sources/cxx-stl/llvm-libc++/include
<compileflags>-I$(AndroidNDKRoot)/sources/cxx-stl/llvm-libc++abi/include
<compileflags>-I$(AndroidNDKRoot)/sources/android/support/include
<compileflags>-DANDROID
<compileflags>-Wa,--noexecstack
<compileflags>-Wformat
<compileflags>-Werror=format-security
<compileflags>-DNDEBUG
<compileflags>-D_REENTRANT
<compileflags>-O2
<compileflags>-gcc-toolchain
<compileflags>$(AndroidNDKRoot)/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64
<compileflags>-target
<compileflags>armv7-linux-androideabi
<compileflags>-march=armv7-a
<compileflags>-mfloat-abi=softfp
<compileflags>-mfpu=vfp
<compileflags>-fno-builtin-memmove
<compileflags>-fpic
<compileflags>-DHAVE_CONFIG_H
<compileflags>-fno-integrated-as
<compileflags>--sysroot
<compileflags>$(AndroidNDKRoot)/sysroot
<compileflags>-isystem
<compileflags>$(AndroidNDKRoot)/sysroot/usr/include/arm-linux-androideabi
<compileflags>-D__ANDROID_API__=18
<archiver>$(AndroidNDKRoot)/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/arm-linux-androideabi/bin/ar
<ranlib>$(AndroidNDKRoot)/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/arm-linux-androideabi/bin/ranlib
;
# --------------------------------------------------------------------
using clang : x86
:
$(AndroidBinariesPath)/clang++
:
<compileflags>-fexceptions
<compileflags>-frtti
<compileflags>-mthumb
<compileflags>-ffunction-sections
<compileflags>-funwind-tables
<compileflags>-fstack-protector-strong
<compileflags>-Wno-invalid-command-line-argument
<compileflags>-Wno-unused-command-line-argument
<compileflags>-no-canonical-prefixes
<compileflags>-I$(AndroidNDKRoot)/sources/cxx-stl/llvm-libc++/include
<compileflags>-I$(AndroidNDKRoot)/sources/cxx-stl/llvm-libc++abi/include
<compileflags>-I$(AndroidNDKRoot)/sources/android/support/include
<compileflags>-DANDROID
<compileflags>-Wa,--noexecstack
<compileflags>-Wformat
<compileflags>-Werror=format-security
<compileflags>-DNDEBUG
<compileflags>-D_REENTRANT
<compileflags>-O2
<compileflags>-gcc-toolchain
<compileflags>$(AndroidNDKRoot)/toolchains/x86-4.9/prebuilt/windows-x86_64
<compileflags>-target
<compileflags>i686-linux-android
<compileflags>-march=i686
<compileflags>-mfloat-abi=softfp
<compileflags>-mfpu=vfp
<compileflags>-fno-builtin-memmove
<compileflags>-fPIC
<compileflags>-mstackrealign
<compileflags>--sysroot
<compileflags>$(AndroidNDKRoot)/sysroot
<compileflags>-isystem
<compileflags>$(AndroidNDKRoot)/sysroot/usr/include/i686-linux-android
<compileflags>-D__ANDROID_API__=18
<archiver>$(AndroidNDKRoot)/toolchains/x86-4.9/prebuilt/windows-x86_64/i686-linux-android/bin/ar
<ranlib>$(AndroidNDKRoot)/toolchains/x86-4.9/prebuilt/windows-x86_64/i686-linux-android/bin/ranlib
;
Then, for armeabiv7-a:
Run bjam -q --without-math --without-context --without-coroutine --without-fiber --without-python architecture=arm --ignore-site-config -j4 target-os=android toolset=clang-armeabiv7a link=static threading=multi --layout=tagged --build-dir=build/arm/%NDKVER% --stagedir=stage_arm_%NDKVER% stage
Then, for x86:
Run bjam -q --without-math --without-context --without-coroutine --without-fiber --without-python architecture=arm --ignore-site-config -j4 target-os=android toolset=clang-armeabiv7a link=static threading=multi --layout=tagged --build-dir=build/arm/%NDKVER% --stagedir=stage_arm_%NDKVER% stage
Hopefully, the same steps can be followed to compile 1.69.0 (not tested)
Thanks for the helpful instructions.
moritz-wundke/Boost-for-Android is a great project and the original Boost-for-Android. However, the way it works, it requires constant maintenance in order to support each new combination of the ndk and boost as new versions come out (you can only build for the explicit versions the project has been configured to support). After a long time (boost version 1.53 -> 1.63, and ndk 10->16) where its seemed like the project was no longer being maintained, and my efforts to contact the maintainer were in vain, I decided to fork it, which is why dec1/Boost-for-Android came into existence.
It has the advantage that it does not, in general, need to be updated to support new versions of google's ndk, or boost. They generally build out of the box, or need rare adjustments (but I still test regularly to make sure).
Using dec1/Boost-for-Android is arguably also simpler (certainly than following your instructions above). You can build for any/all architectures (arm64-v8a, armeabi-v7a, x86, x86_64), in one go in a single line of code. And if you dont need a custom build you can simply download prebuilt binaries (boost 1.69.0, with ndk 19 and 18b, both dynamic and static are now also available) from here. There's also an example app to help you test your build.
Im pretty sure that it could be made to work on windows or mac too (possibly with less effort than you spent above), but its a lot easier to just use a virtual machine (eg the free virtualbox) to do the build, and copy the resulting binaries to windows if you really want to develop there.
Nonetheles, moritz-wundke/Boost-for-Android seems to have gotten a new influx of contributions of late, which is good news for everybody. And if you find it more suitable for building boost on windows (or any other platform) then thats great.
Good luck with your projects and thanks again for the insights.
GenyMotion's localhost IP address (10.0.3.2) is different from the Android emulator's localhost IP (10.0.2.2). Currently I have this in one of my source files:
//val LOCALHOST = "10.0.2.2" // Android emulator
val LOCALHOST = "10.0.3.2" // Genymotion
and whenever I switch between a Linux box and a Mac box and fetch the latest sources, I have to uncomment one and comment the other before rebuilding.
Unless someone can think of a better solution, I would like to have a Gradle task that writes out one of these values depending on the host OS, into a file that's included in the APK in such a way that I can access it from my Android app's runtime, and have that task run before assembleDebug when I build in Android Studio.
I suppose putting it in a resource would be easiest to access on the runtime side, but even a plain text file accessible to Class.getResourceAsStream() would be fine too.
I don't mind if it's included in the release apk, but I'd prefer that it just go into the debug ones.
I would also prefer that the file be generated in my build/ output directory, so that it's invisible to version control.
Any idea how to go about this?
There are much better solutions like finding the local IP address using getNetworkInterfaces(), but as you asked how to pass some information from gradle,
android {
productFlavors {
flavorGenymotion {
buildConfigField "String", "LOCALHOST", '"10.0.3.2"'
}
flavorEmulator {
buildConfigField "String", "LOCALHOST", '"10.0.2.2"'
}
}
...
which you can access as BuildConfig.LOCALHOST.
I followed this to compile Chromium ( Actually I need content_shell_apk):
https://www.chromium.org/developers/how-tos/android-build-instructions
Compilation of both ChromePublic.APK and ContentShell.apk succefull, but when I run them in my Android 4.2.2 device, I get this error:
https://paste2.org/nxFYVvtW
Cannot load library: soinfo_alloc(linker.cpp:287): too many libraries when loading "libEGL_mali.so"
I am searching for 2 days, and only thing I could find is this:
comments.gmane.org/gmane.comp.web.chromium.devel/43328
How should I get rid of this error, and compile official ContentShell.apk for my device?
The issue is resolved. Somehow, my out/Default directory was corrupted.
I removed that directory, and run GN configuration again:
gn args out/Default
At this point, to make sure that there are no any debug symbols included:
target_os = "android"
target_cpu = "arm"
is_debug = false
is_component_build = false
is_clang = true
symbol_level = 1
After that, generated filesize for ContentShell.apk is around 40Mbytes ( Jan.2017 ), and it runs perfectly on Android 4.2.2 .
To be able to modify user interface, someone can edit shell_view.xml which is at:
./content/shell/android/java/res/layout/shell_view.xml
There are also a few java files, which can be edited easily, and make your own browser for your custom android device :)
Many thanks to people at #chromium for IRC help.
Is there any way, at least temporarily, to tell ADT to leave BuildConfig.DEBUG as TRUE even for release builds?
At that point, you should just create your own constant like
public class MyConfig {
public static final boolean DEBUG = true;
}
BuildConfig really is meant to tell if it is a debug or production release.
Note that you can modify your own constant from outside the code. For example, on Linux or OSX:
#!/bin/bash
cat MyConfig.java | sed -e 's/DEBUG = true/DEBUG = false/g' > newMyConfig.java
mv newMyConfig.java myConfig.java
ant release
This simply rewrites the config via an outside source.
I was facing the same issue as everytime I was running the project as android application it used to open in debugger mode but then the problem was solved.
-If you are working in eclipse you must be using Java EE perspective
-Instead just select Java perspective.
-Clean your app.
-uninstall the app from the device.
-Restart your device (Just like that so that no cache is stored)
-Run your app.
The debugger mode won't show up this time. Copy the apk generated in your bin folder and try it out on other devices as well
For my thesis, I'm modifying the android framework and building the source (4.1.1 Jelly Bean).
I can do a full build, but because this is very time consuming (I'm developing on a ubuntu 12.04 64bit virtual machine) I'd like to build separate modules.
For example:
When doing changes to the location modules, it should be possible to just build the changed module, and make a new system image:
mmm frameworks/base
make snod
But this doesn't work. Every time I try to boot, the new system image won't boot because of:
I/dalvikvm( 1696): DexOpt: mismatch dep signature for '/system/framework/framework.odex'
After some research, I tried to disable dexpreopt with the enviroment variables
export $WITH_DEXPREOPT=false
and
export $DISABLE_DEXPREOPT=true
and doing a full rebuild with 'make installclean'. The full rebuild works, and the changes to the framework are present in the build. But after doing a new change, still 'mmm frameworks/base' and 'make snod' result in dexpreopt mismatch.
The build/core/makefile from 'make snod' also gives the warning: 'Warning: with dexpreopt enabled, you may need a full rebuild.', which comes from this line in the makefile:
ifeq (true,$(WITH_DEXPREOPT))
$(warning Warning: with dexpreopt enabled, you may need a full rebuild.)
endif
This leads me to believe the $WITH_DEXPREOPT variable isn't correctly set or read?
So far I haven't been able to get a bootable system image without doing a clean full rebuild. Is the procedure I follow the correct to disable dexpreopt, or are there any other ways to build separate modules after doing changes to the framework and getting a new system image?
Build target is 'full-eng'.
Apparently the WITH_DEXPREOPT environment variable is overwritten by an internal WITH_DEXPREOPT variable in
build/target/board/generic/BoardConfig.mk
Changing this to false, or according to the people at google groups, starting a make with:
make showcommands WITH_DEXPREOPT=false
does the trick. Building a specific module and making a new system image now results in a bootable build.
(source: https://groups.google.com/d/topic/android-building/vJCkg8Yq9Ic/discussion )