macrobug

Frequently appears in strace listings of what Android is up to. Appears to be setting the thread local storage.

I’ve also found that strace’ing Zygote and the things it spawns is (possibly predictably) much more fruitful in terms of IPC messages than strace’ing the runtime. However I have don’t yet have enough time to figure out how I dig down into the structure enough to find out the destination process for a transaction, from the data available. Once I get that far I’d like to think I can knock up a simple flow diagram of the messages passed between all the Android threads and we can start to get a decent picture of how the whole system operates.

One day…

Here are some superficial thoughts on Android (which I don’t know much about) versus Symbian OS (which I do).

Some of that’s probably rubbish, and may be based on misinterpreting bits of the interesting podcast. I’m happy to accept corrections, but then again, only six people read this blog anyway so this post was mostly for my own interest :-)

In other news, Motz has figured out the correct linker settings for the Android loader!

Here’s my latest openbinder.c file (use with the other changes in my previous post).

openbinder.c

Much more sensible output this time. I was right to be suspicious about all the nulls – it turned out I was only transferring the first byte of the data. But still no strings yet… next is to decode the replies from the kernel, then to read the kernel module source a little more closely to work out if we can decode any of the stuff in ‘buffer’. Plus, of course, to keep working on it to see if I’ve made any other daft mistakes :-)

Example output:

