User:Joel Reymont/Android Notes

Intro

This page collects my notes on porting Firefox to Android.

Current status

October 12, 2009

Via Chris Lord...

The headless branch of Mozilla that we work on renders to system memory and it is up to the embedder to get this to a texture however they like. We have our own embedding library that uses this with Clutter clutter-mozembed and we just upload each changed region to the texture.

A possible speed-up is to use a shared memory pixmap and texture-from-pixmap (or whatever the platform's equivalent is), which would remove the need to copy from system to video memory.

I wrote a (now out-dated, but still relevant) guide on building the Moblin browser components on my blog. There's also a short demo application I wrote that just uses mozilla-headless alone to take a screenshot of a web-page.

Unfortunately, there is no documentation beyond the standard Mozilla documentation and the source-code (and the above-mentioned links).

I think the easiest way to port Firefox to android would be to write an android-backend (which could well be based on our headless backend) - I didn't think that the Android native development kit was fully featured enough to allow something like this though?

...

You can't run Firefox with the headless backend as it is, it's designed to be embedded and for libxul to be used. The headless backend is also heavily dependent on GLib (for the main loop, signals and idle handlers).

If you wanted to run Firefox, you'd have to write a new backend, or modify an existing one, to provide the application framework. In the gtk2 and headless backends, this is GLib-based. The Gtk2 backend creates a GtkWindow and that is how the user sees and interacts with the application. On the headless backend, there is no visible window. It can only be used for embedding via libxul.

---

Chris has a presentation that explains the headless branch a bit.

Android Notes

Building and running the OpenGL ES NDK example

Here's how to build and run the san-angeles application from NDK 1.6. This program demonstrates how to use a GLSurfaceView from Java along with native OpenGL calls to perform frame rendering.

 
cd /Volumes/android/mydroid/
. build/envsetup.sh 
including vendor/aosp/vendorsetup.sh
lunch sdk-eng

============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=1.6
TARGET_PRODUCT=sdk
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR=false
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm
HOST_ARCH=x86
HOST_OS=darwin
HOST_BUILD_TYPE=release
BUILD_ID=Donut
============================================

First, we need to build the shared library of native code

cd ~/work/android/android-ndk-1.6_r1/
build/host-setup.sh
make APP=san-angeles

Android NDK: Building for application 'san-angeles'    
Compile thumb  : sanangeles <= apps/san-angeles/project/jni/importgl.c
Compile thumb  : sanangeles <= apps/san-angeles/project/jni/demo.c
Compile thumb  : sanangeles <= apps/san-angeles/project/jni/app-android.c
SharedLibrary  : libsanangeles.so
Install        : libsanangeles.so => apps/san-angeles/project/libs/armeabi

Next, we need to make sure we can build the Java portion of the project

android update project --path apps/san-angeles/project

Updated local.properties
File build.xml is too old and needs to be updated.
Added file apps/san-angeles/project/build.xml

Now, lets build the debug release of project

cd apps/san-angeles/project/
ant debug

Buildfile: build.xml
    [setup] Project Target: Android 1.6
    [setup] API level: 4

dirs:
     [echo] Creating output directories if needed...

resource-src:
     [echo] Generating R.java / Manifest.java from the resources...

aidl:
     [echo] Compiling aidl files into Java classes...

compile:
    [javac] Compiling 1 source file to /Users/joelr/Work/android/android-ndk-1.6_r1/apps/san-angeles/project/bin/classes

dex:
     [echo] Converting compiled files and external libraries into bin/classes.dex...

package-resources:
     [echo] Packaging resources
 [aaptexec] Creating full resource package...

debug-sign:

package:
[apkbuilder] Creating .DemoActivity-debug-unaligned.apk and signing it with a debug key...
[apkbuilder] Using keystore: /Users/joelr/.android/debug.keystore
[apkbuilder] /Users/joelr/Work/android/android-ndk-1.6_r1/apps/san-angeles/project/bin/classes.dex => classes.dex
[apkbuilder] /Users/joelr/Work/android/android-ndk-1.6_r1/apps/san-angeles/project/libs/armeabi/libsanangeles.so => lib/armeabi/libsanangeles.so

debug:
     [echo] Running zip align on final apk...
     [echo] Debug Package: bin/.DemoActivity-debug.apk

BUILD SUCCESSFUL
Total time: 1 second

Finally, let's install the app on the device

adb install -r bin/.DemoActivity-debug.apk

1107 KB/s (13707 bytes in 0.012s)
	pkg: /data/local/tmp/.DemoActivity-debug.apk
Success

To run the app click on the "tab" at the bottom of the Android emulator screen and then on the DemoActivity icon in the list of applications. Enjoy!

Drawing and input from native code

Via Jack Palevich...

Input is done by subclassing a view, and override the various input methods. Make sure your view can get focus, using setFocusableInTouchMode(true); 
Otherwise you won't get input events. You could use any View class as your base class, but I suggest that you subclass GLSurfaceView because that makes it easier to use OpenGL graphics for drawing.

Probably the fastest way to get output from native code is done using OpenGL ES, which is newly available in NDK 1.6. Create a texture the size of the 
screen ( it has to be a power of two on each side, so 512 x 256 if your screen is 320 x 240.) Then update the texture and render it to the screen as a screen aligned quad.

For native OpenGL ES APIs the drawing surface is implicit in the thread. For Quake, GLSurfaceView's rendering thread sets up the context and calls the QuakeView's Renderer, which calls the native code, which makes the native GL calls.

Because the context is implicit in the thread, there's nothing that needs to be passed between Java and native code.

The downside of this approach is that you can't wrap the native GL calls as easily as you can wrap the JSR 239 Java OpenGL APIs. It's sometimes useful to wrap the GL APIs to keep track of the matrix stack, or log debugging messages, or check for error messages.

Building Android on Snow Leopard

1. Get the sources.

2. Apply these changes

cd system/core && git pull git://android.git.kernel.org/platform/system/core refs/changes/45/11845/2 && cd ../..
cd external/qemu && git pull git://android.git.kernel.org/platform/external/qemu refs/changes/46/11846/2 && cd ../..
cd prebuilt && git pull git://android.git.kernel.org/platform/prebuilt refs/changes/14/12014/1 && cd ..
cd prebuilt && git pull git://android.git.kernel.org/platform/prebuilt refs/changes/75/12075/1 && cd ..
cd build && git pull git://android.git.kernel.org/platform/build refs/changes/74/12074/1 && cd ..
cd build && git pull git://android.git.kernel.org/platform/build refs/changes/93/12093/1 && cd .. 

The following almost works but resets the head each time. Both of the last two changes are needed but the Java one gets written over by the very last change. Also, changes downloaded this way get blown away on repo sync.

repo download platform/system/core 11845/2
repo download platform/external/qemu 11846/2
repo download platform/prebuilt 12014/1
repo download platform/prebuilt 12075/1
repo download platform/build 12074/1
repo download platform/build 12093/1

3. lunch sdk-eng && make sdk

You should see something like this if everything goes well

ls out/host/darwin-x86/sdk/
android-sdk_eng.joelr_mac-x86		sdk_deps.mk
android-sdk_eng.joelr_mac-x86.zip

One more step is needed

export PATH=$PATH:`pwd`/out/host/darwin-x86/sdk/android-sdk_eng.joelr_mac-x86/tools/
pushd prebuilt && ln -s darwin-x86 darwin-x86_64 && popd
pushd out/host/darwin-x86/sdk/android-sdk_eng.joelr_mac-x86/tools/lib
ln -s x86 x86_64 && popd

Verify that everything works

android list targets

Available Android targets:
id: 1
     Name: Android 1.6
     Type: Platform
     API level: 4
     Revision: 1
     Skins: HVGA (default), QVGA, WVGA800, WVGA854

and

     
android list avd

Available Android Virtual Devices:

4. You are set and you can now run the emulator, e.g.

export AND_HOME=/Volumes/android/mydroid
export AND_SDK=$AND_HOME/out/host/darwin-x86/sdk/android-sdk_eng.joelr_mac-x86
export AND_BIN=$AND_SDK/tools
export AND_IMG=$AND_SDK/platforms/android-1.6/images
export AND_KERNEL=$AND_IMG/kernel-qemu
export PATH=$PATH:$AND_BIN

hdiutil attach ~/work/android/android.dmg -mountpoint /Volumes/android
cd /Volumes/android/mydroid
. ./build/envsetup.sh
emulator

You should see home screen in a minute or less.

You can also run the emulator in verbose mode if you want to troubleshoot or just see lots of interesting output, e.g.

emulator -verbose -logcat "*:v"

emulator: found Android build root: /Volumes/android/mydroid
emulator: found Android build out:  /Volumes/android/mydroid/out/target/product/generic
emulator:     locking user data image at /Volumes/android/mydroid/out/target/product/generic/userdata-qemu.img
emulator: selecting default skin name 'HVGA'
emulator: autoconfig: -skin HVGA
emulator: autoconfig: -skindir /Volumes/android/mydroid/development/emulator/skins
emulator: keyset loaded from: /Users/joelr/.android/default.keyset
emulator: trying to load skin file '/Volumes/android/mydroid/development/emulator/skins/HVGA/layout'
emulator: skin network speed: 'full'
emulator: skin network delay: 'none'
emulator: no SD Card image at '/Volumes/android/mydroid/out/target/product/generic/sdcard.img'
emulator: registered 'boot-properties' qemud service
emulator: registered 'boot-properties' qemud service
emulator: Adding boot property: 'qemu.sf.lcd_density' = '160'
...

Vlad's Android Notes

Can be found here.