Android WVGA support

124 views
Skip to first unread message

Al Sutton

unread,
Sep 7, 2009, 6:16:40 AM9/7/09
to android-d...@googlegroups.com
We've added support for WVGA devices to the AndAppStore using the features from Donut and I'd recommend everyone interested in running their apps on WVGA devices takes a look at the donut SDK because there is a new manifest tag (supports-screens) which, if not used, can make your app look a bit rough.

If you don't use it the docs say "Based on the target device screen density, the Android framework will scale down assets by a factor of 0.75 (low dpi screens) or scale them up by a factor of 1.5 (high dpi screens)." and in our case that meant the icons in the app had zoom performed on them in order to scale them up for WVGA and it looked pretty fuzzy. We've also been told that on some builds of donut the display was limited to a HVGA portion of a WVGA screen with a big black border around it, but I'm not sure how up to date those builds were.

The supports-screens manifest tag appears to be backwards compatible and doesn't cause problems for earlier devices. We're using it in the 1.4.6 version of the AndAppStore client and we've tested it on a few cupcake devices without any problems, and the 1.4.6 release is now public so if you want to test the compatibility you can grab it from http://tinyurl.com/aasclient

Anyway, I thought I'd give you guys a heads up so when donut hits the streets you guys don't start wondering why you're getting comments like "The graphics are poor" or "Everything looks fuzzy".

Hope it's' useful,

Al.

--

* Looking for Android apps?, try http://andappstore.com/ *

======
Funky Android Limited is registered in England & Wales with the
company number  6741909. The registered head office is Kemp House,
152-160 City Road, London,  EC1V 2NX, UK.

The views expressed in this email are those of the author and not
necessarily those of Funky Android Limited, it's associates, or it's
subsidiaries.


broc.seib

unread,
Sep 7, 2009, 5:07:00 PM9/7/09
to Android Developers
I am looking to get my hands on a physical WVGA device for android.
Are any available yet? I saw an old (speculative) post about the HTC
Touch 2 perhaps being an android device, alas, the HTC site says that
device runs windows mobile.

I have found more recent blogging about the SMiT 560, but can't find
it for sale.
http://www.google.com/search?q=SMIT+MID-560
http://www.smit.com.cn/English/proDetail.asp?InfoId=126&js=2

Can anyone shed more light on what/when is available in the WVGA
department for Android?



On Sep 7, 8:16 pm, Al Sutton <a...@funkyandroid.com> wrote:
> We've added support for WVGA devices to the AndAppStore using the features from Donut and I'd recommend everyone interested in running their apps on WVGA devices takes a look at the donut SDK because there is a new manifest tag (supports-screens) which, if not used, can make your app look a bit rough.
>
> If you don't use it the docs say "Based on the target device screen density, the Android framework will scale down assets by a factor of 0.75 (low dpi screens) or scale them up by a factor of 1.5 (high dpi screens)." and in our case that meant the icons in the app had zoom performed on them in order to scale them up for WVGA and it looked pretty fuzzy. We've also been told that on some builds of donut the display was limited to a HVGA portion of a WVGA screen with a big black border around it, but I'm not sure how up to date those builds were.
>
> The supports-screens manifest tag appears to be backwards compatible and doesn't cause problems for earlier devices. We're using it in the 1.4.6 version of the AndAppStore client and we've tested it on a few cupcake devices without any problems, and the 1.4.6 release is now public so if you want to test the compatibility you can grab it fromhttp://tinyurl.com/aasclient

Mark Murphy

unread,
Sep 7, 2009, 5:12:08 PM9/7/09
to android-d...@googlegroups.com
broc.seib wrote:
> I am looking to get my hands on a physical WVGA device for android.

You and me both.

> Are any available yet?

Soon. I think.

> Can anyone shed more light on what/when is available in the WVGA
> department for Android?

The Archos Internet media tablet is supposed to have WVGA:

http://gizmodo.com/5341242/archos-android-tablet-with-720p-playback-and-mobile-internet-to-launch-september-15th

We should get confirmation of that on the 15th.

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

Android App Developer Books: http://commonsware.com/books.html

Dianne Hackborn

unread,
Sep 7, 2009, 6:15:03 PM9/7/09
to android-d...@googlegroups.com
On Mon, Sep 7, 2009 at 2:12 PM, Mark Murphy <mmu...@commonsware.com> wrote:
broc.seib wrote:
> I am looking to get my hands on a physical WVGA device for android.
You and me both.

There shouldn't be any until WVGA is officially supported in the platform.  That is planned for 1.6, but 1.6 is not yet officially supported, and there is a fair lag from when the platform software is done to new devices being released with it.
 
> Can anyone shed more light on what/when is available in the WVGA
> department for Android?
The Archos Internet media tablet is supposed to have WVGA:
http://gizmodo.com/5341242/archos-android-tablet-with-720p-playback-and-mobile-internet-to-launch-september-15th


Afaik, the Archos tablet is based on 1.5, and thus does not use the official screen support in the 1.6 platform.  I have no idea what exactly they are doing, but unless it is a 1.6-based device, it would be of questionable value for someone wanting to follow the standard platform.

Also the Archos device is a very different type of screen than what you will deal with on a phone: with their tablet, it is a 800x480 5" screen (larger in size but about the same density as G1/myTouch); a phone would be more in the realm of a 800x480 3.5" screen (with about the same size but a significantly higher density than current HVGA devices).  The 1.6 platform will support both of these, representing either a larger screen space to work with (implying differences in layout) or the same space but with more pixels (needing scaling of graphical elements in  the same layout).

--
Dianne Hackborn
Android framework engineer
hac...@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.

Mark Murphy

unread,
Sep 7, 2009, 6:41:40 PM9/7/09
to android-d...@googlegroups.com
Dianne Hackborn wrote:
> There shouldn't be any until WVGA is officially supported in the
> platform. That is planned for 1.6, but 1.6 is not yet officially
> supported, and there is a fair lag from when the platform software is
> done to new devices being released with it.

Uh, no offense, but HTC Magic devices shipped with Android 1.5 right
about when the SDK became available. In Spain, IIRC. You may recall
modest gnashing of teeth over this.

While the core Android team may know timelines vis a vis product
launches, we out here in the hinterlands have to plan for another
possible "here's the SDK! better support it tomorrow!" release.

> Afaik, the Archos tablet is based on 1.5, and thus does not use the
> official screen support in the 1.6 platform. I have no idea what
> exactly they are doing, but unless it is a 1.6-based device, it would be
> of questionable value for someone wanting to follow the standard platform.

