1.5 already had some of the initial density support, including simple density matching (it just checked for exact matches to density, rather than considering scaling factors as the final implementation in 1.6 does), so this should work fine.
On Mon, Nov 2, 2009 at 12:11 PM, webmonkey <[email protected]> wrote: > Thanks for the clarification Dianne. > > Is it also OK to use my solution with the normal 1.5 resolution > bitmaps in drawable-mdpi and the high resolution bitmaps in drawable- > hdpi. For some reason the 1.5 emulator correctly gets the bitmaps from > the drawable-mdpi folder if you don't use drawable-ldpi. It seems to > work fine. > > On Nov 2, 8:39 pm, Dianne Hackborn <[email protected]> wrote: > > Yes there are bugs in the version matching. I just submitted a fix that > > should go into the first OTA update for Droid; the current 2.0 should > only > > ever ship on Droid, and be replaced with an update at that point, so > > hopefully this will not be a long-term problem. > > > > In the meantime, the work-around is to have the resources as both -v4 and > > -v6. I know that is a pain; I am very sorry. (For those curious, there > are > > two problems: first when the version matching was implemented, this was a > > late addition to 1.0 "just in case," and was implemented as a simple > > comparison because the semantics hadn't yet been defined. Now when we > are > > actually using it, we've discovered the code never code fully implemented > > with the correct semantics. On top of that, there was a change done late > in > > 2.0 so that "development builds" would match the next version number for > > resources, which I messed up and thus broke the final release > versioning.) > > > > On Fri, Oct 30, 2009 at 10:06 AM, Artem Petakov <[email protected]> > wrote: > > > Right, you have to use -v4 for that of course. It's similar to what > Dianne > > > had suggested above (using both -v4 and -v5), except v5 is actually v6. > It > > > just seems that somewhere deep in this part of the Eclair code there is > > > something that makes it think that the sdkVersion is 6, not 5. Dianne, > could > > > you please comment since this is the only workaround that works so far? > > > > > I would love to find this out myself, but since the Eclair code is not > yet > > > available, it's hard to figure this out. I'm assuming the code drop is > > > coming soon. > > > > > I have verified that by using both -v4 and -v6, I can get things to > work on > > > every platform. > > > > > For those interested, to avoid duplicating actual pngs/jpgs, I am using > an > > > ugly hack. Here is an example > > > > > Folder drawable-160dpi: > > > example_image.png (the mdpi version of image) > > > > > Folder drawable-240dpi-v4: > > > XML file "example_image.xml" with the following inside: > > > <bitmap xmlns:android="http://schemas.android.com/apk/res/android"; > android:src="@drawable/example_image_hdpi" > > > /> > > > > > Folder drawable-240dpi-v6: > > > Same "example_image.xml" with the following inside: > > > <bitmap xmlns:android="http://schemas.android.com/apk/res/android"; > android:src="@drawable/example_image_hdpi" > > > /> > > > > > Folder drawable-nodpi: > > > example_image_hdpi.png (the hdpi version of image) > > > > > Yes, it's very ugly. Any better ideas are very welcome. > > > > > Artem > > > > > On Fri, Oct 30, 2009 at 1:36 PM, webmonkey <[email protected]> > wrote: > > > > >> drawable-hdpi-v6 does indeed work in the 2.0 emulator but not in a 1.6 > > >> emulator. And because it is not exactly clear what the problem is I do > > >> not recommend using it. > > > > >> I am still hoping to find a solution where I can just use drawable- > > >> hdpi > > > > >> On Oct 30, 8:49 am, Nikolay Ananiev <[email protected]> wrote: > > >> > YES drawable-hdpi-v6 works for me too. I'll use it in my next > release as > > >> a > > >> > workaround > > >> > Thanks Artem! > > > > >> > On Fri, Oct 30, 2009 at 7:15 AM, Artem Petakov <[email protected]> > > >> wrote: > > >> > > This will sound crazy, but -v6 works for me. There must be a > strange > > >> reason > > >> > > why this works, or maybe there is a subtle reason why this > workaround > > >> does > > >> > > not work. Can anyone confirm? > > > > >> > > On Thu, Oct 29, 2009 at 11:22 PM, Artem Petakov < > [email protected]> > > >> wrote: > > > > >> > >> Ah, that's too bad. Bugs happen. > > > > >> > >> I am trying to understand the solution... Somehow having a -v5 > > >> version in > > >> > >> there does not help (as webmonkey reported). I don't have my head > > >> around > > >> > >> this fully, but I think Android somehow prefers the regular > > >> "drawable" > > >> > >> directory (which I have for the Cupcake crowd). What is the > > >> recommended set > > >> > >> of drawable directories at this point? > > > > >> > >> Artem > > > > >> > >> On Thu, Oct 29, 2009 at 10:29 PM, Dianne Hackborn < > > >> [email protected]>wrote: > > > > >> > >>> Dammit yeah that would be broken. I'll make sure this is fixed > in > > >> the > > >> > >>> next version; for now i guess you will need to include both -v4 > and > > >> -v5 > > >> > >>> resources. > > > > >> > >>> On Thu, Oct 29, 2009 at 7:25 PM, Artem <[email protected]> > wrote: > > > > >> > >>>> Trying to help by digging up the code. > > > > >> > >>>> I found this: > > > > >>http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#uX1GffpyOZk/. > .. > > > > >> > >>>> // Return true if 'this' can be considered a match for the > > >> > >>>> parameters in > > >> > >>>> // 'settings'. > > >> > >>>> // Note this is asymetric. A default piece of data will > match > > >> > >>>> every request > > >> > >>>> // but a request for the default should not match odd > specifics > > >> > >>>> // (ie, request with no mcc should not match a particular > mcc's > > >> > >>>> data) > > >> > >>>> // settings is the requested settings > > >> > >>>> inline bool match(const ResTable_config& settings) const { > > >> > >>>> ... > > > > >> > >>>> if (version != 0) { > > >> > >>>> if (settings.sdkVersion != 0 && sdkVersion != 0 > > >> > >>>> && sdkVersion != settings.sdkVersion) { > > >> > >>>> return false; > > >> > >>>> } > > >> > >>>> if (settings.minorVersion != 0 && minorVersion != 0 > > >> > >>>> && minorVersion != settings.minorVersion) { > > >> > >>>> return false; > > >> > >>>> } > > >> > >>>> } > > >> > >>>> return true; > > >> > >>>> } > > > > >> > >>>> Of course I am not sure where this is used, but I only see an > != > > >> here. > > >> > >>>> Hopefully, this is not the right code. Or perhaps there is new > code > > >> in > > >> > >>>> Eclair that is not available yet, that makes this better. > > > > >> > >>>> Thanks for the help. > > > > >> > >>>> Artem > > > > >> > >>>> On Oct 29, 9:12 pm, Artem Petakov <[email protected]> wrote: > > >> > >>>> > Dianne, I am sorry to say it also does not work for me. > Actually, > > >> we > > >> > >>>> had > > >> > >>>> > made a mistake and originally forgot the v4, which screwed up > > >> Cupcake, > > >> > >>>> but > > >> > >>>> > now we added the v4 (and make no other changes), and it > stopped > > >> > >>>> working. > > > > >> > >>>> > Am I missing something? Or is there perhaps a serious > problem? > > >> Please > > >> > >>>> reply > > >> > >>>> > back so we can take action -- we need to publish a new APK > for > > >> the > > >> > >>>> Cupcake > > >> > >>>> > users, but we can't figure out how to do that without > breaking > > >> Eclair. > > > > >> > >>>> > Artem > > > > >> > >>>> > On Thu, Oct 29, 2009 at 11:00 AM, webmonkey < > > >> [email protected]> > > >> > >>>> wrote: > > > > >> > >>>> > > Hi Dianne, > > > > >> > >>>> > > The v flag does indeed not work, I am using the Android 2.0 > SDK > > >> with > > >> > >>>> > > the following AndroidManifest settings: > > > > >> > >>>> > > <uses-sdk > > >> > >>>> > > android:minSdkVersion="3" > > >> > >>>> > > android:targetSdkVersion="5" > > >> > >>>> > > /> > > > > >> > >>>> > > Running on a WVGA854 emulator with density 240 and API 5, I > get > > >> the > > >> > >>>> > > following results: > > > > >> > >>>> > > drawable-hdpi-v4 > > > > >> > >>>> > > is ignored > > > > >> > >>>> > > drawable-hdpi-v5 > > > > >> > >>>> > > is ignored, very strange > > > > >> > >>>> > > drawable-hdpi > > > > >> > >>>> > > works, but we can't use that > > > > >> > >>>> > > On Oct 29, 3:45 pm, Dianne Hackborn <[email protected]> > > >> wrote: > > >> > >>>> > > > I am pretty positive it works. Nothing changed in 2.0 -- > > >> this has > > >> > >>>> been > > >> > >>>> > > the > > >> > >>>> > > > same since 1.0, if the platform's SDK version is < the > > >> resource > > >> > >>>> version, > > >> > >>>> > > > then the resource is ignored. > > > > >> > >>>> > > > On Wed, Oct 28, 2009 at 5:28 PM, Jeff < > [email protected]> > > >> > >>>> wrote: > > > > >> > >>>> > > > > Looks like -v4 flag doesn't work in Android 2.0. Any > ideas? > > > > >> > >>>> > > > > On Oct 22, 8:38 am, Nikolay Ananiev < > [email protected]> > > >> > >>>> wrote: > > >> > >>>> > > > > > This is how I made my app resolution-independent and > with > > >> > >>>> Android 1.5 > > >> > >>>> > > > > legacy > > >> > >>>> > > > > > support: > > > > >> > >>>> > > > > > Why did I put my high-dpi images in the > drawable-hdpi-v4 > > >> > >>>> folder and > > >> > >>>> > > not > > >> > >>>> > > > > in > > >> > >>>> > > > > > drawable-hdpi? Because the Android 1.5 OS can't > handle > > >> the > > >> > >>>> -hdpi and > > >> > >>>> > > > > tries > > >> > >>>> > > > > > to use these images instead of the ones in the > > >> res/drawable > > >> > >>>> folder. > > >> > >>>> > > The > > >> > >>>> > > > > -v4 > > >> > >>>> > > > > > flag is only meaningful for Android 1.6 and works > > >> perfect. > > > > >> > >>>> > > > -- > > >> > >>>> > > > 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. > > > > >> > >>> -- > > >> > >>> 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]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > > For more options, visit this group at > > > > ... > > > > read more ยป > > -- > 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]<android-developers%[email protected]> > For more options, visit this group at > 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
