Android WVGA support
Al Sutton
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
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.
>
Mark Murphy
> 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:
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
broc.seib wrote:You and me both.
> I am looking to get my hands on a physical WVGA device for android.
> Can anyone shed more light on what/when is available in the WVGAThe Archos Internet media tablet is supposed to have WVGA:
> department for Android?
http://gizmodo.com/5341242/archos-android-tablet-with-720p-playback-and-mobile-internet-to-launch-september-15th
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
> 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)...
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy
_The Busy Coder's Guide to *Advanced* Android Development_
Version 1.1 Available!
Al Sutton
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.
Howard M. Harte
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.
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
> 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
> 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
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
Dianne Hackborn
Al Sutton
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
Al Sutton
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
>1.5 WVGA : http://download.funkyandroid.net/15wvga.png
>1.6 WVGA : http://download.funkyandroid.net/16wvga.png
>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).
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
Xavier Ducrohet
> 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
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
> 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
> 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.
>
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
Dianne Hackborn
Al Sutton
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 Guy
> 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
Xavier Ducrohet
>
> 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
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
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
"Based on the target device screen density, the Android framework will
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:
>
> > 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
Dianne Hackborn
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
gasolin
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
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
Al Sutton
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.
Dianne Hackborn
Al Sutton
Al.
Ed Burnette
Dianne Hackborn
ellipso...@googlemail.com
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
> 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
> multiple screen sizes from a single APK.
>
> app to handle more than one screen size, and leave those manifest
> elements out of it.
>
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
> 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
Dianne Hackborn
Android framework engineer
Artem
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.
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.
>
Artem
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
> > 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
> > 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
> 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.
>
> 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
>
>
>
> > (Fwiw, when we finished things in Donut we decided to call these
>
> > 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
Artem
out of compatibility mode, which defeats the purpose. :(
Artem
Nikolay Ananiev
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
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
Android framework engineer
Dianne Hackborn
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.
Dianne Hackborn
Android framework engineer
Jeff
screen my app loads "drawable-hdpi", but ignores "drawable-hdpi-v4".
Ideas anyone?
Jeff
> support:
>
Dianne Hackborn
Dianne Hackborn
Android framework engineer
webmonkey
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
Artem Petakov
Artem
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
Artem Petakov
Artem Petakov
Nikolay Ananiev
The strange thing is that drawable-ldpi-v4 works fine in the qvga 2.0 emulator.
tberthel
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:
>
Nikolay Ananiev
Thanks Artem!
webmonkey
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!
>
> > 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?
>
>
> >> 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
>
>
> >>> 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.
>
>
> >>>> Trying to help by digging up the code.
>
> >>>> I found this:
>