How to make my project compatible with different sdk versions while using features for an specific version

Question

I'm developing a project that uses a Flash video within a webview. I solved all my problems regarding to code, but only worked below Honeycomb.

Reading this I found out how to solve the problems for Android 3.0 and later (including ICS), but now it's the big question... If I make my project compatible with ICS I've got to use the directive, but then I wouldn't run on Gingerbread.

To provide some more info... the problematic piece of code is this one:

android:hardwareAccelerated="true"

which is a property that was included in Android 3.0.

So, is there anything I can do to avoid building two different apks (somehitng like a pre-HoneyComb apk and post-HoneyComb apk)?

This is a piece of my Android manifest:

<application android:label="@string/app_name" 
             android:icon="@drawable/elabora"
             android:theme="@android:style/Theme.NoTitleBar">
    <activity android:name="es.fundacionvodafone.elabora.android.controlador.InicioElaboraTest"
              android:label="@string/app_name"
              android:noHistory="true">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>
    <activity android:name="es.fundacionvodafone.elabora.android.controlador.InicioElabora"
              android:configChanges="orientation|keyboardHidden"
              android:label="@string/app_name"  
              android:hardwareAccelerated="true">
            <!--            
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
            -->
    </activity>

Thanks in advance.

Update: I was already using what Mike explained, it's to say, defining minSdk and targetSdk properly, but I was confused by the following fact. With such a project configuration, when you run the project in eclipse, it prompts the following window: The red cross means that the project targetSdk level is above the device API level. So I thought it was just not working in this device, but the thing is you can actually run it, and works as expected.

Answer 1

The comment posted by the OP below his question (basically stating that the targetSDK doesn't affect the compiling of an app) is entirely wrong! Sorry to be blunt.

In short, here is the purpose to declaring a different targetSDK from the minSDK: It means you are using features from a higher level SDK than your minimum, but you have ensured backwards compatibility. In other words, imagine that you want to use a feature that was only recently introduced, but that isn't critical to your application. You would then set the targetSDK to the version where this new feature was introduced and the minimum to something lower so that everyone could still use your app.

To give an example, let's say you're writing an app that makes extensive use of gesture detection. However, every command that can be recognised by a gesture can also be done by a button or from the menu. In this case, gestures are a 'cool extra' but aren't required. Therefore you would set the target sdk to 7 ("Eclair" when the GestureDetection library was introduced), and the minimumSDK to level 3 ("Cupcake") so that even people with really old phones could use your app. All you'd have to do is make sure that your app checked the version of Android it was running on before trying to use the gesture library, to avoid trying to use it if it didn't exist. (Admittedly this is a dated example since hardly anyone still has a v1.5 phone, but there was a time when maintaining compatibility with v1.5 was really important.)

To give another example, you could use this if you wanted to use a feature from Gingerbread or Honeycomb. Some people will get the updates soon, but many others, particularly with older hardware, might stay stuck with Eclair until they buy a new device. This would let you use some of the cool new features, but without excluding part of your possible market.

There is a really good article from the Android developer's blog about how to use this feature, and in particular, how to design the "check the feature exists before using it" code I mentioned above.

To the OP: I've written this mainly for the benefit of anyone who happens to stumble upon this question in the future.

Answer 2

I have similar problem with versioning the android manifest. For older phones I want to have widgets in a few predefined sizes, for newer phones that support resizing I want to have a single resizeable widget. Could not find yet a way to do it. Possibly this is why Google came with multiple APK support.

The Adam's Powell article mentioned above does not address this kind of versioning. (great article BTW).

Edit: got a solution. The widgets definition in the android manifest have a boolean 'enabled' attibute that can be set from boolean resource values. The resource values can have per version values using the standard version qualified resource directory names. Problem solved.