Update targetSDK to ICS

[GoogleCodeExporter]

targetSDK is a setting that tells the framework an app has been tested on the 
given version, and is OK with the behavioural changes that result. It's a way 
to phase in backwards incompatible changes so they don't break old apps.

By updating targetSDK from Honeycomb, we get a bunch of bugfixes and these 
things:

http://developer.android.com/reference/android/os/Build.VERSION_CODES.html#ICE_C
REAM_SANDWICH

* For devices without a dedicated menu key, the software compatibility menu key 
will not be shown even on phones. By targeting Ice Cream Sandwich or later, 
your UI must always have its own menu UI affordance if needed, on both tablets 
and phones. The ActionBar will take care of this for you.

* 2d drawing hardware acceleration is now turned on by default. You can use 
android:hardwareAccelerated to turn it off if needed, although this is strongly 
discouraged since it will result in poor performance on larger screen devices.

(this may help a lot!)

* The default theme for applications is now the "device default" theme: 
Theme_DeviceDefault. This may be the holo dark theme or a different dark theme 
defined by the specific device. The Theme_Holo family must not be modified for 
a device to be considered compatible. Applications that explicitly request a 
theme from the Holo family will be guaranteed that these themes will not change 
character within the same platform version. Applications that wish to blend in 
with the device should use a theme from the Theme_DeviceDefault family.

* App Widgets will have standard padding automatically added around them, 
rather than relying on the padding being baked into the widget itself.

By updating to the JellyBean targetSDK, we also get:

* NfcAdapter.setNdefPushMessage, NfcAdapter.setNdefPushMessageCallback and 
NfcAdapter.setOnNdefPushCompleteCallback will throw IllegalStateException if 
called after the Activity has been destroyed.

(i wonder if that's the behavior change you saw?)

Original issue reported on code.google.com by hearn@google.com on 17 Jul 2012 at 4:24

[GoogleCodeExporter]

Thanks. I'm well aware of all these changes.

The question is, what concrete advantages will we have?

For example, hardware acceleration can be enabled also on Honeycomb and sure I 
did this the moment I raised target to Honeycomb. (Actually is was the reason I 
raised target to Honeycomb.)

The software comptibility menu key has also been gone for some months. Same 
with the theme: Just one switch in my own theme.

Original comment by andreas....@gmail.com on 17 Jul 2012 at 4:34

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

[GoogleCodeExporter]

The enhanced NFC API on ICS+ would be a little bit of an incentive to raise 
target SDK. However, this would mean to ditch NFC support for Gingerbread 
users. Does anyone know if there are still Gingerbread devices around with NFC? 
The Nexus S has been lifted to ICS+ long ago. I have had in my hand two Intel 
devices (running on Gingerbread), but did they actually make it to market?

Altogether, this is just a small optimization to NFC support. There is nothing 
you can't do with the Gingerbread API, its just that ICS adds some convenience 
methods.

Original comment by andreas....@gmail.com on 18 Jul 2012 at 9:19

[GoogleCodeExporter]

I'm not sure why it'd involve dropping support for NFC on Gingerbread? 
targetSDK doesn't mean you have to use newer APIs.

Original comment by hearn@google.com on 18 Jul 2012 at 9:30

[GoogleCodeExporter]

Sure, but if I don't use the incentive is gone (-:

Original comment by andreas....@gmail.com on 18 Jul 2012 at 10:01

[GoogleCodeExporter]

Well, as I said, it enables behaviors that are desirable but can't be enabled 
safely by default because it might break apps. If the app doesn't break, you 
want to be on the latest targetSDK. For instance to get the hardware 
acceleration.

There's no really no reason to ever use a low targetSDK value, unless the app 
relies on framework quirks or behaviours that were changed.

Original comment by hearn@google.com on 18 Jul 2012 at 10:03

[GoogleCodeExporter]

You know, I have made good experience with /not/ just doing everything "because 
we can". There must be a good incentive to change things. I'd like to keep it 
that way.

As I said, hardware acceleration is already available from Honeycomb on and 
sure its enabled.

Original comment by andreas....@gmail.com on 18 Jul 2012 at 10:53

[GoogleCodeExporter]

Are you sure? I think unless you added an attribute to the activities then it's 
not on by default because it can break apps. By setting targetSDK to ICS+ you 
are telling the system you tested the app and it draws correctly. That's how I 
read the Build.VERSION_CODES documentation.

Original comment by hearn@google.com on 18 Jul 2012 at 10:59

[GoogleCodeExporter]

Yes. You can enable/disable HA on app level, activity level, window level or 
even view level. Bitcoin Wallet has it enabled on app level since April.

All the switch from HC to ICS does is change the default on app level.

http://developer.android.com/guide/topics/graphics/hardware-accel.html

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

[GoogleCodeExporter]

Ah, OK then.

Original comment by hearn@google.com on 18 Jul 2012 at 11:16

[GoogleCodeExporter]

Marking this as invalid because it is no issue on its own. It will happen at 
some time, but not just "because we can".

Original comment by andreas....@gmail.com on 12 Apr 2013 at 11:08

• Changed state: Invalid