I should have taken a lot more time to both think about the problem and to explain it. My apologies.
>> 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. << I see in the documentation<http://developer.android.com/guide/topics/manifest/uses-sdk-element.html>that new builds of Android are meant to be backwards compatible and I also see a warning about using maxSdkVersion. The above points make sense. >> 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. << If I would have taken my time with the opening post I would have written "I do *not *is how to pull the apps *max* API levels for the SDK as in" (followed by an example of use-sdk with maxSdkVersion instead of my copy and past of targetSdkVersion). It was a poor quality post on my part and I've taken note of such. With that understanding, perhaps its not moot to attempt to pull a maxSdkVersion from an app if its set, but given the strong warning in the aforementioned documentation<http://developer.android.com/guide/topics/manifest/uses-sdk-element.html>, perhaps it is. >> 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. << Note taken. Sounds like I'm on a road to nowhere, but I will give a shot at something if for nothing more than to learn what not to do. Thanks a lot. On Friday, March 23, 2012 12:50:13 PM UTC-6, Kostya Vasilyev wrote: > > 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 > android-developers@googlegroups.com<[email protected]> > To unsubscribe from this group, send email to > android-developers+[email protected]<[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en<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
