Building for Android

(Difference between revisions)
Jump to: navigation, search
m
m (Troubleshooting Stellarium: and info on the log file paths)
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
The build instructions should differ only minimally between operating systems.
 
The build instructions should differ only minimally between operating systems.
  
Note that the Android emulator lacks OpenGL ES 2 support and will crash very quickly. You '''must''' do your testing on an actual Android device.
+
The Android SDK Platform / Emulator image for '''API 15''' is the earliest that supports OpenGL ES 2 (it also supports hardware acceleration using the host OS' GPU, which is nice). Prior SDKs will '''not''' work; to test with earlier versions of Android OS, you must use a physical device. Necessitas' SDK is currently out-of-date and doesn't have API Level 15, so you'll need to download it separately if you do want to use emulation.
  
 
== Prerequisites ==
 
== Prerequisites ==
Line 7: Line 7:
 
=== All ===
 
=== All ===
 
#[https://sourceforge.net/p/necessitas/home/necessitas/ Necessitas] (the Qt port for Android). The necessitas package includes the Android SDK and NDK, QtCreator, and the Qt libraries
 
#[https://sourceforge.net/p/necessitas/home/necessitas/ Necessitas] (the Qt port for Android). The necessitas package includes the Android SDK and NDK, QtCreator, and the Qt libraries
#*API 11 is the current target, so you may want to install that (it may be wise for us to target 10 or an earlier one, however); if using another target, be sure to comment out the bits of the necessitas Java code that aren't applicable (they're prefixed by //@ANDROID-XX; it looks like necessitas QtCreator is supposed to treat these as preprocessor directives)
+
#*API 8 is the current target, so be sure it's installed (the installer checks it be default); this is the lowest API level that support Open GL ES 2
 
#[http://www.oracle.com/technetwork/java/javase/downloads/index.html JDK 6]. Not JRE, not JDK 7
 
#[http://www.oracle.com/technetwork/java/javase/downloads/index.html JDK 6]. Not JRE, not JDK 7
 
#*If you have JRE installed, the JAVA_HOME environment variable may be pointing at that instead of the JDK; you need this to point to the JDK root directory for <code>ant</code> to work properly
 
#*If you have JRE installed, the JAVA_HOME environment variable may be pointing at that instead of the JDK; you need this to point to the JDK root directory for <code>ant</code> to work properly
Line 62: Line 62:
 
* BUILD_STATIC_PLUGINS
 
* BUILD_STATIC_PLUGINS
 
** Currently should be set to 0 as not all plugins support OpenGL ES2
 
** Currently should be set to 0 as not all plugins support OpenGL ES2
* EXTERNAL_GUI_SRC_PATH
 
** "../../plugins/MobileGui"
 
 
* GUI_MODE
 
* GUI_MODE
** External
+
** Mobile
 
** You can also use <code>Desktop</code> to use the Desktop UI, if you so choose. The Mobile GUI is a work in progress.
 
** You can also use <code>Desktop</code> to use the Desktop UI, if you so choose. The Mobile GUI is a work in progress.
 
* NECESSITAS_QT_ROOT
 
* NECESSITAS_QT_ROOT
Line 71: Line 69:
 
* ARM_TARGET
 
* ARM_TARGET
 
** "armeabi-v7a", "armeabi-v7a with NEON", "armeabi-v7a with VFPV3", or "armeabi"
 
** "armeabi-v7a", "armeabi-v7a with NEON", "armeabi-v7a with VFPV3", or "armeabi"
*** armeabi is the slowest and most compatible
+
*** armeabi is the slowest and most compatible (ARMv5 and greater)
*** armeabi-v7a is faster, and will work on most devices released in the past few years, and maybe all devices that are even capable of running Stellarium
+
*** armeabi-v7a is faster, and will work on most devices released in the past few years, and maybe all devices that are even capable of running Stellarium (ARMv7 and greater)
*** "armeabi-v7a with NEON" uses specific optimizations for the NEON vpu and is even faster, but only works on devices with a NEON (all Cortex A8s and ''most'' Cortex A9s)
+
*** "armeabi-v7a with VFPV3" enables VFPV3-D16 support, which ''should'' be compatible with every ARMv7a device. We may want to test this to see if that's true and whether there's a performance benefit
*** "armeabi-v7a with VFPV3" is similar, but for VFPV3. Works on Tegra devices.
+
*** "armeabi-v7a with NEON" enables NEON and VFPV3 instructions. NEON is a SIMD instruction set that must be specifically programmed for (there is a compiler option to auto-vectorize code to work with NEON, but that would completely rule out compatibility with devices that don't have NEON, and may have negligible benefit [http://wiki.debian.org/ArmHardFloatPort/VfpComparison#NEON])
 +
** I'm thinking the best idea will be compile "armeabi" and "armeabi-v7 with VFPV3", as this should allow pretty good compatibility. NDK allows libraries for different EABIs to coexist in the same package, and will choose the appropriate one for the device.
 
* ANDROID_API_LEVEL
 
* ANDROID_API_LEVEL
 
** leave it at default (android-8); this is the lowest API we can use, so using this allows the greatest compatibility. Because we're using Qt, it's unlikely we'll need the extra features the higher levels give us
 
** leave it at default (android-8); this is the lowest API we can use, so using this allows the greatest compatibility. Because we're using Qt, it's unlikely we'll need the extra features the higher levels give us
Line 97: Line 96:
 
  make run_apk
 
  make run_apk
  
== Troubleshooting ==
+
== Want to contribute, or having problems building? ==
  
If something goes wrong: The log file will be present at <code>/data/data/org.stellarium.stellarium/files/.stellarium/log.txt</code> or ''possibly'' at <code>/sdcard/stellarium/log.txt</code>. This will hopefully have information on what happened.
+
See: [[Android_port#Communication]]. Pop into IRC and let me know, or toss out an email to the mailing list.
 +
 
 +
== Troubleshooting Stellarium ==
 +
 
 +
If something goes wrong: The log file will be present at <code>/data/data/org.stellarium.stellarium/files/.stellarium/log.txt</code> (you can't view this on most devices without root) or ''possibly'' at <code>/sdcard/stellarium/log.txt</code> (will eventually change it so it ''always'' ends up here to avoid the root requirement). This will hopefully have information on what happened.
  
 
If it crashed before creating the log, or if the log doesn't contain anything useful, try running logcat through adb on your PC while you run the app on the device:
 
If it crashed before creating the log, or if the log doesn't contain anything useful, try running logcat through adb on your PC while you run the app on the device:
Line 110: Line 113:
  
 
=== Debug with gdb ===
 
=== Debug with gdb ===
(should write our own version of the ndk-gdb script to automate some of this)
+
('''Note''': there's now an ndk-debug.sh script in <code>stellarium/android/util</code> which handles most of this; I'll have to remember to rewrite this section)
  
 
If you need to debug as soon as the native code starts, import the project into Eclipse as described below, and set a breakpoint right before the necessitas code starts up the native side of the app. This line in <code>QtActivity.java</code> should do the trick:
 
If you need to debug as soon as the native code starts, import the project into Eclipse as described below, and set a breakpoint right before the necessitas code starts up the native side of the app. This line in <code>QtActivity.java</code> should do the trick:
Line 163: Line 166:
  
 
=== Debug with QtCreator ===
 
=== Debug with QtCreator ===
I haven't the foggiest. If anyone wants to investigate this, please go right ahead :)
 
  
 
==== To import the project into QtCreator ====
 
==== To import the project into QtCreator ====
Line 175: Line 177:
 
To get it to build, deploy, and run the code, you can just add build commands to the project as described above (<code>make install</code>, ...)
 
To get it to build, deploy, and run the code, you can just add build commands to the project as described above (<code>make install</code>, ...)
  
To have it actually debug the code ('''I haven't actually tried this yet'''), follow the gdb instructions but stop before the step where it instructs you to start gdb. In QtCreator, ''Debug -> Start Debugging -> Start and Attach to Remote Application''. Choose the correct gdb as your debugger, the app_process you grabbed as the executable, and set everything else up correctly.
+
==== Debugging ====
 +
 
 +
