I compiled the Cocos2d-js 'Hello World'-project for Android and try to run it on Genymotion (Android emulator on x86).
I already tried adding :
APP_ABI := armeabi armeabi-v7a x86
to Application.mk , which makes the apk 3 times bigger, but when I run the app in Genymotion it immediately says "HelloWorld has stopped".
The same apk runs fine on a real Android device.
Any ideas ?
UPDATE:
The sample JS-MoonWarriors runs fine on Genymotion (with ARM-translation installed), so I guess it has nothing to do with x86. The sample JS-Tests however does not work (same error '... has stopped').
Solved it with the help from the following link :
http://discuss.cocos2d-x.org/t/cocos2d-x-with-genymotion/9476/2
In the file Cocos2dxActivity.java is a function that checks if it runs on the default Android emulator.
Change this function to also include Genymotion (and Adobe VirtualBox) :
isEmulator = product.equals("sdk") ||
product.contains("_sdk") ||
product.contains("sdk_") ||
product.contains("vbox");
Also, you'll have to make sure that the ARM-translation package is installed in Genymotion, or use the APP_ABI trick in the question.
i Solved it too ... and there's two things you should do to make it work:
First search your cocos game project on a file named Cocos2dxActivity.java then open it with notepad and scroll down to the bottom of the file then you should find a static function with a line like this:
isEmulator = product.equals("sdk") || product.contains("_sdk") || product.contains("sdk_");
which needs to be changed to this:
isEmulator = product.equals("sdk") || product.contains("_sdk") || product.contains("sdk_") || product.contains("vbox");
Second search your cocos game project again for another file called Application.mk and like the usual open it with notepad and under these tow lines:
# Uncomment this line to compile to armeabi-v7a, your application will run faster but support less devices
#APP_ABI := armeabi-v7a
add another line just beneath them :
APP_ABI := armeabi x86
another thing you should consider is the line you just add should be exactly as i wrote it and if you just try this :
APP_ABI := Armeabi x86 (Wrong ... it wont work just because of the capital A)
and by the way i am using Cocos code IDE 1.2 to package my apk files with framework v3.7 and android-ndk-r10c And the SDK as the adt-bundle-windows-x86_64-20140702
and one more thing ... you have to install Genymotion-ARM-Translation in your emulator with Gapps in order for this to work.
PS: if you don't find any of the files then you need to recreate your project and with add native code to the project checked in.
Related
I have set the project to run QML with C++ having slots communication. Now I am stumbled with the message:
void QDeclarativeView::continueExecute()):
file:///data/data/org.qtproject.example.input/files/Input.qml: File not found
I searched around and checked a similar problem, thus I followed that suggestion, changing my project file as follows:
QT += qml quick sensors xml
QT += declarative
SOURCES += \
main.cpp
OTHER_FILES += \
Input.qml
HEADERS += \
Input.h
RESOURCES += \
Input.qrc
# Required for deployment (?) :
QML_FILES.source = qml
QML_FILES.target = .
DEPLOYMENTFOLDERS += QML_FILES
# Required for deployment too (?) :
include(qmlapplicationviewer/qmlapplicationviewer.pri)
qtcAddDeployment()
While adding this hack to the project file seems to work for Symbian and Harmattan, for Android the last two lines doesn't fix the problem, as the compiler gives the messages:
./input/qmlapplicationviewer/qmlapplicationviewer.pri:-1: error: No such file or directory
./input.pro:22: 'qtcAddDeployment' is not a recognized test function.
Even for Qt5 should we get worried about the target, even if when we defined the project we already set it for Android device?
So, could someone have any suggestion on how to get the QML deployed to Android device? Maybe some equivalent hack that will do the same magic that worked for Symbian but also could work for Android?
Try to downgrade your Android target from API 19 to 17. Apparently the API 19 is not working properly with Qt 5 for Android yet.
Using qtcAddDeployment and qmlapplicationviewer.pri might also solve your issue. But before going into that direction, you should have a close look in the article from Qt Blog on Android Deployment in Qt 5.2.
Even a simple code like this gives the error
string test= "hello";
string part = test.substr(2, 3);
Invalid arguments Candidates are: stlpmtx_std::basic_string,stlpmtx_std::allocator> substr(?, ?)
Even casting to size_t did not not help
string part = test.substr((size_t)2, (size_t)3);
But both pieces of code working when running it as a console application using gcc 4.6 on Linux.
But when using Androind NDK it gives me the error.
If I close the file in the editor and close Eclipse, and then open Eclipse and build the project it compiles. But if I have the file open it throws up the error.
I am using APP_STL:= stlport_static in the Application.mk make file
Yes I did include <string>
Edit: I just looked at the times of .so file, it seems to be compiling even though Eclipse is showing the errors.
I found the solution I need to have to have stlport system include folder in the Paths and Symbols section of project properties -> C/C++ General
path_To_NDK/sources/cxx-stl/system/include
I only had the
path_To_NDK/sources/cxx-stl/stlport/stlport
I am trying to use boost library with Android ndk in Eclipse with Windows. I tried to follow this tutorial
I am stuck in the step with "bjam" command in cygwin.
bjam --without-python --without-serialization toolset=gcc-android4.4.3 link=static runtime-link=static target-os=linux --stagedir=android
Error: bjam command not found.
What is bjam? Also I used the boost 1.53 along ndk r8e. Can someone help me with this please?
Android NDK is no longer dependent on Cygwin, so you can build Boost with the NDK from within Windows command prompt (cmd).
In order to make Boost.Build find the NDK, edit boost\tools\build\v2\user-config.jam file and append the following text:
import os ;
androidNDKRoot = C:/android-ndk-r8e ; # put the relevant path
using gcc : android :
$(androidNDKRoot)/toolchains/arm-linux-androideabi-4.7/prebuilt/windows/bin/arm-linux-androideabi-g++ :
<compileflags>--sysroot=$(androidNDKRoot)/platforms/android-9/arch-arm
<compileflags>-mthumb
<compileflags>-Os
<compileflags>-fno-strict-aliasing
<compileflags>-O2
<compileflags>-DNDEBUG
<compileflags>-g
<compileflags>-lstdc++
<compileflags>-I$(androidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.7/include
<compileflags>-I$(androidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.7/libs/armeabi/include
<compileflags>-D__GLIBC__
<compileflags>-D_GLIBCXX__PTHREADS
<compileflags>-D__arm__
<compileflags>-D_REENTRANT
<archiver>$(androidNDKRoot)/toolchains/arm-linux-androideabi-4.7/prebuilt/windows/bin/arm-linux-androideabi-ar
<ranlib>$(androidNDKRoot)/toolchains/arm-linux-androideabi-4.7/prebuilt/windows/bin/arm-linux-androideabi-ranlib
;
Certainly, instead of c:/android-ndk-r8e you have to put the right location of the NDK on your PC.
Besides, you can select more recent platform API, instead of android-9.
Also note that the NDK supplies several tool-chains, and the above settings point to gcc-4.7. If you prefer to build boost with some other tool-chain, change arm-linux-androideabi-4.7 to the relevant path.
After you've put the configuration in user-config.jam, open cmd, cd to the directory where Boost resides, and invoke bootstrap. Then invoke b2 like this (for example):
b2 --without-python --without-serialization threading=multi link=static runtime-link=static toolset=gcc-android target-os=linux threadapi=pthread --stagedir=android stage
UPDATE: As of 11/2015, older NDK toolchains seem to have issues with the newer Boost versions, causing compiler crash, so consider using a more recent compiler. To do this, just change every 4.7 occurrence in the above script to 4.9. Also, it's worth compiling with a more recent Android API (eg. andoroid-9 -> andoroid-16 or so).
I tried building i686-linux-android-gfortran using build-gcc.sh following this
(it's for androdindk-7b) but I get error about link.h. I added link.h from here, but it gives further more errors.
Has anyone tried enabling i686-linux-android-gfortran for x86 Android?
From https://groups.google.com/forum/#!msg/android-ndk/QR1qiN0jIpE/g0MHkhTd4YMJ as selalerer suggested. I didn't try this, so I'm posting as a community wiki for reference purposes.
Fortran for x86 Android
=================
The guide is based on this one, many thanks to Phil:
Compiling Android NDK with Objective-C-enabled gcc errors
1) Download and unpack Android NDK 'android-ndk-r8c', (the older -r8b NDK won't work due to missing link.h!):
wget http://dl.google.com/android/ndk/android-ndk-r8c-linux-x86.tar.bz2
2) Create somewhere a folder called 'toolchain-src' (e.g. inside the folder android-ndk-r8c),
'cd' to this new folder
3) Make sure to have git installed ('yum install git' or whatever..) and download
the toolchain sources:
git clone https://android.googlesource.com/toolchain/build.git
git clone https://android.googlesource.com/toolchain/gmp.git
git clone https://android.googlesource.com/toolchain/gdb.git
git clone https://android.googlesource.com/toolchain/mpc.git
git clone https://android.googlesource.com/toolchain/mpfr.git
git clone https://android.googlesource.com/toolchain/expat.git
4) Create the folder 'binutils', 'cd' to this directory, unpack
binutils-2.23 there:
wget ftp.gnu.org/gnu/binutils/binutils-2.23.tar.gz
tar -xvzf binutils-2.23.tar.gz
You should now have a folder toolchain-src/binutils/binutils-2.23
5) Change to folder toolchain-src/build, edit the Makefile.in, changing the line:
--with-gnu-as --with-gnu-ld --enable-languages=c,c++
to
--with-gnu-as --with-gnu-ld --enable-languages=c,c++,fortran
6) In the file android-ndk-r8c/build/tools/build-mingw64-toolchain.sh change the line:
var_append GCC_CONFIGURE_OPTIONS "--enable-languages=c,c++"
to
var_append GCC_CONFIGURE_OPTIONS "--enable-languages=c,c++,fortran"
7) In the file android-ndk-r8c/build/tools/build-gcc.sh, change the line:
EXTRA_CONFIG_FLAGS=$EXTRA_CONFIG_FLAGS" --disable-libquadmath --disable-plugin"
to
EXTRA_CONFIG_FLAGS=$EXTRA_CONFIG_FLAGS" --disable-libquadmath --disable-libquadmath-support --disable-plugin"
8) In the file android-ndk-r8c/build/tools/build-host-gcc.sh, change the line:
ARGS=$ARGS" --enable-languages=c,c++"
to
ARGS=$ARGS" --enable-languages=c,c++,fortran"
And change the line
ARGS=$ARGS" --disable-libquadmath --disable-plugin --disable-libitm --disable-bootstrap"
to
ARGS=$ARGS" --disable-libquadmath --disable-libquadmath-support --disable-plugin --disable-libitm --disable-bootstrap"
9) Build your new toolchain:
/your/path/to/android-ndk-r8c/build/tools/build-gcc.sh -j1 --gmp-version=5.0.5 --mpfr-version=2.4.2 --mpc-version=0.8.1 --binutils-version=2.23 --gdb-version=7.3.x /your/path/to/toolchain-src /your/path/to/android-ndk-r8c x86-4.7
(don't worry about messages like 'expr: warning: unportable BRE:')
10) And go down to your knees in front of the screen, praying to the Lord that somehow these
countless configure scripts doing checks that nobody needs, using an ugly shell language
that cooks your brain with indentation going from right to left, will somehow manage to
compile a zillion of far too small files (so that 10% of the time is spent on compilation
and 90% on starting up GCC), and after an hour of watching progress with
tail -F /tmp/ndk-YourUserName/build/toolchain/config.log
your toolchain will be magically ready. You'll find it in the android-ndk-r8c/toolchains folder.
11) Finally, 'cd' to the folder
'/your/path/to/android-ndk-r8c/toolchains/x86-4.7/prebuilt/linux-x86/i686-linux-android'
and run this command:
ln -s ../libexec libexec
Without this command, it may happen that g++ raises the error message
"g++: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found".
Using strace, I found that g++ looks in the wrong folder, but the link
above lets it find the file liblto_plugin.so nevertheless.
And here are a few lessons learned on the way, so that Google finds this page:
*) To speed up the compilation, you can remove the '-j1'. But only after you got
it to work once, since building in parallel on multiple CPU cores was reported to
cause additional troubles.
*) The error message "Link tests are not allowed after GCC_NO_EXECUTABLES" shows up
when linking fails for x86 (works for ARM). The reason is that GCC does not include
the proper ANDROID_STARTFILE_SPEC and ANDROID_ENDFILE_SPEC from
gcc-4.6.1/gcc/config/linux-android.h. GCC 4.6.1 only specifies them for ARM, but not
for i386, GCC 4.8.0 however does. The GCCs downloaded from Google also do,
so best use Google's GCC.
*) The error message "fatal error: link.h: No such file or directory" also happens
with Google's GCC, and apparently (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50877)
only when you enable additional languages like objc or fortran.
The bug thread is here: http://gcc.gnu.org/ml/gcc-bugs/2012-08/msg00494.html
MIPS has link.h in android-ndk-r8b/platforms/android-9/arch-mips/usr/include
In android-ndk-r8c, link.h is now also present in android-9/arch-x86/usr/include/link.h,
so this bug was fixed.
*) The error message "fatal error: quadmath_weak.h: No such file or directory":
It also happens with the latest gcc-4.8, so we can just continue using Googles GCC 4.7.
Google itself uses --disable-libquadmath, but we additionally need --disable-libquadmathsupport
(see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47648). So this needs to be added in
android-ndk-r8c/build/tools/build-gcc.sh
and
android-ndk-r8c/build/tools/build-host-gcc.sh
*) The error message "error: Pthreads are required to build libatomic"
Happens when building the ARM version of gcc-4.8 downloaded from gnu.org,
better stay with Google's GCCs.
*) The GCC that came with android-ndk-r8c didn't work for me (error message about
libstdc++.so.6 being too old), while the one in android-ndk-r8b worked
without problems. Since the android-ndk should support as many environments
as possible, I'm not sure why the Googlers decided to depend on a newer libstdc++,
but the good news are that building your own toolchain solves the issue.
*) If you get an error while compiling generic-morestack.c, then replace
#ifdef linux
// On Linux, the first two real time signals are used by the NPTL
with
#if defined(GLIBC) && defined(linux)
// On Linux, the first two real time signals are used by the NPTL
I've downloaded Android source code. Now I want to make it for my own device (LG GT540). I heard that you need to create some 'Device configuration' for that. Although several developers have already created device configurations for my device, but I want to create my own, just for learning.I saw a lot of files like BoardConfig.mk, AndroidProducts.mk, etc. But don't know what they do. Besides they contain a lot of configurations. Over that, there's not a good documentation for that.Can anyone experienced with Android porting and device configurations help me?
Right... So you want to build your own device tree, read on.
Disclaimer: this is by no means complete, and there will be omissions as have explained all this top of my head and copied pasted certain bits that I have here on my own device tree.
The device tree, for example, /device/lg/gt540would consist of the following make files:
Android.mk - this will tell the build system to include and to build sources specifically for your device. See below, for an example. This is dependant on the device and hardware, you could have libsensors, liblights, libcamera subdirectories under the example device tree, i.e. /device/lg/gt540/libsensors, /device/lg/gt540/liblights, /device/lg/gt540/libcamera etc.
AndroidBoard.mk - this is for the kernel, the build system uses that to drop the kernel image in place (more about this in a few minutes)
AndroidProducts.mk - specifies the appropriate device's make file, to use for building. i.e. /device/lg/gt540/device_gt540.mk, this is specific also.
device_xxxxx.mk - specifies the properties and extras to copy over into the final output, in this case, it could be for example, device_gt540.mk
BoardConfig.mk - This is the meat of it all, this is where compiler conditional flags are set, partition layouts, boot addresses, ramdisk size, and so on.
Lets peek into each of those to give a glance as to where it all fits in.
Android.mk:
ifeq ($(TARGET_BOOTLOADER_BOARD_NAME),xxxxx)
include $(call all-named-subdir-makefiles, recovery libsensors liblights libcamera ....)
endif
This is how the build will use that to build recovery, sensors, lights and camera (of course there will be more), its saying 'Yo Builder, go into each of the directories specified, and build the respective sources plskthxbai'
AndroidBoard.mk:
LOCAL_PATH := device/lg/gt540/
#
# Boot files
#
TARGET_PREBUILT_KERNEL := $(LOCAL_PATH)/kernel
file := $(INSTALLED_KERNEL_TARGET)
ALL_PREBUILT += $(file)
$(file): $(TARGET_PREBUILT_KERNEL) | $(ACP)
$(transform-prebuilt-to-target)
Now this, is telling the build system, to be able to drop this kernel into the out/target/product/lg/gt540 (notice the correlation with the device tree directory?)
AndroidProducts.mk:
PRODUCT_MAKEFILES := \
$(LOCAL_DIR)/device_gt540.mk
Its telling the build as in 'Yo Builder, read that device make file please and process it upon completion of build.'
*device_xxxxx.mk: (for this example, device_gt540.mk) *
PRODUCT_NAME := lg_gt540
PRODUCT_DEVICE := gt540
PRODUCT_MODEL := LG GT 540
PRODUCT_COPY_FILES += \
... specific ...
PRODUCT_PROPERTY_OVERRIDES := \
ro.com.android.dateformat=dd-MM-yyyy \
... more stuff ...
This is where all the specifics for the device such as drivers, proprietary libraries, supporting scripts specifically for the device, gets copied over to out/target/product/lg/gt540/system/ in this case. Notice how the overrides for the properties, these end up in the build.prop found in the root of the /system of the Android ROM.
BoardConfig.mk:
LOCAL_PATH:= $(call my-dir)
TARGET_NO_BOOTLOADER := true
TARGET_PREBUILT_KERNEL := device/lg/gt540/kernel
TARGET_PREBUILT_RECOVERY_KERNEL := device/lg/gt540/recovery_kernel
# This will vary from device!
TARGET_BOARD_PLATFORM := msm7k
TARGET_ARCH_VARIANT := armv6-vfp
TARGET_CPU_ABI := armeabi
TARGET_CPU_ABI := armeabi-v6l
TARGET_CPU_ABI2 := armeabi
# OpenGL drivers config file path
BOARD_EGL_CFG := device/lg/gt540/egl.cfg
# Dependant, not to be taken literally!
BOARD_GLOBAL_CFLAGS += -DHAVE_FM_RADIO
# Dependant, not to be taken literally!
BOARD_KERNEL_BASE := 0x02600000
# this will be device specific, and by doing cat /proc/mtd will give you the correct sizes
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00480000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00480000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x0cf80000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x0d020000
BOARD_FLASH_BLOCK_SIZE := 131072
That is an excerpt, notice how we specify kernel's base address, this is how the boot.img gets generated after compilation is done and yet again, gets dropped into out/target/product/lg/gt540/boot.img. Also, more importantly, we're telling the build system to use the target platform for cross-compiling the sources (*TARGET_BOARD_PLATFORM*/*TARGET_CPU_ABI*) There will be more information in there such as conditional flags to pass to the compiler, for an example. we specified the directive HAVE_FM_RADIO to tell it, when it comes to handling the source for the FM radio system, to conditionally compile parts of the source. Again, this is hardware specific and mileage will vary, also this applies to the address for boot. In a nutshell, this is saying 'Yo Builder, read the damn variables and remember them and apply them when cross-compiling those source files!'
Now that the internals of each of those Android build make-files are shown.
Now, onto the vendor/ part of it, in AOSP, simply, once again, correlation and corresponds with the device/ tree, as in continuing with this example, vendor/lg/gt540/ which gets picked up by the lunch. There's more make files in there but the general consensus is there's a directory called proprietary which contains the proprietary libs (due to close-source etc) that gets copied over. The copying over of the libraries gets specified in the file device-vendor-blobs.mk, in this case, gt540-vendor-blobs.mk.
When the magic happens by doing the following:
. build/envsetup.sh
This is reading in the entire entries found in each of the device/ subdirectories and "remembers them", so the build system knows what type of target is used etc.
When the . lunch gets invoked, a menu appears prompting to pick the device that is required to build. Now the last and final step to do the build...
make -j5 > buildlog.log 2>&1
I run multitail on another terminal and monitor the buildlog.log file to check and make sure its building.
This last step will depend on how many cores you have (n cores + 1 as a rule) and it takes a while to build, GB build takes 40mins on my laptop running Arch Linux 64bit, ICS build takes about 2hrs 30 mins. So mileage will vary on what type of horsepower your machine has.
When the build is done, a little bell goes off and at the bottom of the said log file, I see this:
Combining NOTICE files: out/target/product/xxxxx/obj/NOTICE.html
Target system fs image: out/target/product/xxxxx/obj/PACKAGING/systemimage_intermediates/system.img
Install system fs image: out/target/product/xxxxx/system.img
out/target/product/xxxx/system.img+ total size is 108776448
As matter of interest JBQ (Jean Baptiste Queru - the 'boss' for managing/distributing the source from Google), his build step is this...
make -j32
Yup! 32 cores! That..... is pretty powerful.
There is some information here: http://elinux.org/Android_Device
An excellent resource for anyone building Android for a device is here:
http://com.odroid.com/sigong/nf_file_board/nfile_board_view.php?bid=98
(A Practical Real-World Approach To Android Platform Development In ODROID)
Though some of the stuff in there is particular to the ODROID board, it still offers great insight into the inner workings of Android and the necessary customization for a new board.
If you're looking to get into the hardware side of things probably the single most informative resource I've found has been:
http://source.android.com/compatibility/overview.html
Read through the documentation they wrote for manufacturers looking to build android devices, it's the most thorough/complete reference you will find.