22:34:57.044758 ioctl(7, BINDER_WRITE_READ, {write_size=56,write_consumed=56,write_buffer=0x153f8,read_size=256, read_consumed=8,read_buffer=0x152e8,write_data= [bcINCREFS(target=0x00000015)bcACQUIRE(target=0x00000015) bcREPLY({cookie=0x00014130,code=0x00000000,flags=0x00000000,priority=80,data_size=12, offsets_size=0,data={buffer=0x00015970,offsets=0x00000000, *buffer=[0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x00,0x00,0x00,............]}})], read_data={...}) = 0

22:34:57.867208 ioctl(7, BINDER_WRITE_READ, {write_size=40,write_consumed=40,write_buffer=0x153f8,read_size=256,read_consumed=8, read_buffer=0x152e8,write_data=[bcREPLY({cookie=0x00014130,code=0x00000000, flags=0x00000000,priority=80,data_size=24,offsets_size=4,data={buffer=0x00015e18, offsets=0x00014130,*buffer= [0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x85,0x2a,0x68,0x73,0x08,0x00,0x00,0x00,0x0e,0x00,0x00,0x00,0x04,0xfe,0x4f,0x10, .........*hs..........O.]}})],read_data={...}) = 0

So far the only decent string I’ve seen in any of the buffers is /dev/input/event0… which might give another clue about where to head next.

I’ve had a quick look into the OpenBinder ioctls zinging around within the Android emulator. Here’s a summary of what I’ve done, and the results I’ve had (such as they are… it’s not been too fruitful).

First, the context. We know that Android IPC uses a system called OpenBinder, thanks both to Benno’s pioneering investigations, and the fact that one of the OpenBinder developers kindly posted a load of information on the web! But, we also know that the user-side OpenBinder is not based on the existing MPL version, or Google would have had to release the code already. (For this reason a lot of my terminology is probably wrong – it looks like perhaps the MPL version is OpenBinder, whilst we’ve got some other type of Binder, perhaps a not-quite-Open-yet-Binder).

In fact, the only code we’ve got relating to the OpenBinder in use within Android are the code for the module, provided within the Android Linux kernel. That includes two header files – include/linux/binder_module.h being the important one – and about 10 files code for the kernel-side driver.

According to the OpenBinder website, the kernel driver is responsible for reference-counting as well as the pure data-copying aspect of IPC. So, with any luck, the kernel-side code will have to understand the data structures passed back and forth, and therefore so can we.

Anyway, this is what I did.

1. First, I modified strace to output some information about OpenBinder. I only bothered with the BINDER_WRITE_READ ioctl, and essentially just printed out the payload in binary, for the moment. My changes are here – sorry it’s not a nice easy patch, but all the makefiles etc. got changed too and I didn’t want to include them in the patch. strace-4.5.15-diffs
2. I built this using my Scratchbox as per my previous instructions. You’ll need to run automake first to rebuild the makefiles to include the extra source code file.
3. I then followed Benno’s instructions to boot Android without the automatic startup of Zygote and the runtime. I ran my modified strace in exactly the same way as Benno to get the output I wanted.

Enough! What are the results? Well… not very spectacular yet.

Here’s a typical ioctl:

ioctl(7, BINDER_WRITE_READ, {write_size=8,write_consumed=8,write_buffer=0x14eb0,read_size=256, read_consumed=44,read_buffer=0x14da0, write_data={0x4,0xc1,0xb,0x0,0x84,0xc1,0xb,0x0,}, read_data={0xe,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xb9,0xfc,0x1,0x0,0xe,0x0,0x0,0x0,0xb1,0xfc,0x1,0x0, 0xe,0x0,0x0,0x0,0xa9,0xfc,0x1,0x0,0xe,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0, 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,}) = 0

My thoughts about that (in no particular order):

• I don’t like the fact that the write_buffer and read-buffer addresses are so small. I am not at all familiar with the Linux memory map, though, so maybe Linux process memory really does start all the way down there. And, their type is signed long. (In standard OpenBinder it’s void*, according to the documentation). Comments suggest that this strange type is used to allow for mixed 32/64-bit systems, but I still slightly worry that these parameters aren’t addresses at all, but could be offsets into some shared mmapped area or something.
• However, each time I tried to fetch the data at this address, it worked. So this makes me think they’re real addresses.
• I think these data areas should contain lists of commands and replies, respectively. The commands and replies are variable-length, so without some analysis it’s hard to work out second and subsequent commands/replies. The first byte is an opcode from BinderDriverCommandProtocol. I’m encouraged that the first byte is never 0×0, which would be bcNOOP, and is small enough to be likely to be an enumeration. So again, I’m happy these are the command streams.
• But I’m surprised we’re seeing so much null data. I’d also hoped that we’d see some strings related to the objects being bound to. But perhaps they’re pointed to by pointers within the data stream (certainly, the main ‘transaction’ command usually contains pointers to the real data).
• Maybe the read_data is usually blank; the client always allocates 256 bytes for a reply. Quite often the first opcode in the reply is 0xe, no-op, which might back that up. Although I’m not clear how the no-op operation causes the rest of the buffer to be ignored.

The code within the kernel module does parse and try to understand this data, and it does match the understanding above.

My overall conclusion: this approach does work, and it’s just a matter of getting time to implementing code within strace fully to parse the Binder command stream. I reckon we should be able to get as far as tracking individual object lifetimes, and what method are called on which objects. I reckon we should be able to get the names of the objects (as that’s part of the binding) but I haven’t yet worked out how binder specifies the methods which are called… it’s probably by ordinal into the interface rather than by name, so perhaps we won’t be able to work out what methods are being called. We’ll see, though. It would be great if we could see what methods were being called by one process on another.

You might wonder why I stopped here… mostly because I ran out of time, but also because I planned to do the analysis using Perl from this point onwards. But I think we’re going to need to access pointers to other bits of memory, so strace is probably the way to go.

(It might be easier just to rebuild the kernel with binder logging turned on, but I haven’t yet tried rebuilding the kernel for Android).

Here is an archive of the strace logs retrieved. Logs

I hope I will eventually get around to implementing much more code within strace to dig into what Binder is up to, although I reckon Benno’s bound to get there first :-)

Benno explains how to build simple native programs for Android. But any significant pre-existing Linux software package uses a complex array of libraries and a correspondingly complicated build process, typically based around GNU Autoconf. That build process usually involves a “configure” script whose purpose is to run tiny programs to experiment with the system, to find out its capabilities and set up the code appropriately.

Terrific, except it doesn’t work if, say, you’re building on an Intel x86 box, but trying to build for Android, which is based around Linux and an entirely different CPU. Fortunately, the Scratchbox project exists to solve this problem. It provides you with a special Linux universe, which uses the QEMU emulator to run ARM binaries. Hence: autoconf can run its experiments and all will be well.

It worked surprisingly well and surprisingly simply. Good work by the Scratchbox team.

Maybe this is how Benno produced his strace binary which he used to dig up some interesting stuff from Android. I’m not sure. Either way, I’m going to be building strace here as an example of how to get this stuff to work.

1. You’re really going to need Linux. Specifically, it sounds like a Debian-based distribution is by far the most likely to work. Since I’ve got a Mac, I had to install Ubuntu Linux 7.10 within a Parallels virtual machine. This is easier said than done, in itself, but once the X-server problems were sorted out it was reliable.
2. First we need to install Scratchbox. It’s available as Debian packages. You can install it either using command-line tools, or the GUI package manager. So naturally I chose half-and-half.
   1. Edit (as root) /etc/apt/sources.list, and add this line: deb http://scratchbox.org/debian stable main
   2. Use the Synaptics Package Manager (in the System menu) to look at the available packages. You’ll need:
      • scratchbox-core
      • scratchbox-libs
      • qemu (not 100% convinced this is really required; I think it may be provided with Scratchbox)
      • scratchbox-devkit-cputransp

      You’ll also need a toolchain. Which toolchain(s) to choose was a bit of a mystery. I’d like to have seen a package using CodeSourcery’s latest compiler, 2007q3. But it seems the Maemo platform, the main user of Scratchbox, is stuck on an older compiler. To be honest, more of an issue than the compiler is probably the version of libc in use within the Android platform. I haven’t figured that out yet, so I’ve been producing statically linked binaries for the moment. Anyway, for my toolchain, I chose scratchbox-toolchain-arm-linux-2006q3-27, which appeared to be the most recent.

   3. Wait for these to install…
3. As per the Scratchbox install document and these Maemo-focussed instructions, add your user to scratchbox: sudo /scratchbox/bsin/sbox_adduser adrian
4. Log out and log in again until the groups command reveals you’re in the sbox group
5. Run scratchbox
6. Run sb-menu
7. Create a new target. Configure it thusly:
   1. Select the compiler you installed, arm-linux-2006q3-27
   2. Select cputransp devkit
   3. Select qemu-arm-0.8.2-sb2 emulation
   4. No to rootstrap
   5. Yes to files. Choose C-library, /etc, Devkits and fakeroot



8. Exit sb-menu. You will be deposited back at the scratchbox shell, but this time the shell is able to run ARM binaries. So things like configure should work.
9. Fetch your source. I built /scratchbox/packages/hello-world.tar.gz and also strace 4.5.15. In theory you ought to be able to build anything (so long as static linkage is OK, and so long as the configure script doesn’t do anything too wacky that qemu can’t emulate). For your first build, perhaps stick to the hello world example?
10. Unzip it/install it/etc. into your scratchbox home. What appears to be /home/xyz is actually located at /scratchbox/users/xyz/home/xyz so that’s where to put the files. (The reasons scratchbox maintains a separate root is so that there’s no chance any of your important system files can be blatted whilst building things for a different architecture).
11. ./configure LDFLAGS=--static (that’s minus-minus static, in case the blog software munges it)
12. make
13. That’s it! You now need to move the generated binary from here onto your Android emulator in the tried and trusted way, then execute it:

MacBook:Desktop adriantaylor$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, statically linked, for GNU/Linux 2.6.14, not stripped
MacBook:Desktop adriantaylor$ cd android_sdk_darwin_m3-rc20a/tools/
MacBook:tools adriantaylor$ ./adb push ../../hello /system/bin/hello
2006 KB/s (563210 bytes in 0.274s)

In my case, rinse and repeat for strace, then…

MacBook:tools adriantaylor$ ./adb shell
# /system/bin/hello
Hello World!
# /system/bin/strace /system/bin/hello
execve("/system/bin/hello", ["/system/bin/hello"], [/* 8 vars */]) = 0
uname({sys="Linux", node="(none)", ...}) = 0
brk(0)                                  = 0x80000
brk(0x80c70)                            = 0x80c70
syscall_983045(0x80430, 0x7dd88, 0, 0x10, 0x80430, 0x7e734, 0x7ea38, 0xf0005, 0x28, 0x8, 0x4, 0x10, 0, 0xbe94cb08, 0x11da8, 0x8834, 0x60000010, 0x80430, 0, 0, 0, 0xc8c8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
brk(0xa1c70)                            = 0xa1c70
brk(0xa2000)                            = 0xa2000
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40000000
write(1, "Hello World!\n", 13Hello World!
)          = 13
munmap(0x40000000, 4096)                = 0
exit_group(0)                           = ?
Process 547 detached

Maybe I’ll eventually get some time to get dynamic linkage working, which shouldn’t be too hard, just a matter of working out which libc to use. Famous last words?

Update: yes, dynamic linkage may be too much to hope for. The libc is apparently derived from BSD rather than glibc. And I can’t get these tips to work.

A couple of links: some investigation and some more information on it.

Java is widely regarded as easier to develop for than C++, etc. I tend to agree with that. In C++ it’s easy to find some nasty question to separate the decent developers from the amateurs (for example, ask them how a vtable works).

But even Java has some “low-level” lurking features which only the better Java developer understands. One of these is the class loader. Java normally has a class loader which will search the CLASSPATH environment variable, and/or any JAR file specified, when asked to load a given class. But this can be replaced – and often is.

For example, in Eclipse, each plugin has its own class loader. This means that plugins cannot conflict by having two classes with the same name; it also means that Eclipse can enforce a clear dependency tree on the plugins (the classloaders interact to allow downstream plugins to load classes from upstream plugins).

More or less the same applies to J2EE environments on web servers. Again, this is done so that the different… errr… web thingies have separate environments.

Still other classloaders – such as for good old Java applets – load classes dynamically across a network.

I’m hardly an expert on this stuff, but it seems I know more than some. The vendors of a library I wanted to use load their configuration files using getResourceAsStream(), which is delegated to the class loader. I explained this wasn’t very convenient for people whose class loaders didn’t refer to useful directories. They said that I should just edit the CLASSPATH and insisted that “all Java environments have a CLASSPATH” despite me repeatedly telling them it’s not true. For Eclipse and web applications, at least, the CLASSPATH is irrelevant.

The library is popular and otherwise appears well-designed and reasonably well-written.

All of which makes me think that any decent Java developer would be able to answer an interview question such as “what are some advantages of using a different class loader?” as a good filter at interview for Java developers.

Having said that, I’ve always been rubbish at interviewing so don’t listen to me.

In Excel, suppose you want to produce a table like this:

Obviously you want to use the SUM formula to add up the total number of beasties. That means you can’t literally type “2 oxen” into the cell – you’ll have to just type “2″ but make up a number format to present it as you wish.

That’s easy for singular quantities: the number format would be 0 "sheep".

But for plurals you have to go a bit further. It turns out you can put multiple formats in the box, separate them with semicolons, and add conditions. So the desired format is this: [=1]0 "ox";0 "oxen".

This adds all sorts of potential. What about [=0]"None";[<4]"A few";"Lots"? Or [=2]"Company";[>2]"A crowd"?

I’ve found a neat way to survive using Eclipse on a small screen!

Get rid of the Outline view (I did that ages ago). That frees up a third of your screen which you can devote to code.

The cunning bit is – then – to use Ctrl-O to bring up the Quick Outline view, and type the first few letters of the thing you wish to navigate to. Quicker than using the Outline view in the first place, and takes no screen space!

I haven’t seen this full sequence written down anywhere (only in various partial fragments), so here it is for anyone who finds it useful. Here’s what you need to do if you want to add a Help button to your Eclipse wizard.

1. In your wizard class, call setHelpAvailable(true).
2. In your wizard page class, override performHelp() with code like this:

   public void performHelp() {
     PlatformUI.getWorkbench().getHelpSystem()
       .displayHelp(CONTEXT_ID);
   }
   

3. CONTEXT_ID should be something like “ .mywizardhelp”.
4. Add a help context extension to your plugin. It should look something like:

   <extension
            id="com.wotsit.doodah.wizardhelp"
            point="org.eclipse.help.contexts">
         <contexts
               file="helpContexts.xml"
               />
      </extension>
   

5. Create that helpContexts.xml file in the root of your plug-in. (It can be localised in fragments, incidentally). It should contain something like:

   <contexts>
         <context  id="wizardhelp">
           <description>Gets help about this wizard</description>
           <topic href="html/wizard.html"  label="My wizard help"/>
           <topic href="html/toc.html"  label="General help"/>
     </context>
   </contexts>
   

6. Finally, of course, create the help HTML itself (which you probably did already if you selected the easiest settings when creating your plug-in in the first place).

The bit I couldn’t find documented anywhere was the single line of code which ties it all together! So there might be a better way to do that, but it seems to work.