2

Problem: I'm writing an Android app, and one of its features requires Open Accessory compatibility, which is only available in 3.1 and up (as well as a backport for certain versions of 2.3.4). The packages I need (android.hardware.usb or android.future.usb) are completely absent from earlier API levels, but I need the app to run on at least Android 2.2. Right now, it won't even install (I get "INSTALL_FAILED_MISSING_SHARED_LIBRARY" in Eclipse).

I've done some research and come up with the following potential solutions, but I need help choosing which one is the "best" (easiest to implement, cleanest, easiest to maintain, most logical...) or if there's another solution I've overlooked.

Solution #1: Create two branches of the project: one supporting accessories, and one for older phones.

Pro: Keeps things clean, and I could just designate one project as the phones-only one, and the other as tablets-only.

Con: Requires that I set up a Library project or work up some kind of custom build script so I don't have to duplicate all of my code across two projects.

Solution #2: Use reflection to manually load the necessary classes at runtime, and throw an exception if the class does not exist.

Pro: I can maintain backwards compatibility without having to make multiple projects.

Con: It seems a little messy/hacky

So in a nutshell... how can I use a package that only exists in API level 12 and up, but still have the app run on earlier versions?

Any advice would be greatly appreciated. Thanks!

bmat
  • 2,084
  • 18
  • 24

1 Answers1

1

I ended up going with the Library Project solution. A vast majority of the application code was in the Library project, but everything related to Open Accessory was moved to its own project. It actually ended up being pretty easy to maintain since so much code was shared. No complicated build scripts required!

bmat
  • 2,084
  • 18
  • 24