To have it actually debug the code is not straight-forward. You need to 'trick' Necessitas' QtCreator into working for you, and even then it probably won't work well:
 +
* create an empty Android project
 +
* clear out all of the build steps, but leave the deploy/running/debugging steps
 +
* copy in the binaries you built using the project you imported above, or symlink to the build directory or something
 +
* run it (using an actual device ''or'' and Android-15 target)
  
 
== Debug (Java) ==
 
== Debug (Java) ==

Revision as of 08:58, 22 April 2012

The build instructions should differ only minimally between operating systems.

The Android SDK Platform / Emulator image for API 15 is the earliest that supports OpenGL ES 2 (it also supports hardware acceleration using the host OS' GPU, which is nice). Prior SDKs will not work; to test with earlier versions of Android OS, you must use a physical device. Necessitas' SDK is currently out-of-date and doesn't have API Level 15, so you'll need to download it separately if you do want to use emulation.

Contents

Prerequisites

All

  1. Necessitas (the Qt port for Android). The necessitas package includes the Android SDK and NDK, QtCreator, and the Qt libraries
    • API 8 is the current target, so be sure it's installed (the installer checks it be default); this is the lowest API level that support Open GL ES 2
  2. JDK 6. Not JRE, not JDK 7
    • If you have JRE installed, the JAVA_HOME environment variable may be pointing at that instead of the JDK; you need this to point to the JDK root directory for ant to work properly

Linux

Through your distro's package manager, install:

  1. cmake (>= 2.8 is required)
  2. bazaar

OS X

  1. cmake
  2. MacPorts

Use MacPorts to install Bazaar. In a terminal window:

$ sudo port install bzr

Windows

  1. cmake
  2. bazaar (you'll likely want to check TortoiseBzr in the installer)
  3. MinGW/MSYS (be sure you check "MSYS shell environment" in in the installer)

Sync to experimental Android branch

The code currently resides in a personal branch.

bzr checkout lp:~brady.brenot/stellarium/android-port

More instructions for using Bazaar and Launchpad can be found in the Bazaar and Launchpad documentation.

Build

Configure

Create a subdirectory builds inside the directory where you synced to, and another subdirectory android inside that, so that you've got

stellarium/builds/android/

inside the builds/android directory, you'll want to run cmake, passing in the path to the Android toolchain so that it sets up for cross-compiling instead of compiling Stellarium for your own system. You also need to export an environment variable for the location of the NDK. The following commands will do that (replace the path in the export with the path of the ndk on your system):

export ANDROID_NDK=/path/to/necessitas/android-ndk-r6b
cmake -DCMAKE_TOOLCHAIN_FILE=../../android/android.toolchain.cmake ../..

But cmake will fail. The error message may mention something that's not in your PATH. Follow the onscreen instructions. To add to your path (temporarily; doing it permanently varies according to the OS), use the following command in the terminal window:

export PATH=/path/to/some/directory:$PATH

Otherwise, the problem is that you need to configure cmake properly; the default values are for paths on my own system, you'll need to configure them. To configure cmake, either run

ccmake

in place of cmake in the above command, or edit the CMakeCache.txt file directly in any text editor. The most important Android-specific parameters are (some will be set by default unless you first built in that directory without the toolchain):

  • OPENGL_MODE
    • Set to ES2 for Android devices
  • BUILD_STATIC_PLUGINS
    • Currently should be set to 0 as not all plugins support OpenGL ES2
  • GUI_MODE
    • Mobile
    • You can also use Desktop to use the Desktop UI, if you so choose. The Mobile GUI is a work in progress.
  • NECESSITAS_QT_ROOT
    • Set this to the path to necessitas' Qt libraries; on Windows, this is normally necessitas/Android/Qt/480
  • ARM_TARGET
    • "armeabi-v7a", "armeabi-v7a with NEON", "armeabi-v7a with VFPV3", or "armeabi"
      • armeabi is the slowest and most compatible (ARMv5 and greater)
      • armeabi-v7a is faster, and will work on most devices released in the past few years, and maybe all devices that are even capable of running Stellarium (ARMv7 and greater)
      • "armeabi-v7a with VFPV3" enables VFPV3-D16 support, which should be compatible with every ARMv7a device. We may want to test this to see if that's true and whether there's a performance benefit
      • "armeabi-v7a with NEON" enables NEON and VFPV3 instructions. NEON is a SIMD instruction set that must be specifically programmed for (there is a compiler option to auto-vectorize code to work with NEON, but that would completely rule out compatibility with devices that don't have NEON, and may have negligible benefit [1])
    • I'm thinking the best idea will be compile "armeabi" and "armeabi-v7 with VFPV3", as this should allow pretty good compatibility. NDK allows libraries for different EABIs to coexist in the same package, and will choose the appropriate one for the device.
  • ANDROID_API_LEVEL
    • leave it at default (android-8); this is the lowest API we can use, so using this allows the greatest compatibility. Because we're using Qt, it's unlikely we'll need the extra features the higher levels give us

Build and deploy

Once all the parameters are set up, run cmake again. It should succeed this time. Now, we want to build a debug apk without assets (see Android port; even if you wanted to include assets in the apk, they can't currently be used). Run:

make install
make build_apk_debug_no_assets

This will create the apk.

Copy builds/android/Stellarium-apk/share/stellarium to the root of your device's external storage (i.e. to /sdcard/stellarium). If external storage isn't at /sdcard on the device, you need to create a symlink to wherever external storage is at. If you rebuild Stellarium but don't change the assets or translation files, you won't need to recopy this directory; otherwise, you will.

To install the APK, either copy it to the device and install, or:

make deploy_debug_apk

And to run it, either hit the icon (it's currently a Q without a label; this is owing to lazyness, the fix isn't difficult), or run

make run_apk

Want to contribute, or having problems building?

See: Android_port#Communication. Pop into IRC and let me know, or toss out an email to the mailing list.

Troubleshooting Stellarium

If something goes wrong: The log file will be present at /data/data/org.stellarium.stellarium/files/.stellarium/log.txt (you can't view this on most devices without root) or possibly at /sdcard/stellarium/log.txt (will eventually change it so it always ends up here to avoid the root requirement). This will hopefully have information on what happened.

If it crashed before creating the log, or if the log doesn't contain anything useful, try running logcat through adb on your PC while you run the app on the device:

adb logcat

If that doesn't help, it's time for debugging:

Debug (C++)

Debug with gdb

(Note: there's now an ndk-debug.sh script in stellarium/android/util which handles most of this; I'll have to remember to rewrite this section)

If you need to debug as soon as the native code starts, import the project into Eclipse as described below, and set a breakpoint right before the necessitas code starts up the native side of the app. This line in QtActivity.java should do the trick:

QtApplication.setQtActivityDelegate(qtLoader);

With the device attached to adb (test with adb devices):

Find the process ID for Stellarium:

adb shell ps | grep stellarium

Then attach gdbserver to it:

adb shell gdbserver :5039 --attach pid

Have ADB forward that port from the device:

adb forward tcp:5039 tcp:5039

Pull the app process off the device; this process starts and runs Android apps, so it's the process you're going to be debugging. gdb needs this.

Windows Note: MinGW will interpret the paths in the pull commands below as Windows paths and passes them to adb accordingly (/system/bin/app_process becomes C:\system\bin\app_process). They're supposed to be paths on the Android device though, not your system. Either use cmd, or type the paths as //system/bin/app_process

adb pull /system/bin/app_process

Pull libc.so as well, and maybe any Qt libs you want:

adb pull /system/lib/libc.so
adb pull /data/data/org.kde.necessitas.ministro/files/qt/lib/libQtCore.so
...

Open gdb, which should reside somewhere in the android ndk directory (in Windows, it's under necessitas/android-ndk-r6b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin)

Tell gdb where your source is:

directory path/to/source

Give gdb the executable that it's going to be debugging, the app_process binary you downloaded from the device:

file path/to/app_process

And give it the locations of libstellarium.so, libc.so, and any other libraries so it can find them (you can run the command multiple times, it will add each directory to the search path):

set solib-search-path /path/to/lib/directory

Instructions on using gdb are beyond the scope of this document. You're on your own.

Now you should be able to resume in Eclipse and in gdb, and debug as usual.

It should be possible to hook gdb into Eclipse or QtCreator to allow GUI debugging. May want to investigate that at some point. It'll probably be handy to have a script do most of the setup for this use.

Debug with QtCreator

To import the project into QtCreator

If you don't have the environment variables saved on your account, start necessitas' QtCreator in a terminal window that does. On Windows, you must start QtCreator for a MinGW shell, otherwise it won't detect the MinGW cmake generator and you'll be quite stuck.

In QtCreator, open the CMakeLists.txt in the root of the directory where you've checked out Stellarium. In the following windows, choose "MinGW Makefiles" or "Unix Makefiles" as the generator, put in any cmake commands you need (the toolchain one from above may be all), and run it. If it fails, look in the directory it's created and edit the CMakeCache.txt as described above.

(I can't get the MinGW Generator to work on Windows, even though it's the only option QtCreator gives. Passing in -G"Unix Makefiles" appears to work)

To get it to build, deploy, and run the code, you can just add build commands to the project as described above (make install, ...)

Debugging

To have it actually debug the code is not straight-forward. You need to 'trick' Necessitas' QtCreator into working for you, and even then it probably won't work well:

  • create an empty Android project
  • clear out all of the build steps, but leave the deploy/running/debugging steps
  • copy in the binaries you built using the project you imported above, or symlink to the build directory or something
  • run it (using an actual device or and Android-15 target)

Debug (Java)

There is some Java code here, but thanks to necessitas it should be kept to a minimum.

Debug with Eclipse

Install Eclipse (preferably Eclipse Classic). Follow the directions for installing ADT.

Create a new project, choose Android project, and choose "Create project from existing source". Point Eclipse at the stellarium/android/java directory. Go to Project -> Properties, and set the JDK compliance level to 1.6. You can now use Eclipse to build and debug the software. If debugging, as noted above, you must use a device. Stellarium will not run in the Android emulator.

Personal tools
Namespaces
Variants
Actions
in this wiki
other languages
Toolbox