Building Applications with Multiple SDK Applications in Eclipse Without Losing Compilation Time

Question

I am developing an Android application in Eclipse. I would like to target a wide variety of devices and SDK versions (for example, I can optionally support multi-touch). I understand the recommended approach for allocating all new functions to a particular class and using lazy loading to load this class at runtime if the host device really supports this function.

The disadvantage of this approach is that I have to compile all my code with the SDK of the newest function that I want to use. This means that if some new function flows into my "version neutral" code, the compiler will no longer be able to catch it.

I would like to compile my project with an older Android SDK in Eclipse to make sure my "version neutral" code is in order. I would like, if possible, to avoid moving my build system from Eclipse. I am glad that this old version of the SDK is a bit inconvenient to run.

I think this boils down to some conditional complication (or conditional “binding”) inside Eclipse? For example, in my project, when creating against SDK-1.6, I would like to leave the source “MultiTouchHandler.java” from the assembly. I'm not sure if it is possible to express "assembly types" like this in Eclipse.

The hacker solution seems to simply manually change the SDK version of the project, rebuild and look through the errors, and ignore the "expected" errors. The overkill solution seems to be writing my own ant / maven / make build scripts.

Matters Related

This question: Versions and common codebases with Eclipse cover similar grounds, but will include moving all classes related to the version to separate "libraries". (And I would still have a problem with multiple build types in Eclipse, I think.)

This question: Building multiple project configurations using eclipse implies that I have to go to an external build system (e.g. ant or maven), but this is much more than just trying to build with the old SDK from time to time.

Answer 1

The February 2012 (v17) updates of the Lint tool in ADT should help solve this problem without requiring multiple builds. When an application targets the old minimum SDK but compiles against the newest SDK (as recommended), the lint tool will notice if calls to the new SDK are invoked. If you are sure that the call is in order (since you hid it behind the SDK_INT runtime check or something else), you can quickly copy the annotation to prevent the warning.

For example, in my code, I have a call to View.setSystemUiVisibility, which was introduced in API 11, but I am targeting API 8. Running Lint shows:

The call requires API level 11 (current min - 8): android.view.View # setSystemuiVisibility

QuickFix offers two kinds of fixes: adding an annotation that suppresses the warning or adds an annotation that declares a piece of code as working in API 11.

More details here: http://tools.android.com/recent/lintapicheck

Answer 2

A slightly less clean / less efficient method would be to use reflection to access the newer apis you need, rather than trying to reference them directly with lazy loading. This should allow you to compile a file with a lower sdk level.