Monday, November 2, 2009

Re: [android-developers] Re: Android WVGA support

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 <p.artem@gmail.com> 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 <webmonkey18@gmail.com> 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 <devuni...@gmail.com> 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 <p.ar...@gmail.com> 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 <p.ar...@gmail.com> 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 <hack...@android.com>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 <p.ar...@gmail.com> 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 <p.ar...@gmail.com> 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 <webmonke...@gmail.com>
> >>>> 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 <hack...@android.com> 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 <codesec...@gmail.com>
> >>>> wrote:
>
> >>>> > > > > Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
>
> >>>> > > > > On Oct 22, 8:38 am, Nikolay Ananiev <devuni...@gmail.com>
> >>>> 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
> >>>> > > > hack...@android.com
>
> >>>> > > > 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
> >>> hack...@android.com
>
> >>> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---




--
Dianne Hackborn
Android framework engineer
hackbod@android.com

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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

No comments:

Post a Comment