|| Drawing into our classic framebuffer. Android draws from that in its usual update procedures with the aid of the Bitmap and SurfaceVuew? classes
|| Touchscreen + front buttons all working, no keyboard support yet though
| Music playback
|| 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
|| Not yet implemented. There's no API for this, seems to be something the manufacturers add onto their OS (without opening the source)
|| Not yet implemented
| Power Management
|| 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
|| 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
- 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.
- 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 and ANDROID_NDK_PATH to the NDK directories (the latter is needed by configure).
- Build librockbox.so as usual in the android/ directory of Rockbox trunk (configure with tools/configure and follow the directions) (../tools/configure && make -j3)
- Execute make zip and make apk (you need a debug signature setup for signing the apk).
- Attach your phone and use 'adb install -r rockbox.apk' to install the app or use eclipse to "Run" the project.
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):
set solib-search-path .
target remote :1234
- 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.
Copyright © by the contributing authors.