Building for Android

From Stellarium Wiki
Revision as of 08:54, 6 March 2012 by Brady Brenot (Talk | contribs)
Jump to: navigation, search

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.

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 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)
  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
  • EXTERNAL_GUI_SRC_PATH
    • "../../plugins/MobileGui"
  • GUI_MODE
    • External
    • 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
      • 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 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" is similar, but for VFPV3. Works on Tegra devices.
  • 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

Troubleshooting

If something goes wrong: The log file will be present at /data/data/org.stellarium.stellarium/files/.stellarium/log.txt or possibly at /sdcard/stellarium/log.txt. 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

(should write our own version of the ndk-gdb script to automate some of this)

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

I haven't the foggiest. If anyone wants to investigate this, please go right ahead :)

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, ...)

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.

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