If it sells in decent quantity, or looks like it might, whether it is
"the standard platform" or not means little -- we have to know how to
support it. That means some of us will need to get our grubby
medium-sized hands on it, to test apps and advise others. In fact, the
possibility that they *do* deviate from the norm is all the more reason
some of us will need hardware, since we will not be able to rely upon
emulators as much.

As the long-standing Chinese proverb/curse goes: "May you live in
interesting mobile OS platforms" (or something like that)...

_The Busy Coder's Guide to *Advanced* Android Development_
Version 1.1 Available!

Al Sutton

unread,
Sep 8, 2009, 2:14:31 AM9/8/09
to Android Developers
I can see 800x480 on 1.5 as a stop gap measure, so I'm holding off for
1.6 devices before buying 800x480 hardware.

The reason for this is that I could spend time sorting out a 800x480
layout which works on a 1.5 device only to find that all that work
goes out the window when the OEM releases a firmware update to bring
the device to 1.6 and adopts donuts method of layout scaling.

An example of what I've seen in terms of difference between the 1.5
Archos WVGA skin and the 1.6 SDK WVGA skin can be seen with image
sizes; If you have an app which doesn't have a supports-screens tag or
declare a minimum SDK level of 4 (yup, declaring minimum SDK of donut
alters the layout behaviour) and a layout file within it has an
ImageButton containing an image which is 48 pixels high (i.e. 10% of
the screen hight in portrait mode) it's hight is still 48 pixels on
the 1.5 Archos WVGA skin (thus making it only 6% of the screen hight
in portrait mode), but on 1.6 it's scaled so the image ends up being
72 pixels high (thus making it around 9% of the screen hight, closer
to the original).

This means that on a 1.5 WVGA device the layout can look sparse and
odd, whereas on 1.6 it looks a lot closer to what you originally had.

Given the state of the open source repo (I've been using the 1.6 build
from the open repo for a few days and it seems rock solid) I'd suggest
we're in the last weeks of Donut development the useful lifespan of a
1.5 supporting non-HVGA layout is most likley limited.

Al.
> Mark Murphy (a Commons Guy)http://commonsware.com|http://twitter.com/commonsguy

Howard M. Harte

unread,
Sep 8, 2009, 2:22:46 AM9/8/09
to Android Developers


On Sep 7, 3:41 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> Dianne Hackborn wrote:
> > There shouldn't be any until WVGA is officially supported in the
> > platform.  That is planned for 1.6, but 1.6 is not yet officially
> > supported, and there is a fair lag from when the platform software is
> > done to new devices being released with it.
>
> Uh, no offense, but HTC Magic devices shipped with Android 1.5 right
> about when the SDK became available. In Spain, IIRC. You may recall
> modest gnashing of teeth over this.
>
> While the core Android team may know timelines vis a vis product
> launches, we out here in the hinterlands have to plan for another
> possible "here's the SDK! better support it tomorrow!" release.
>
> > Afaik, the Archos tablet is based on 1.5, and thus does not use the
> > official screen support in the 1.6 platform.  I have no idea what
> > exactly they are doing, but unless it is a 1.6-based device, it would be
> > of questionable value for someone wanting to follow the standard platform.
>
> If it sells in decent quantity, or looks like it might, whether it is
> "the standard platform" or not means little -- we have to know how to
> support it. That means some of us will need to get our grubby
> medium-sized hands on it, to test apps and advise others. In fact, the
> possibility that they *do* deviate from the norm is all the more reason
> some of us will need hardware, since we will not be able to rely upon
> emulators as much.

You can download a WVGA emulator skin for the Archos from appslib.com:
http://appslib.com/developers/index.html?disp=full

I tried this today with Al's 1.6 SDK. It reproduced exactly the
problem that I was having testing an app on the LogicPD Zoom2
development kit which also has WVGA. My app showed up in the upper
middle of the screen, with black background all around. When I
changed the AndroidManifest.xml uses-sdk to:
android:minSdkVersion="4"

The problem went away, and now my app uses the entire screen
properly. I tried also adding the following to the
AndroidManifest.xml:
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:anyDensity="true" />

Then I changed back to minSdkVersion="3" to see if the app would still
work properly, but it did not.

Is there a way to make my app use the entire display area, even if I
keep the minSdkVersion="3"?

Thanks,
Howard

Romain Guy

unread,
Sep 8, 2009, 2:29:56 AM9/8/09
to android-d...@googlegroups.com
> ImageButton containing an image which is 48 pixels high (i.e. 10% of
> the screen hight in portrait mode) it's hight is still 48 pixels on
> the 1.5 Archos WVGA skin (thus making it only 6% of the screen hight
> in portrait mode), but on 1.6 it's scaled so the image ends up being
> 72 pixels high (thus making it around 9% of the screen hight, closer
> to the original).

This has nothing to do with WVGA, this is about the pixel density of
the device. I don't remember what we've done in the 1.6 SDK but it
looks like the WVGA skin is using a high density configuration
(probably 240 dpi.) You can very well run the 1.6 emulator in WVGA
with a density that matches Dream/Magic/Hero/Galaxy/etc.

> This means that on a 1.5 WVGA device the layout can look sparse and
> odd, whereas on 1.6 it looks a lot closer to what you originally had.

Android 1.5 actually has limited support for higher and lower
densities. The device has to be built with the information about the
screen density so that images can be scaled accordingly.

