db4o has been running on Android from the very beginning - in fact, we had our first db4o-based Android app running a few hours after the first Android beta was out. However, there have been some nasty pitfalls in db4o development for the Android platform (most notably the very limited stack depth for Android applications), and we didn't have any automated indicator for keeping full Android compliance while moving the db4o code base forward.

Eventually we got to tackle these issues to really make Android a first class citizen among the platforms supported by db4o.

Continuous Testing

Every check-in into db4o code repository triggers an extensive build process, that will exercise all our test suites against the various supported platforms, ranging from JDK1.1 up to .NET 4.0 SilverLight.

To this range now we added a dedicated test suite run against the Android emulator (currently a virtual device version 2.1). This means every single change in db4o code will almost immediately be exercised in the Android platform.

Limiting db4o stack usage

Due to the notoriously small DalvikVM stack size, db4o would potentially run into a StackOverflowException upon storing or activating deep object graphs.

To address that, we tweaked the internal db4o stack management mechanism to ensure that recursive descent handling switches to a heap based queue much earlier on the Android platform.

As a result, no more stack overflows should occur handling deep object graphs. There are some minor exceptions to that rule - most notably ExtObjectContainer#peekPersisted() is not integrated into that mechanism yet. (However, we don’t see many convincing use cases for using #peekPersisted in deep objects, anyway).

 

Calling constructors

When we instantiate objects from a database, we want to do this without any side effects, without calling constructors.

Although there is no official support in any standard API, a Java implementation that supports serialization has to do this somehow.

 

On the Android platform, we now use the functionality from the private static method ObjectInpuStream#newInstance.

 

The road ahead

There are still some minor issues to be solved:

  • For some platform classes you may experience slightly varying behavior compared to a standard Sun JDK. So far the only example we are aware of is BigInteger and BigDecimal. While on a standard Sun VM, instances of these classes can be stored out of the box, on Android you are required to configure the BigMathSupport (which is the recommended practice, anyway).

  • Our runtime native query optimization for DalvikVM is still work-in-progress. For the time being, you'll have to resort to optimization at build time if you want your native queries to run optimized.

  • We are still working on getting a few remaining test cases to run which make heavy use of class loading wizardry, mostly covering missing class scenarios.

     

While continuing to work on those few puzzle pieces, we are happy to welcome Android to the family of platforms db4o provides full-fledged support for.