Port Status

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)

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 not work on cygwin out of the box, 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)

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 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 Rockbox in the usual way: Create a build directory (e.g. build-android) as a subdirectory of the Rockbox trunk, change to that directory and execute ../tools/configure and follow the directions, and then execute make 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):

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.