Update targetSdkVersion

[GoogleCodeExporter]

I'd like to understand the issues that prevent that. I can go file internal 
bugs against the Android team if necessary.

Alternatively, could you provide one package with an updated targetSdkVersion 
for newer phones, and a different one for older phones?

Original issue reported on code.google.com by hearn@google.com on 10 Feb 2012 at 7:57

[GoogleCodeExporter]

Going up with targetSdkVersion means that Eclipse links against higher SDK, 
while the app still can run under older SDKs (limited by minSdkVersion). 
Extreme care must be taken to not use API that you may not use, or 
MethodNotFound/ClassNotFound exceptions will be thrown. Generally I prefer 
staying at lower targetSdkVersions (ideally target == min) and use higher API 
by reflection.

Providing two packages is PITA to maintain.

The Android team should provide an action bar implementation in the 
compatibility pack, including all the Holo artworks. This would allow for true 
backwards compatibility, perhaps even back to Android 1.6.

Original comment by andreas....@gmail.com on 10 Feb 2012 at 11:18

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I think they don't do that because it would also change the UI paradigm on 
older phones. You'd have a mix of menu button designs and action bar designs.

Is it possible to set targetSdkVersion to the latest only for testing/release, 
but keep it lower for development? That should shake out accidental usages of 
new APIs but keep you opted in to bugfixes and ui updates on newer platforms.

Original comment by hearn@google.com on 11 Feb 2012 at 8:31

[GoogleCodeExporter]

re: UI paradigm

Action bars have been used and recommended since Android 2.1/2.2. I don't see 
what an "official" backport would change in this respect. IMHO it would help 
improve consistency on Android 2.x and - most important - on Android 3+.

Also, the Android team backported ViewPagers. This is arguably also an UI 
paradigm "from the future", planted into older UIs. Why did they do that?

re: different targetSdkVersion for development

targetSdkVersion changes many defaults. That could cause troubles if the 
majority of testing happens with the development version.

Also, if the reason for raising your target is being able to reference a system 
resource, not raising the target in the development version would not work.

That said, for Bitcoin Wallet, I'm considering to be a bit more experimental. 
I'm already targetting API level 10 in order to get NFC. If the ICS release of 
ActionBarSherlock (v4.x) actually only forces API level 11 (Android 3), I'd 
probably take the pill and dump my own (very incomplete) action bar 
implementation.

Original comment by andreas....@gmail.com on 11 Feb 2012 at 12:26

[GoogleCodeExporter]

ABS 4 has been released for a while and Bitcoin Wallet is now using it. For 
this to work, targetSdkVersion was advanced to above what the majority of users 
is using (sdk level 11 rather than 10).

Original comment by andreas....@gmail.com on 12 May 2012 at 9:27

• Changed state: Fixed