Random notes on building Android

Random notes on building Android

This is mostly a note to myself. The easy way to build a profilable image for Android (e.g. Gingerbread). I am applying the patch from the bottom to build with framepointers. I am build an unstripped image, I use the environment script and then launch the emulator. With the default engineering mode opcontrol and oprofiled will be installed only the events will be missing from the image.

$ make TARGET_STRIP_MODULE=false
$ . ./build/envsetup.sh
$ help
$ setpaths
$ ./out/host/linux-x86/bin/emulator

diff --git a/core/combo/TARGET_linux-arm.mk b/core/combo/TARGET_linux-arm.mk
index ae1997c..66e55fd 100644
--- a/core/combo/TARGET_linux-arm.mk
+++ b/core/combo/TARGET_linux-arm.mk
@@ -56,7 +56,7 @@ TARGET_LD := $(TARGET_TOOLS_PREFIX)ld$(HOST_EXECUTABLE_SUFFIX)
 TARGET_NO_UNDEFINED_LDFLAGS := -Wl,--no-undefined
 
 TARGET_arm_CFLAGS :=    -O2 
-                        -fomit-frame-pointer 
+                        -fno-omit-frame-pointer 
                         -fstrict-aliasing    
                         -funswitch-loops     
                         -finline-limit=300
@@ -68,7 +68,7 @@ TARGET_arm_CFLAGS :=    -O2 
 ifeq ($(ARCH_ARM_HAVE_THUMB_SUPPORT),true)
 TARGET_thumb_CFLAGS :=  -mthumb 
                         -Os 
-                        -fomit-frame-pointer 
+                        -fno-omit-frame-pointer 
                         -fno-strict-aliasing 
                         -finline-limit=64
 else
HTC Desire/Android GSM Protocol Issue

HTC Desire/Android GSM Protocol Issue

I was playing with ASN1 and Supplementary Services over the Weekend. My goal was to provide extended user information during a call setup. So the first step was searching for information of how it could look like, this involved going through the GSM Spec, the 2nd part was wrestling with asn1c to generate some dummy data (as I couldn’t find a trace doing that), the 3rd part was being able to generate that from OpenBSC and send it to the phone.

Well, long story short. It doesn’t work, the better phones ignore the data I am sending, all the others refuse to show incoming calls, the Phone failing the most is a HTC Desire with Android. First of all OpenBSC has a pretty simple USSD implementation and it doesn’t like that, now when you place a phone call (while Android decides to do a USSD request in the background), OpenBSC will close the channel, not do any Call-Control and on the Android one screen shows the call is terminated, in the decoration it is still active, then the wakeup/sleep logic gets confused, you can not hang-up and then the phone is restarting.
The executive summary: Not implementing USSD in your network (we send an error and such) can make Android phones reboot if someone is placing a call at the time android retries to send the USSD query.
Adding a route with android’s route

Adding a route with android’s route

Today I needed to add a route on the android shell but was greated with “Invalid Argument” failures, there is no “-h”, no man page. So we will have to use the sourcecode.

First of all the code is in /system/core/toolbox/route.c
and it supports three types of argument..
  • route add default dev DEVICE
  • route add default gw IP dev DEVICE
  • route add -net IP netmask NETMASK gw IP
Android mediaserver segfault

Android mediaserver segfault

Hmm… we just want to stream some video… giving android a MPEG TS stream does not work, giving it a HTTP Pantos, does not work, giving it a ms3u playlist segfaults the mediaserver. fun

Android and Java

Android and Java

I am now playing with the Android UI/Java Code and right now I have something really really simple to do. Over time I have a bunch of URIs to GET or POST and after it is done I want to have the status and the data. On top of that it should not block the UI thread. Android is using the HttpComponents of the apache project. The good thing about it is that Google was not reinventing the wheel, the bad thing is that the code is Java. So I will need to write 200 lines of code to setup a threadsafe ConnectionManager and a HttpClient on top of that and then I need to write my own thread pool… Which is bringing one back to the main complain about Java, it is an overengineered system…

But in general I think the Android UI classes are very promising, yesterday I implemented the preferences for my application and it is really really easy, better than anything i have dealt with before. One needs to create a xml/preferences.xml, one can use “categories” and each category can have different preference items, even custom ones. The system will automatically create the view for that (like with the most xml documents for Android) and it will take care of saving/loading the settings.