Just An Application

August 19, 2009

A Standalone Android Runtime: Logs

Filed under: Android, Java, Mobile Java, Standalone Android Runtime — Tags: , , , — Simon Lewis @ 10:26 am

The first thing the run() method of the ServerThread does is write to the Event log, at which point it falls over.

The Android runtime uses two logs extensively.

The Android log, accessed by static methods on the class


and the Event log, accessed by static methods on the class


both of which are in


In each case the actual logging is done by native methods.

The runtime uses logging to report progress, errors, and other signficant events, and it would be useful to have the logging work in some way so that we know what is going on, especially as there are likely to be a large number of errors initially, not least as a result of the wholesale replacement of native methods with Java stubs.

We could simply replace the native methods in the log classes with Java methods which write their arguments to standard out, but this would mean that the output from separate processes would be distinct, rather than being contained in the appropriate logs, and also that the information would tend to get lost in the general cacophony of stub methods reporting that they were being invoked.

An easy pure Java solution, and the one that was adopted, is to implement a logging server running as a separate process which then writes the logs.

Methods in the two log classes simply package up their arguments and send them to the logging server which formats them and writes them to the equivalents of the Android log and the Event log.

Records in the Event log are written in the correct format, although there was a slight glitch initially. The header format was taken from the EventLog class documentation, specifically

Events for the event log are self-describing binary data structures. They start with a 20 byte header (generated automatically) which contains all of the following in order:

  • Payload length: 2 bytes – length of the non-header portion
  • Padding: 2 bytes – no meaning at this time
  • Timestamp:
    • Seconds: 4 bytes – seconds since Epoch
    • Nanoseconds: 4 bytes – plus extra nanoseconds
  • Process ID: 4 bytes – matching android.os.Process.myPid
  • Thread ID: 4 bytes – matching android.os.Process.myTid

which turned out to be not quite right.

On the basis of the field offsets specified in the Event class nested in the EventLog class, and the declaration of struct logger_entry in


it seems that the Timestamp field actually follows the Process ID and Thread ID fields.

Copyright (c) 2009 By Simon Lewis. All Rights Reserved.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at WordPress.com.

%d bloggers like this: