But what does the targetSdk have to do with the stated goal?
>>
present them with a clear picture of what should and should not run on
their device in the event that they update to a newer build of Android
<<
An app with targetSdk set to 4 should run on API 15, Android 4.0.3, and
hopefully beyond (or may not, although this should be very rare).
An app with targetSdk set to 15 most likely will run older Android
version, depending on how it was constructed.
At this time, given what a small portion of devices runs Android 3.0 and
above, most developers try to, and do, achive this. And if a particular
app only goes so far in supporting older Android versions, that would be
specified in the manifest as minSdkVerison, not targetSdkVerison.
Checking minSdkVersion for a prospective firmware update is moot - if an
app is already on the device, it means it passed the minSdkVersion
check. And since firmware, usually (?) gets updated to a later version
rather than goes backwards, any installed apps will continue to pass the
minSdkVersion check.
Then there are cases where the targetSdkVerison is deliberately not set
to the highest possible value.
This last one is from personal experience - I've decided to compile two
of my apps with SDK 4.0.3 to use the "action bar on the bottom" thing,
and yet kept the targetSdkVersion at 13 because I can't stand how
Android 4.0 adds its own padding to widgets if you target it.
Perhaps a better test would be to check for undocumented APIs that are
known to have disappeared in a particular Andorid version, but just
collecting the data for this type of checking is going to be a large task.
-- K
On 03/23/2012 10:29 PM, Chris Stratton wrote:
Oh, sorry, didn't see that the specific information you need is part
of what is available from stable APIs.
On Friday, March 23, 2012 2:26:44 PM UTC-4, Chris Stratton wrote:
On Thursday, March 22, 2012 10:55:00 PM UTC-4, exiquio wrote:
My intent is to write and app that pulls the targetSdkVersion
from all of a user's installed apps in order to present them
with a clear picture of what should and should not run on
their device in the event that they update to a newer build of
Android. This in response to a user's question on XDA. I did a
cursory search and decided it wasn't impossible and that I
should just write something like that as I continue to learn
the platform.
Non-portably, at least as of the last time I tried something
similar you can get the apk code paths out of packages.xml, open
the apk's as zip files, demangle the binary manifests (there's
code for that on the net) and pull out the information you seek.
Doing so becomes marginally off topic for this group, but
probably still of interest to your chosen target audience.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
