Thanks for this response, I didn't mean to come off as rude but I was more frustrated than anything, I did some long thinking and approached my drawables differently, There are redundancies yes but I suppose no system is going to be perfect stretching over 4 SDKs.
I know it might not seem like much but having a detailed response like this makes a lot more sense than just a single sentence in the new features list. It helps to know how you guys are thinking about things. Anyway, from my extensive testing to get to where I am, I did uncover many bugs, some I knew, some are new (to me), so now I agree with your stance to take the plunge and fix it once :) Otherwise I can see how the problem would of just got worse and worse. At least the behaviour will be consistent now :) Thanks Dianne. On Dec 6, 4:37 am, Dianne Hackborn <[email protected]> wrote: > On Fri, Dec 4, 2009 at 5:17 PM, adamphillips12 > <[email protected]>wrote: > > > "It was documented like so "The SDK version supported by the device, > > for example v3. The Android 1.0 SDK is v1, the 1.1 SDK is v2, and the > > 1.5 SDK is v3.", if that was supposed to imply that a device supported > > its most recent sdk version and perhaps older versions (in terms of > > the resource system), then the documentation itself could probably > > have been made more clear. All the wording and the examples suggest > > the implication that a device has one and only one SDK version it > > identifies with, e.g. 1.5 identifies only with v3, if not present it > > uses default (given no other qualifiers), otherwise it would of read > > "The SDK versions...", the 's' has quite some significance. Obviously > > the new "or higher" clause can not follow this single SDK definition, > > it is a behavioural change, not merely a fix of the documented > > functionality." > > I can certainly make the documentation more clear, but the 2.0.1 behavior is > entirely the intended behavior, and is consistent with other uses of the API > version such as in minSdkVersion and targetSdkVersion. > > Also the previous behavior is simply -not- useful. For example, the typical > reason one to use this is to select different resources to match changes in > newer versions of the platform. The two main examples to date: > > - As of v4, there are new configurations for screens. If you use these, you > want to also use -v4 to ensure that older versions of the platform (which > don't know about this differentiation) don't accidentally pick up your > resources, for example, for small screens. > > - As of v5, there is a change in the standard look of some things. You can > use a -v5 (actually -v6 because of another bug in 2.0) variation to switch > to different variations of your graphics or colors to match the new UI. > > In both cases, with the old pre-2.0.1 behavior, each time there is a new > platform update it breaks your use of this. So when 2.0 appeared, you > needed to add duplicate -v6 resources for the first cases, or else the > platform wouldn't see your resources that are using -v4 to prevent older > platforms from seeing them. And that would happen again for each following > platform update. > > The new behavior in 2.0.1 is completely how we want this to work, it caused > a ton of problems for developers that it didn't work as intended previously, > and now it is fixed. > > -- > 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