If your app is correctly using layouts and not according positions, it
should work fine on a WVGA "normal" density device (screen density of
a Deam, which means a 5" WVGA display.) If you want your app to work
on a high-density or low-density device (for instance a 3" WVGA or a
3" QVGA display,) Android 1.6 will be required.

>If you have an app which doesn't have a supports-screens tag or
>declare a minimum SDK level of 4 (yup, declaring minimum SDK of donut
>alters the layout behaviour)

It doesn't really alter the layout behavior. It takes the app out of
compatibility mode. In compatibility mode, the application runs as if
it was on an HVGA standard density device (a Dream/Magic/etc.) This
way the app works as it's supposed to. When you compile against SDK
level 4, we assume you are aware that you must now support different
resolutions and/or densities. Your app is taken out of compatibility
mode and is laid out based on the actual screen resolution. At this
point, your app is still using a limited compatibility mode: if the
device has a density that is not 160 dpi (or close, a Dream is
actually 180 dpi but is assumed to have 160 dpi,) the bitmap resources
are scaled to match the screen density (a 100x100 bitmap becomes
150x150 on a 240 dpi device, or 75x75 on a 120 dpi device.)

Your job as an app developer is to:
- Make sure your activities layout correctly in various resolutions (HVGA, WVGA)
- Decide whether you want to use assets specific to various screen
densities (drawable-hdpi/ for displays > 160 dpi for instance.)
- Correct possible use of absolute pixel dimensions in your code by
taking into account the screen density (DisplayMetrics.density gives
you the correct scale factor)

Of all those 3 points, the second one is optional. Taking care of it
will make sure your app looks great.

I know this is all complicated and probably confusing (and this email
is light on details and does not cover everything) but when Android
1.6 is released, we'll tell you everything there is to know about
supporting various resolutions and densities.

P.S: Now some of you might understand why we deprecated AbsoluteLayout
to discourage its use :)

--
Romain Guy
Android framework engineer
roma...@android.com

Note: please don't send private questions to me, as I don't have time

to provide private support. All such questions should be posted on

Romain Guy

unread,
Sep 8, 2009, 2:31:34 AM9/8/09
to android-d...@googlegroups.com
> I tried this today with Al's 1.6 SDK.  It reproduced exactly the
> problem that I was having testing an app on the LogicPD Zoom2
> development kit which also has WVGA.  My app showed up in the upper
> middle of the screen, with black background all around.  When I
> changed the AndroidManifest.xml uses-sdk to:
> android:minSdkVersion="4"

This is not a problem, this is your application running in
compatibility mode on a device with the same screen density as a Dream
(160 dpi.) Your application is simply told the screen is actually
WVGA.

--
Romain Guy
Android framework engineer
roma...@android.com

Note: please don't send private questions to me, as I don't have time
to provide private support. All such questions should be posted on

Don Tran

unread,
Sep 8, 2009, 2:37:23 AM9/8/09
to Android Developers
I know this is hard due to ongoing things changing but if it's
possible to give more information on how to deal with various
resolutions and densities, it will be great. Back in the cupcake 1.5
release, developers probably had a week maximum to make changes after
the new SDK was released and before cupcake was released to the
general public.

Maybe consider giving an official preview build only to developers
(similar to how Apple provides a dev release version months before the
actual release to allow developers to better prepare for it) will be
ideal.

On Sep 7, 11:31 pm, Romain Guy <romain...@google.com> wrote:
> > I tried this today with Al's 1.6 SDK.  It reproduced exactly the
> > problem that I was having testing an app on the LogicPD Zoom2
> > development kit which also has WVGA.  My app showed up in the upper
> > middle of the screen, with black background all around.  When I
> > changed the AndroidManifest.xml uses-sdk to:
> > android:minSdkVersion="4"
>
> This is not a problem, this is your application running in
> compatibility mode on a device with the same screen density as a Dream
> (160 dpi.) Your application is simply told the screen is actually
> WVGA.
>
> --
> Romain Guy
> Android framework engineer
> romain...@android.com

Dianne Hackborn

unread,
Sep 8, 2009, 2:40:11 AM9/8/09
to android-d...@googlegroups.com
We're getting things out as fast as we can.  It's not as fast as anyone would like, but it's the best we can do right now.
--
Dianne Hackborn
Android framework engineer
hac...@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.

Al Sutton

unread,
Sep 8, 2009, 3:06:12 AM9/8/09
to Android Developers
I've put some screenshots up to show the differences. The app used was
declared as requiring midSDK 1;

1.5 HVGA : http://download.funkyandroid.net/15hvga.png
1.5 WVGA : http://download.funkyandroid.net/15wvga.png
1.6 WVGA : http://download.funkyandroid.net/16wvga.png

For those in doubt; The 1.6 one isn't zoomed by me, this is what
happens on the 1.6 donut emulator.

I understand the problem is down to pixel densities, but the point I'm
trying to raise is that if a developer does nothing with their app
they should expect differences between a 1.5 WVGA device and a 1.6
WVGA one will differ.

And yes, I understand that 1.5 WVGA isn't supported by Google, but
companies out there are doing it, so as Mark says, it's something that
developers need to make a decision about supporting (even if, like me,
the decision is to do nothing specific for it in the expectation 1.6
will gain traction on WVGA devices before 1.5 gets too settled in).

Al.

On Sep 8, 7:29 am, Romain Guy <romain...@google.com> wrote:
> > ImageButton containing an image which is 48 pixels high (i.e. 10% of
> > the screen hight in portrait mode) it's hight is still 48 pixels on
> > the 1.5 Archos WVGA skin (thus making it only 6% of the screen hight
> > in portrait mode), but on 1.6 it's scaled so the image ends up being
> > 72 pixels high (thus making it around 9% of the screen hight, closer
> > to the original).
>
> This has nothing to do with WVGA, this is about the pixel density of
> the device. I don't remember what we've done in the 1.6 SDK but it
> looks like the WVGA skin is using a high density configuration
> (probably 240 dpi.) You can very well run the 1.6 emulator in WVGA
> with a density that matches Dream/Magic/Hero/Galaxy/etc.
>
> --
> Romain Guy
> Android framework engineer
> romain...@android.com

Al Sutton

unread,
Sep 8, 2009, 3:15:20 AM9/8/09
to Android Developers
Sounds like the LogicPD Zoom2 dev kit is donut based.

If they update to the latest donut build you'll most likley see you
app zoomed as opposed to bordered. The android-x86 guys reported black
bordering on the AndAppStore client on an pre-last friday donut build
which is what started me down this path.

Al.

Romain Guy

unread,
Sep 8, 2009, 3:16:03 AM9/8/09
to android-d...@googlegroups.com
Let me correct this:

>1.5 HVGA
>1.5 WVGA@160dpi
>1.6 WVGA@240dpi

> And yes, I understand that 1.5 WVGA isn't supported by Google, but
> companies out there are doing it, so as Mark says, it's something that
> developers need to make a decision about supporting (even if, like me,
> the decision is to do nothing specific for it in the expectation 1.6
> will gain traction on WVGA devices before 1.5 gets too settled in).

As long as these 1.5 WVGA devices have the same density as a Dream,
there's not much well written apps (i.e. apps using layouts) should
have to do. I would be really surprised if manufacturers started
rolling out devices with a non-default density using Android < 1.6.
This would pretty much guarantee that existing apps would not run on
their device, and I highly doubt that's what they want :)

>
> Al.
>
> On Sep 8, 7:29 am, Romain Guy <romain...@google.com> wrote:
>> > ImageButton containing an image which is 48 pixels high (i.e. 10% of
>> > the screen hight in portrait mode) it's hight is still 48 pixels on
>> > the 1.5 Archos WVGA skin (thus making it only 6% of the screen hight
>> > in portrait mode), but on 1.6 it's scaled so the image ends up being
>> > 72 pixels high (thus making it around 9% of the screen hight, closer
>> > to the original).
>>
>> This has nothing to do with WVGA, this is about the pixel density of
>> the device. I don't remember what we've done in the 1.6 SDK but it
>> looks like the WVGA skin is using a high density configuration
>> (probably 240 dpi.) You can very well run the 1.6 emulator in WVGA
>> with a density that matches Dream/Magic/Hero/Galaxy/etc.
>>
>> --
>> Romain Guy
>> Android framework engineer
>> romain...@android.com
>>
>> Note: please don't send private questions to me, as I don't have time
>> to provide private support.  All such questions should be posted on
>> public forums, where I and others can see and answer them
> >
>



--
Romain Guy
Android framework engineer
roma...@android.com

Xavier Ducrohet

unread,
Sep 8, 2009, 3:29:07 AM9/8/09
to android-d...@googlegroups.com
On Mon, Sep 7, 2009 at 11:29 PM, Romain Guy<roma...@google.com> wrote:
> This has nothing to do with WVGA, this is about the pixel density of
> the device. I don't remember what we've done in the 1.6 SDK but it
> looks like the WVGA skin is using a high density configuration
> (probably 240 dpi.) You can very well run the 1.6 emulator in WVGA
> with a density that matches Dream/Magic/Hero/Galaxy/etc.

Just to confirm to everyone.

The skins are associated to each platform in the SDK.
The skins packaged with Android 1.5 and earlier have no density
associated to them, meaning they'll behave like medium density devices
(160dpi).

The skins packaged with Android 1.6 are the following:
QVGA@120dpi (low)
HVGA@160dpi (med)
WVGA(800&854)@240dpi (high)

When creating an avd from the command (with 'android create avd') you
can override this value. Just say 'yes' to using a custom hardware
config and change the property lcd.density (or something close).

This way you can test all different sorts of resolution/density combos.

Xav

--
Xavier Ducrohet
Android Developer Tools Engineer
Google Inc.

Al Sutton

unread,
Sep 8, 2009, 3:56:06 AM9/8/09
to Android Developers
My problem is basically this; If my monitors dpi stays static why is
the emulated dpi changing between emulator skins?

To me it would make more sense if the dpi of the emulators display
doesn't change unless the developer explictly states they want to
emulate a device with a different DPI.

Al.


On Sep 8, 8:29 am, Xavier Ducrohet <x...@android.com> wrote:

Romain Guy

unread,
Sep 8, 2009, 11:44:14 AM9/8/09
to android-d...@googlegroups.com
> My problem is basically this; If my monitors dpi stays static why is
> the emulated dpi changing between emulator skins?

It has *nothing* to do with your monitor. It's a choice we made
because these densities (120, 160, 240) are the ones likely to be used
by future devices. Like we mentioned earlier, to keep the same density
as a Dream in WVGA, you would need a 5" display. I doubt that many
phones will ship with a 5" display.

It's all about *emulating* phone hardware. The density of your
computer display remains the same, but the emulators emulates the
display density of phones by scaling the pixels accordingly. Actually,
if you know the density of your monitor, you can even pass a flag to
the emulator to set it up so that it will have the same physical size
as an actual phone. For instance, on my Dell 30" monitor, I can use a
monitor density of 96 dpi to make HVGA@160dpi an WVGA@240dpi emulators
show up with the same physical size as my Dream (holding the device
next to the emulators is a simple comparison :).

> To me it would make more sense if the dpi of the emulators display
> doesn't change unless the developer explictly states they want to
> emulate a device with a different DPI.

No. Like I said, 160 dpi at other resolutions means a very different
screen size. I mentioned WVGA/5" already, but now imagine the size of
a QVGA@160dpi display... it would be very tiny. The point is that it
wouldn't help you at all.

Howard M. Harte

unread,
Sep 8, 2009, 12:06:14 PM9/8/09
to Android Developers



> No. Like I said, 160 dpi at other resolutions means a very different
> screen size. I mentioned WVGA/5" already, but now imagine the size of
> a QVGA@160dpi display... it would be very tiny. The point is that it
> wouldn't help you at all.
>

This makes sense, but is there a way to leave minSdk="3" and turn off
compatibility mode, so my app will fill the entire WVGA screen in
medium DPI, since my app already can scale properly? Like I
mentioned, this works fine with minSDk="4" but I don't want to
restrict my app to the v1.6 SDK.

Also, it would be nice to be able to prevent the soft keyboard IME
from forcing full-screen/extract mode for landscape WVGA at medium DPI
since now there is a lot more display real estate, and extract mode
makes less sense.

Thanks,
Howard
> --
> Romain Guy
> Android framework engineer
> romain...@android.com

Dianne Hackborn

unread,
Sep 8, 2009, 1:13:22 PM9/8/09
to android-d...@googlegroups.com
Hi all,

I'm not sure how much it is worth getting into the details of this right now.  There is a blog post being written on the topic of different screen sizes, and we have gone through round after round of work on the underlying model of the platform and how to best explain the way this works, which is reflected in the doc.  I think ultimately it is going to be much more confusing trying to answer questions piecemeal here rather than waiting for the full documentation that is well organized (first covering the concepts being used and way we look at different screen configurations, then how these impact applications, how they can opt out of different compatibility modes, and details of how old and new APIs work in these environments).

Also, please don't base any of your work in this area on 1.5.  There was a lot of half-done stuff in that platform that was early work on supporting these different screen configurations, but it was very incomplete, and in many cases behaves radically different than 1.6.

As usual, our goal is that the bulk of existing apps will just work on the new types of hardware, though with a new wrinkle that on some kinds of screens (smaller) there is no way for the platform to provide compatibility for existing apps so they will be filtered out by market until they are updated.  But this will be covered in the upcoming blog post and documentation.

--
Dianne Hackborn
Android framework engineer
hac...@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.

Al Sutton

unread,
Sep 8, 2009, 1:44:00 PM9/8/09
to Android Developers
Most of the WVGA Android devices I've seen announced are 5" media
tablets.

This has *everything* to do with my monitor because it's what the
emulator is being displayed on. I'm not saying that the dpi of my
monitor should be the same as the dpi of the emulator, what I am
saying is if I open an QVGA, HVGA, or WVGA sized window in the native
OS the dpi stays the same, therefore if I request a QVGA, HVGA, or
WVGA sized screen for the emulator and it opens a QVGA, HVGA, or WVGA
sized window I wouldn't expect the emulator to start changing the dpi
*as well* without either asking or warning me.

Al.
> romain...@android.com

Romain Guy

unread,
Sep 8, 2009, 1:52:55 PM9/8/09
to android-d...@googlegroups.com
> This has *everything* to do with my monitor because it's what the
> emulator is being displayed on. I'm not saying that the dpi of my
> monitor should be the same as the dpi of the emulator, what I am
> saying is if I open an QVGA, HVGA, or WVGA sized window in the native
> OS the dpi stays the same, therefore if I request a QVGA, HVGA, or
> WVGA sized screen for the emulator and it opens a QVGA, HVGA, or WVGA
> sized window I wouldn't expect the emulator to start changing the dpi
> *as well* without either asking or warning me.

It still has NOTHING to do with your monitor. The emulator emulates
*phones.* What matters is the density of the *phones.* You're not
choosing the resolution of a window on your computer, you are choosing
the resolution of a phone display you want to emulate.

--
Romain Guy
Android framework engineer

roma...@android.com

Xavier Ducrohet

unread,
Sep 8, 2009, 2:24:29 PM9/8/09
to android-d...@googlegroups.com
On Tue, Sep 8, 2009 at 10:44 AM, Al Sutton<a...@funkyandroid.com> wrote:
>
> Most of the WVGA Android devices I've seen announced are 5" media
> tablets.
>
> This has *everything* to do with my monitor because it's what the
> emulator is being displayed on.

Not really. The emulator, by default, displays the framebuffer and
that's it. So only the resolution matters. It doesn't give you any
idea of the screen size being displayed.
As Romain mentioned, using -scale <your monitor dpi>dpi will scale the
emulator to roughly emulate the actual screen size.
Using '-scale 96dpi' on a WVGA@160dpi and WVGA@240dpi will result in
different scaling.

> I'm not saying that the dpi of my
> monitor should be the same as the dpi of the emulator, what I am
> saying is if I open an QVGA, HVGA, or WVGA sized window in the native
> OS the dpi stays the same, therefore if I request a QVGA, HVGA, or
> WVGA sized screen for the emulator and it opens a QVGA, HVGA, or WVGA
> sized window I wouldn't expect the emulator to start changing the dpi
> *as well* without either asking or warning me.

Actually your are warned (kinda).

When you create an AVD based on android 1.6, at the end it'll tell you
it created it with the following hardware config:
hw.lcd.density=240

We should probably make it more obvious, but then we'd probably need
make the whole hardware config more obvious. For example, hat tablet
you keep referring to has no navigation buttons (d-pad/trackball) and
yet the emulator will emulate one.

Dianne Hackborn

unread,
Sep 8, 2009, 2:33:17 PM9/8/09
to android-d...@googlegroups.com
On Tue, Sep 8, 2009 at 10:44 AM, Al Sutton <a...@funkyandroid.com> wrote:
Most of the WVGA Android devices I've seen announced are 5" media
tablets.

I suspect most companies aren't going to announce things until they at least know that the platform code they need to support them (and thus the ability to run Market) is there. ;)

Ultimately, I don't know whether there will be more WVGA normal density vs. WVGA high density devices around.  My guess, however, would be that given the number of phones sold vs. things like tablets, that the more common screen will be a high density WVGA.  Who knows, though, maybe tablets may take off and sell better than smart phones with high density screens.

And this all ignores what is to me probably likely to be an even bigger part of the market, lower density QVGA and WQVGA screens.

--
Dianne Hackborn
Android framework engineer
hac...@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

unread,
Sep 8, 2009, 3:34:17 PM9/8/09
to android-d...@googlegroups.com
On Tue, Sep 8, 2009 at 11:33 AM, Dianne Hackborn <hac...@android.com> wrote:
And this all ignores what is to me probably likely to be an even bigger part of the market, lower density QVGA and WQVGA screens.

One of the important things to know about the QVGA devices like this is that none of the existing apps will show up on the market there, because until 1.6 developers have had no requirement to design for a smaller screen, and there is little the platform can do to make existing apps work on a smaller screen with a good experience.  (Note that this is different for WQVGA screens, which are actually larger than the G1, just lower density, which is something the platform can easily account for with reasonable results.)

Anyway, as an app developer, I think it would be worth considering getting my applications to work on QVGA as the first priority.  At the minimum this means either <uses-sdk android:targetSdkVersion="4" /> or <supports-screen android:smallScreens="true" android:anyDensity="true" /> in the manifest, and then doing whatever fiddling of the UI is required to make it fit on the smaller QVGA screen.  (Note you can also supply alternative layouts in the layout-small directory.)  You'll also probably want to create low density graphics and place those in drawable-ldpi.

Again, there should be a blog post soon that goes into much more detail on this topic.

Al Sutton

unread,
Sep 8, 2009, 4:21:24 PM9/8/09
to Android Developers
The SDK docs in the open source repo say;

"Based on the target device screen density, the Android framework will
scale down assets by a factor of 0.75 (low dpi screens)..."

And the default QVGA skin is a low density one.

Just to be clear; are you saying that the device won't show in market
because it's a standard DPI and low resolution screen, or are you
saying they'll be blocked just because apps don't explicityly say they
support QVGA?

From the docs in the open repo SDK I would have expected apps to be
available and scaled down using the 0.75 factor.

Al.

On Sep 8, 8:34 pm, Dianne Hackborn <hack...@android.com> wrote:
> On Tue, Sep 8, 2009 at 11:33 AM, Dianne Hackborn <hack...@android.com>wrote:
>
> > And this all ignores what is to me probably likely to be an even bigger
> > part of the market, lower density QVGA and WQVGA screens.
>
> And speaking of...  http://www.htc.com/www/product/tattoo/overview.html
>
> One of the important things to know about the QVGA devices like this is that
> none of the existing apps will show up on the market there, because until
> 1.6 developers have had no requirement to design for a smaller screen, and
> there is little the platform can do to make existing apps work on a smaller
> screen with a good experience.  (Note that this is different for WQVGA
> screens, which are actually larger than the G1, just lower density, which is
> something the platform can easily account for with reasonable results.)
>
> Anyway, as an app developer, I think it would be worth considering getting
> my applications to work on QVGA as the first priority.  At the minimum this
> means either <uses-sdk android:targetSdkVersion="4" /> or <supports-screen
> android:smallScreens="true" android:anyDensity="true" /> in the manifest,
> and then doing whatever fiddling of the UI is required to make it fit on the
> smaller QVGA screen.  (Note you can also supply alternative layouts in the
> layout-small directory.)  You'll also probably want to create low density
> graphics and place those in drawable-ldpi.
>
> Again, there should be a blog post soon that goes into much more detail on
> this topic.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com

Dianne Hackborn

unread,
Sep 8, 2009, 5:08:01 PM9/8/09
to android-d...@googlegroups.com
On Tue, Sep 8, 2009 at 1:21 PM, Al Sutton <a...@funkyandroid.com> wrote:
Just to be clear; are you saying that the device won't show in market
because it's a standard DPI and low resolution screen, or are you
saying they'll be blocked just because apps don't explicityly say they
support QVGA?

They won't show because QVGA is a smaller physical screen size than applications are currently targeted for (given a portrait screen of the same width as HVGA, a QVGA screen has less vertical space).  If an application is designed to use all of the space on an HVGA screen, there is little that can be done to display it on QVGA except doing a vertical pan and scan, or scaling it down even more so it is letterboxed on the sides.  Yuck.
 
From the docs in the open repo SDK I would have expected apps to be
available and scaled down using the 0.75 factor.

Density is a separate aspect of the screen, and easily adjusted for by the platform.  It doesn't cause any filtering on the market.

The upcoming blog post and documentation will cover this...  I don't really want to spend too much time on it here, reproducing the various tables and such showing how this all works.

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

gasolin

unread,
Sep 9, 2009, 2:26:09 AM9/9/09
to Android Developers
Hello,

I was thinking there are plenty of hardware constrains in upcoming
android devices,
not only the screen resolution. There will be some devices without
compass, wifi, g-sensor... ,etc.

It will be nice that developer could pre-claimed the app requirement
and user could be notified before they install the app and feel bad
while the app hang (mostly without notice).

Donut's 'supports-screens' tag could be easily extend to this
suggested architecture if google guys think its helpful.
http://code.google.com/p/android/issues/detail?id=3693

Please 'Star' this issue in the above link if you think it's good for
android ecosystem.


regards
--
gasolin

Dianne Hackborn

unread,
Sep 9, 2009, 2:35:55 AM9/9/09
to android-d...@googlegroups.com
Supporting a wider variety of hardware has been an ongoing processes, and was already started with 1.5 with the introduction of soft keyboards and corresponding mechanisms for applications to declare they require hard keyboards etc.  This will continue after Donut as well.

We are not going to drop a hardware requirement without having a mechanism for applications to specify that they need the hardware and a strategy for grand-fathering existing applications into the filtering.
--
Dianne Hackborn
Android framework engineer
hac...@android.com

Al Sutton

unread,
Sep 9, 2009, 5:12:48 AM9/9/09
to Android Developers
Dianne,

In the blog post can you cover how to produce one app which will run
on cupcake and donut and support multiple resolutions.

As I understand things at the moment developers will need at least two
versions of the same app listed in Market to cover both bases; One
with minSDK="4" and the supports-screens manifest tag and a separate
one for cupcake devices because cupcake won't run apps with minSDK >
3. If there is also a lite & paid for version you're then into 4 app
listings for the same app (lite, paid-for, multi-resolution lite,
multi-resolution paid-for), which seems like its' going to be a it of
a pain.

Thanks,

Al.
> hack...@android.com

Dianne Hackborn

unread,
Sep 9, 2009, 12:37:48 PM9/9/09
to android-d...@googlegroups.com
You'd do <supports-sdk android:minSdkVersion="3" android:targetSdkVersion="4" /> and then configure the rest of the manifest as desired.
hac...@android.com

Al Sutton

unread,
Sep 9, 2009, 1:29:38 PM9/9/09
to Android Developers
Thanks.

Al.

Ed Burnette

unread,
Sep 9, 2009, 9:59:44 PM9/9/09
to Android Developers
Did you mean <uses-sdk>?

Dianne Hackborn

unread,
Sep 9, 2009, 11:35:37 PM9/9/09
to android-d...@googlegroups.com
Sorry, yes.
hac...@android.com

ellipso...@googlemail.com

unread,
Sep 15, 2009, 6:10:45 AM9/15/09
to Android Developers
Sorry if I'm jumping the gun & this will be covered by the blog post -
but the thing I'm not getting is how we'll support new (i.e. SDK 1.6)
devices and old (1.5 or earlier) devices at the same time on the
market.

If I just rebuild and publish my app with the 1.6SDK to provide proper
support for different screen sizes, then anyone who hasn't upgraded to
Donut won't be able to see my app. Does this mean that we'll all end
up leaving 1.5SDK versions of our apps available on the market, and
then publishing donut/eclair versions with slightly different names?

Mark Murphy

unread,
Sep 15, 2009, 6:18:56 AM9/15/09
to android-d...@googlegroups.com
ellipso...@googlemail.com wrote:
> Sorry if I'm jumping the gun & this will be covered by the blog post -
> but the thing I'm not getting is how we'll support new (i.e. SDK 1.6)
> devices and old (1.5 or earlier) devices at the same time on the
> market.

Use resource sets, and ship one version of your app that supports
multiple screen sizes from a single APK.

My interpretation is that the manifest elements that Al Sutton and Ms.
Hackborn were describing are used as market and installer filters -- the
app will not be installed if you do not meet the manifest criteria. You
might use this, for example, as a stopgap to prevent people from trying
to use your app on QVGA or WVGA screens before you have had a chance to
add support for them.

So, if you want one app to handle more than one screen size, write your
app to handle more than one screen size, and leave those manifest
elements out of it.

Again, this is an educated guess, based upon what we had been told for
the last ~15 months on this issue, and it could be they have a whole
'nuther system in mind now.

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

_Android Programming Tutorials_ Version 1.0 Available!

ellipso...@googlemail.com

unread,
Sep 15, 2009, 10:42:21 AM9/15/09
to Android Developers
> Use resource sets, and ship one version of your app that supports
> multiple screen sizes from a single APK.
>
> <snip>
> So, if you want one app to handle more than one screen size, write your
> app to handle more than one screen size, and leave those manifest
> elements out of it.
>

Right - so if for my existing market apps I'm happy to stick with the
1.5SDK (which I am) and if I can code/design the apps to cope with the
different screens (which I can), then I can stick with 1.5 and ignore
the new manifest elements?

I was concerned that if I do this the framework on (e.g.) a WVGA
device will know that my app is 'old', and will therefore start
automatically scaling up my assets. Or, that for QVGA devices the
market might decide that my 1.5SDK app can't possibly support the
screen and it won't even be offered for download.

Mark Murphy

unread,
Sep 15, 2009, 11:17:18 AM9/15/09
to android-d...@googlegroups.com
> Right - so if for my existing market apps I'm happy to stick with the
> 1.5SDK (which I am) and if I can code/design the apps to cope with the
> different screens (which I can), then I can stick with 1.5 and ignore
> the new manifest elements?

That I am not sure about, see below.

> I was concerned that if I do this the framework on (e.g.) a WVGA
> device will know that my app is 'old', and will therefore start
> automatically scaling up my assets. Or, that for QVGA devices the
> market might decide that my 1.5SDK app can't possibly support the
> screen and it won't even be offered for download.

I misunderstood your original question. I thought you were wondering how
to support multiple screen sizes without having multiple APKs on the
market. You should be able to support as many screen sizes as you want
with a single APK, via resource sets. This *may* need to be supplemented
with new 1.6-specific manifest entries -- that part is unclear to me at
this time.

If you have an existing application, 1.5r3, with no layouts specifically
for WVGA/QVGA, WVGA and QVGA devices may make autonomous decisions of how
to interpret the layout rules you have provided (which presumably were
written for HVGA). Up until recently, I'd've said that it would just try
to use the assets as-is and interpret the layout rules as written. So,
WVGA might work just fine "out of the box" if you used RelativeLayout and
such (versus, say, AbsoluteLayout), but QVGA might look awful because your
assets were too big.

Some of the recent comments on this thread suggest that the core Android
team has added more sophisticated smarts than that, perhaps to try to
allow more applications to run acceptably without modification, and
perhaps also to deal with screen density and such. The details of how all
that works has not been discussed much beyond this thread, and presumably
is the meat of Ms. Hackborn's upcoming blog post.

Like you, I'm awaiting more details.

--
Mark Murphy (a Commons Guy)
http://commonsware.com

Android App Developer Books: http://commonsware.com/books.html


Dianne Hackborn

unread,
Sep 15, 2009, 1:05:02 PM9/15/09
to android-d...@googlegroups.com
For the most part, well written 1.5 apps will just work fine on Donut on a non-HVGA screen with compatibility mode turned off.  So all you need to do is say that you have been tested against Donut and know you work there with its compatibility features turned off by specifying android:targetSdkVersion="4".  (So this means your minSdkVersion is 3, 1.5, and your target is 4, Donut.  You can't be installed on anything before 1.5, you are tuned to work well on Donut, and anything after Donut will use what every new compatibility options on your app that they introduce.)

As far as scaling bitmaps, this is really orthogonal.  Compatibility mode is focused on putting your layout in a traditional HVGA size.  Images will only be scaled if you don't have versions of the appropriate density.  So if you just put images in drawable-240dpi and drawable-120dpi then the system will use the images you have designed for high and low density screens instead of scaling.  Again, regardless of whether compatibility mode is in play or not.  (Fwiw, when we finished things in Donut we decided to call these drawable-hdpi and drawable-ldpi, but pre-donut you need to use the old names, and Donut will be compatible with this.)

The perhaps more tricky thing is if you want to use new Donut features, even new attributes like android:supportsSmallScreens to say whether you will run on a small screen device.  At this point you will need to turn things around: build against the Donut SDK, be careful about what new features you use, and test against 1.5.  You can freely use new XML attributes and features without breaking compatibility with 1.5.  You'll still set minSdkVersion and targetSdkVersion the same, since you are again tuned for Donut and compatible with 1.5.
--
Dianne Hackborn
Android framework engineer
hac...@android.com

Artem

unread,
Oct 21, 2009, 7:09:16 PM10/21/09
to Android Developers


On Sep 15, 1:05 pm, Dianne Hackborn <hack...@android.com> wrote:
> For the most part, well written 1.5 apps will just work fine on Donut on a
> non-HVGA screen with compatibility mode turned off.  So all you need to do
> is say that you have been tested against Donut and know you work there with
> its compatibility features turned off by specifying
> android:targetSdkVersion="4".  (So this means your minSdkVersion is 3, 1.5,
> and your target is 4, Donut.  You can't be installed on anything before 1.5,
> you are tuned to work well on Donut, and anything after Donut will use what
> every new compatibility options on your app that they introduce.)
> As far as scaling bitmaps, this is really orthogonal.  Compatibility mode is
> focused on putting your layout in a traditional HVGA size.  Images will only
> be scaled if you don't have versions of the appropriate density.  So if you
> just put images in drawable-240dpi and drawable-120dpi then the system will
> use the images you have designed for high and low density screens instead of
> scaling.  Again, regardless of whether compatibility mode is in play or not.

Dianne, thanks for the answer.

Somehow, we are trying this and it does not seem to be working.
Namely, it seems
Donut *does not* pick up new resolution images in compatibility mode.

We have a test program with a drawable and drawable-hdpi in the res
folder, and
test.jpg in both of them. In the manifest, minSdkVersion=3 and
targetSdkVersion=3,
and we simply reference the drawable in the layout XML.

Any ideas? We are working hard to meet the WVGA-device deadline
(Monday), and we would really like to
still take advantage of the compatibility mode, so any advice would be
really appreciated.

>  (Fwiw, when we finished things in Donut we decided to call these
> drawable-hdpi and drawable-ldpi, but pre-donut you need to use the old
> names, and Donut will be compatible with this.)
>
> The perhaps more tricky thing is if you want to use new Donut features, even
> new attributes like android:supportsSmallScreens to say whether you will run
> on a small screen device.  At this point you will need to turn things
> around: build against the Donut SDK, be careful about what new features you
> use, and test against 1.5.  You can freely use new XML attributes and
> features without breaking compatibility with 1.5.  You'll still set
> minSdkVersion and targetSdkVersion the same, since you are again tuned for
> Donut and compatible with 1.5.
>
> hack...@android.com

Artem

unread,
Oct 21, 2009, 7:18:48 PM10/21/09
to Android Developers
We got it!

You need to put this in the manifest:
<supports-screens android:anyDensity="true" />

Artem

On Oct 21, 7:09 pm, Artem <p.ar...@gmail.com> wrote:
> On Sep 15, 1:05 pm, Dianne Hackborn <hack...@android.com> wrote:
>
> > For the most part, well written 1.5 apps will just work fine on Donut on a
> > non-HVGA screen withcompatibilitymodeturned off.  So all you need to do
> > is say that you have been tested against Donut and know you work there with
> > itscompatibilityfeatures turned off by specifying
> > android:targetSdkVersion="4".  (So this means your minSdkVersion is 3, 1.5,
> > and your target is 4, Donut.  You can't be installed on anything before 1.5,
> > you are tuned to work well on Donut, and anything after Donut will use what
> > every newcompatibilityoptions on your app that they introduce.)
> > As far as scaling bitmaps, this is really orthogonal.  Compatibilitymodeis
> > focused on putting your layout in a traditional HVGA size.  Images will only
> > be scaled if you don't have versions of the appropriate density.  So if you
> > just put images in drawable-240dpi and drawable-120dpi then the system will
> > use the images you have designed for high and low density screens instead of
> > scaling.  Again, regardless of whethercompatibilitymodeis in play or not.
>
> Dianne, thanks for the answer.
>
> Somehow, we are trying this and it does not seem to be working.
> Namely, it seems
> Donut *does not* pick up new resolution images incompatibilitymode.
>
> We have a test program with a drawable and drawable-hdpiin the res
> folder, and
> test.jpg in both of them. In the manifest, minSdkVersion=3 and
> targetSdkVersion=3,
> and we simply reference the drawable in the layout XML.
>
> Any ideas? We are working hard to meet the WVGA-device deadline
> (Monday), and we would really like to
> still take advantage of thecompatibilitymode, so any advice would be
> really appreciated.
>
>
>
> >  (Fwiw, when we finished things in Donut we decided to call these
> > drawable-hdpiand drawable-ldpi, but pre-donut you need to use the old
> > names, and Donut will be compatible with this.)
>
> > The perhaps more tricky thing is if you want to use new Donut features, even
> > new attributes like android:supportsSmallScreens to say whether you will run
> > on a small screen device.  At this point you will need to turn things
> > around: build against the Donut SDK, be careful about what new features you
> > use, and test against 1.5.  You can freely use new XML attributes and
> > features without breakingcompatibilitywith 1.5.  You'll still set

Artem

unread,
Oct 21, 2009, 7:21:50 PM10/21/09
to Android Developers
Nope, victory declared too early -- supports-screens actually puts it
out of compatibility mode, which defeats the purpose. :(

Artem

Nikolay Ananiev

unread,
Oct 22, 2009, 1:38:27 AM10/22/09
to android-d...@googlegroups.com
This is how I made my app resolution-independent and with Android 1.5 legacy support:

1. Changed the project settings in Eclipse to use Android SDK 1.6 (right click on the project -> Settings -> Android)
2. In AndroidManifest.xml added this:
     <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4" />
3. Leaved all the standard images for the 320x480 resolution in the res/drawable folder
4. Put all images for the high-resolution devices (800x480) in the res/drawable-hdpi-v4 folder
5. Put all images for the low-resolution devices (240x320) in the res/drawable-ldpi-v4 folder
6. Make sure you are not using Android 1.6 APIs in your code (This is very important to check manually, because Eclipse will not warn you)
7. Compile

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.

The only problem with this setup is with the ARCHOS 5 Tablet - it's the only Android 1.5 device that has a resolution different than 320x480 and it won't be able to load the images in the drawable-hdpi-v4 folder. So, if you want to support it you'll have to create a custom APK for it.

Dianne Hackborn

unread,
Oct 22, 2009, 2:15:28 PM10/22/09
to android-d...@googlegroups.com
On Wed, Oct 21, 2009 at 10:38 PM, Nikolay Ananiev <devu...@gmail.com> wrote:
The only problem with this setup is with the ARCHOS 5 Tablet - it's the only Android 1.5 device that has a resolution different than 320x480 and it won't be able to load the images in the drawable-hdpi-v4 folder. So, if you want to support it you'll have to create a custom APK for it.

Is it a high density device?  I thought its screen was larger so it would actually count as medium density.  Anyway, as you say they did their own customization for their screen support, so are not following the standard platform, so won't be compatible.  I would assume that Market won't be on it until this is resolved.

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

Dianne Hackborn

unread,
Oct 22, 2009, 2:21:06 PM10/22/09
to android-d...@googlegroups.com
On Wed, Oct 21, 2009 at 4:09 PM, Artem <p.a...@gmail.com> wrote:
Somehow, we are trying this and it does not seem to be working.
Namely, it seems
Donut *does not* pick up new resolution images in compatibility mode.

I am pretty positive it does.  Proof: when you run any existing application on a high density display, you will get the nice high density graphics for any buttons or other stock widgets.  This is because the framework is picking the correct density graphics for the screen.

Note, however, that this can only happen if you are loading the image as a Drawable from Resources, since there is special magic in BitmapDrawable and NinePatchDrawable to load the bitmap based on the true screen report to the app metrics that match the compatibility scaling it is.  Also, if you draw anything into an off-screen bitmap, then you will force everything in to the compatibility scaling and lose any high-density graphics.

As a general rule, the compatibility modes are only there for existing applications that were written before knowing about multiple screens.  The first thing you should do is turn them off.  I don't really understand why you are trying to keep your app running in compatibility mode on 1.6; that is by and large really what you -don't- want.

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

Jeff

unread,
Oct 28, 2009, 7:49:24 PM10/28/09
to Android Developers
Looks like -v4 flag doesn't work in Android 2.0. On emulator with WVGA
screen my app loads "drawable-hdpi", but ignores "drawable-hdpi-v4".
Ideas anyone?

Jeff

unread,
Oct 28, 2009, 8:28:05 PM10/28/09
to Android Developers
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:
>

Dianne Hackborn

unread,
Oct 29, 2009, 10:45:28 AM10/29/09
to android-d...@googlegroups.com
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.
--
Dianne Hackborn
Android framework engineer
hac...@android.com

webmonkey

unread,
Oct 29, 2009, 11:00:40 AM10/29/09
to Android Developers
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

Artem Petakov

unread,
Oct 29, 2009, 9:12:41 PM10/29/09
to android-d...@googlegroups.com
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

Artem

unread,
Oct 29, 2009, 10:25:14 PM10/29/09
to Android Developers, Jason Chen
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/include/utils/ResourceTypes.h&q=ResTable_config&l=787

// 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

Dianne Hackborn

unread,
Oct 29, 2009, 10:29:11 PM10/29/09
to android-d...@googlegroups.com, Jason Chen
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.
hac...@android.com

Artem Petakov

unread,
Oct 29, 2009, 11:22:16 PM10/29/09
to android-d...@googlegroups.com, Jason Chen
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

Artem Petakov

unread,
Oct 30, 2009, 1:15:13 AM10/30/09
to android-d...@googlegroups.com
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?

Nikolay Ananiev

unread,
Oct 30, 2009, 1:48:14 AM10/30/09
to android-d...@googlegroups.com
drawable-hdpi-v4 doesn't work in the WVGA 2.0 emulator, but works in the WVGA 1.6.
The strange thing is that drawable-ldpi-v4 works fine in the qvga 2.0 emulator.

tberthel

unread,
Oct 30, 2009, 3:16:01 AM10/30/09
to Android Developers
The Highest resolution I can get in the emulator is 1000x500.

I need 1200x600. How do I do it? or can I yet?

On Oct 29, 9: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/...

Nikolay Ananiev

unread,
Oct 30, 2009, 3:49:23 AM10/30/09
to android-d...@googlegroups.com
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.a...@gmail.com> wrote:

webmonkey

unread,
Oct 30, 2009, 1:36:16 PM10/30/09
to Android Developers
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/...