Fair enough. Looks like my little plan is dead in the water unless I try something as daunting as what Kostya suggested.
-1 on my ego +1 on my learning This has been educational in more ways than one. Thanks. On Friday, March 23, 2012 2:31:56 PM UTC-6, Dianne Hackborn wrote: > > The platform never looks at maxSdkVersion. The entire concept of > maxSdkVersion is broken as shown by what you are trying to do -- having > your apps suddenly not work when you get a platform update just because > they have declared a maxSdkVersion in their manifest is a horrible user > experience. > > This is why the documentation for maxSdkVersion at > http://developer.android.com/guide/topics/manifest/uses-sdk-element.html<http://developer.android.com/guide/topics/manifest/uses-sdk-element.html>says > with a red line that you shouldn't use it. > > Anyway, from 2.0.1 and on the platform never even looks at this attribute, > so there is no easy way for you to retrieve it. > > On Fri, Mar 23, 2012 at 12:13 PM, exiquio <[email protected]> wrote: > >> 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 >> android-developers@googlegroups.com<[email protected]> >> To unsubscribe from this group, send email to >> android-developers+[email protected]<android-developers%[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> >> > > > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. > > -- 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
