release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Wiki > Main > AndroidPort (compare)

Difference: AndroidPort (r22 vs. r21)

Port Status

driverstatuscomments
LCD 100% Drawing into our classic framebuffer. Android draws from that in its usual update procedures with the aid of the Bitmap and SurfaceVuew? classes
Keys 100% Touchscreen + front buttons all working, no keyboard support yet though
Music playback 95% Playing music files back works flawlessly using AudioTrack? API (NOTE: some HTC phones with 2.1 are broken and may not be able to keep decoding if in the background). Some people report sporadic failure
FM Radio 0% Not yet implemented. There's no API for this, seems to be something the manufacturers add onto their OS (without opening the source)
Recording 0% Not yet implemented
Power Management 95% Battery level readout works. Rockbox idles quite efficiently when not playing music. Idle poweroff and sleep timer work. Dynamic ticks would be nice
Host integration 90% Receiving calls, backlight on/off, Activity pause/unpause is handled, wired headset buttons work. Android widgets for yesno and keyboard input are used. Homescreen widget. Sharing volume with global OS volume

TODO

  • Integrate the port into the build system so we can distribute .apk files.
  • Research what's needed in order to be able to distribute Rockbox for multiple screen dimensions (that can, but needn't, mean that Rockbox should be build screen resolution independent)
    • a patch which implements dynamic screen sizes is available on the tracker
  • Maybe FM Radio and Recording

Procedure for installation from source

  • NOTE: The installation has only been tested on Linux so far, but should in theory work on Windows(cygwin)/Mac as well. UPDATE: This does notwork on cygwin out of the box, and almost certainly will not without much hacking, since the NDK doesn't appear to support cygwin paths and the makefiles are not making any attempt to convert cygwin paths to win32 paths. (stripwax)
  • Download and install the Android SDK and NDK from http://developer.android.com/sdk/index.html and http://developer.android.com/sdk/ndk/index.html
  • Set up the SDK and NDK as per README in the android folder.
  • If you like eclipse: Import the Rockbox eclipse project from the android folder (File->New->Other->Android->Android Project; then select 'Create Project from existing Source')
  • Make the environment variables ANDROID_SDK_PATH point to the SDK directory and ANDROID_NDK_PATH to the NDK directories directory (the latter is needed by configure). Don't forget the trailing slash at the end of the path (required). The SDK path will be something like /path/to/whereyouinstalled/android/sdk/ , which is the directory directly containing subdirectories named 'platforms', 'platform-tools', 'system-images', etc. The NDK path will be something like /path/to/whereyouinstalled/android/ndk/ , which is the directory directly containing the subdirectories named 'toolchains', 'prebuilt', 'ndk-which', etc
  • Build librockbox.so Rockbox as usual in the android/ usual way: Create a build directory (e.g. build-android) as a subdirectory of the Rockbox trunk (configure with tools/configure trunk, change to that directory and execute ../tools/configure and follow the directions) (../tools/configure && directions, and then execute make -j3) e.g. make -j3. The result of the build will be librockbox.so .
  • Execute make zip and make apk (you need a debug signature setup for signing the apk). If you get errors when running make apk saying something like "platforms/android-16 not found", then try symlinking /path/to/sdk/platforms/android-16 to /path/to/sdk/platforms/android-17 (or whatever you have in the sdk you installed) - stripwax
  • Attach your phone and use 'adb install -r rockbox.apk' to install the app or use eclipse to "Run" the project. adb might not be in your path, but it's part of the sdk you installed, probably located under platform-tools subdirectory. you might just want to add the platform-tools subdirectory to your PATH environment variable for ease of use

GDB Debugging

There's the ability to debug native code with gdb. It probably requires root access, and is only tested on a rooted device. Here's the procedure (the first 3 steps don't need to repeated until the device is reset)

  • Push gdbserver if it isn't on the device already (it was on mine, under /system/bin). It ships with the ndk: adb push $ANDROID_NDK_PATH/toolchains/x86-4.4.3/prebuilt/gdbserver /data/local/
  • Pull contents of /system/bin/ and /system/lib from the device to a suitable working dir for debugging, e.g. the current dir: adb pull /system/bin/; adb pull /system/lib/
  • Create a file named .gdbinit with the following content (Note that you may need to edit the path to the Rockbox source and the solib-search-path if the debugging dir is not the current dir):
file app_process
directory /path/to/rockbox-source
set solib-search-path .
target remote :1234
continue 
  • Configure a DEBUG build (../tools/configure, then A for advanced, then D for debug build) and build Rockbox with make apk
  • Copy the generated .so files to the debugging dir: cp /path/to/builddir/libs/armeabi/*.so .
  • Enable adb tcp port fowarding: adb forward tcp:1234 tcp:1234
  • Start gdbserver on the device: adb shell /data/local/gdbserver :1234 --attach \`pidof org.rockbox\`
  • Start gdb on the host pc (also shipped in the ndk): arm-linux-androideabi-gdb

At this point, I got some warnings that some debugging symbols (for android libraries) were not found, but that's not a problem. But I needed to to enter them quickly away since Android otherwise kills Rockbox for not responding for too long.

Another note: GDB defaults to Thread #1, which is mightily useless. The vast majority runs in the Rockbox thread. This was Thread #9 in my case but it might be different on other devices. Type 'info threads' to see all threads and 'thread X' to switch to another one (where X is the number). You can use DDMS (shipped in the sdk) to find the exact thread since DDMS, unlike gdb, also knows the thread names by their string identifier.

Anyway, you can now set breakpoints, investigate segfaults and the like as usual.

Links

-- ThomasMartitz - 2010-08-14

r22 - 04 Apr 2013 - 23:37:30 - DaveHooper

Revision r22 - 04 Apr 2013 - 23:37 - DaveHooper
Revision r21 - 24 Mar 2013 - 19:45 - DaveHooper
Copyright by the contributing authors.