Re: [android-developers] Re: Android WVGA support
1.5 already had some of the initial density support, including simple density matching (it just checked for exact matches to density, rather than considering scaling factors as the final implementation in 1.6 does), so this should work fine. On Mon, Nov 2, 2009 at 12:11 PM, webmonkey webmonke...@gmail.com wrote: Thanks for the clarification Dianne. Is it also OK to use my solution with the normal 1.5 resolution bitmaps in drawable-mdpi and the high resolution bitmaps in drawable- hdpi. For some reason the 1.5 emulator correctly gets the bitmaps from the drawable-mdpi folder if you don't use drawable-ldpi. It seems to work fine. On Nov 2, 8:39 pm, Dianne Hackborn hack...@android.com wrote: Yes there are bugs in the version matching. I just submitted a fix that should go into the first OTA update for Droid; the current 2.0 should only ever ship on Droid, and be replaced with an update at that point, so hopefully this will not be a long-term problem. In the meantime, the work-around is to have the resources as both -v4 and -v6. I know that is a pain; I am very sorry. (For those curious, there are two problems: first when the version matching was implemented, this was a late addition to 1.0 just in case, and was implemented as a simple comparison because the semantics hadn't yet been defined. Now when we are actually using it, we've discovered the code never code fully implemented with the correct semantics. On top of that, there was a change done late in 2.0 so that development builds would match the next version number for resources, which I messed up and thus broke the final release versioning.) On Fri, Oct 30, 2009 at 10:06 AM, Artem Petakov p.ar...@gmail.com wrote: Right, you have to use -v4 for that of course. It's similar to what Dianne had suggested above (using both -v4 and -v5), except v5 is actually v6. It just seems that somewhere deep in this part of the Eclair code there is something that makes it think that the sdkVersion is 6, not 5. Dianne, could you please comment since this is the only workaround that works so far? I would love to find this out myself, but since the Eclair code is not yet available, it's hard to figure this out. I'm assuming the code drop is coming soon. I have verified that by using both -v4 and -v6, I can get things to work on every platform. For those interested, to avoid duplicating actual pngs/jpgs, I am using an ugly hack. Here is an example Folder drawable-160dpi: example_image.png (the mdpi version of image) Folder drawable-240dpi-v4: XML file example_image.xml with the following inside: bitmap xmlns:android=http://schemas.android.com/apk/res/android; android:src=@drawable/example_image_hdpi / Folder drawable-240dpi-v6: Same example_image.xml with the following inside: bitmap xmlns:android=http://schemas.android.com/apk/res/android; android:src=@drawable/example_image_hdpi / Folder drawable-nodpi: example_image_hdpi.png (the hdpi version of image) Yes, it's very ugly. Any better ideas are very welcome. Artem On Fri, Oct 30, 2009 at 1:36 PM, webmonkey webmonke...@gmail.com wrote: drawable-hdpi-v6 does indeed work in the 2.0 emulator but not in a 1.6 emulator. And because it is not exactly clear what the problem is I do not recommend using it. I am still hoping to find a solution where I can just use drawable- hdpi On Oct 30, 8:49 am, Nikolay Ananiev devuni...@gmail.com wrote: YES drawable-hdpi-v6 works for me too. I'll use it in my next release as a workaround Thanks Artem! On Fri, Oct 30, 2009 at 7:15 AM, Artem Petakov p.ar...@gmail.com wrote: This will sound crazy, but -v6 works for me. There must be a strange reason why this works, or maybe there is a subtle reason why this workaround does not work. Can anyone confirm? On Thu, Oct 29, 2009 at 11:22 PM, Artem Petakov p.ar...@gmail.com wrote: Ah, that's too bad. Bugs happen. I am trying to understand the solution... Somehow having a -v5 version in there does not help (as webmonkey reported). I don't have my head around this fully, but I think Android somehow prefers the regular drawable directory (which I have for the Cupcake crowd). What is the recommended set of drawable directories at this point? Artem On Thu, Oct 29, 2009 at 10:29 PM, Dianne Hackborn hack...@android.comwrote: 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=ensa=Ncd=1ct=rc#uX1GffpyOZk/. .. // Return true if 'this' can be
[android-developers] Re: Android WVGA support
OK, I have found a solution that works for my needs:
I now have a folder 'drawable-hdpi' with all the hi-res bitmaps
I have moved all the bitmaps from the 'drawable' folder to 'drawable-
mdpi'
That's it. Fortunately, when running on a 1.5 emulator, it picks the
bitmaps from drawable-mdpi (Not sure why though)
Note that I do support lower resolution screens but I have not made
optimized lo-res bitmaps. The bitmaps scale down quite well from the
normal resolution. It also means that I don't have to create an extra
set of bitmaps and the size of the APK is smaller.
Also, if you do have a 'drawable-ldpi' folder then the 1.5 emulator
will pick those so that does not work.
On Oct 30, 7:06 pm, Artem Petakov p.ar...@gmail.com wrote:
Right, you have to use -v4 for that of course. It's similar to what Dianne
had suggested above (using both -v4 and -v5), except v5 is actually v6. It
just seems that somewhere deep in this part of the Eclair code there is
something that makes it think that the sdkVersion is 6, not 5. Dianne, could
you please comment since this is the only workaround that works so far?
I would love to find this out myself, but since the Eclair code is not yet
available, it's hard to figure this out. I'm assuming the code drop is
coming soon.
I have verified that by using both -v4 and -v6, I can get things to work on
every platform.
For those interested, to avoid duplicating actual pngs/jpgs, I am using an
ugly hack. Here is an example
Folder drawable-160dpi:
example_image.png (the mdpi version of image)
Folder drawable-240dpi-v4:
XML file example_image.xml with the following inside:
bitmap xmlns:android=http://schemas.android.com/apk/res/android;
android:src=@drawable/example_image_hdpi
/
Folder drawable-240dpi-v6:
Same example_image.xml with the following inside:
bitmap xmlns:android=http://schemas.android.com/apk/res/android;
android:src=@drawable/example_image_hdpi
/
Folder drawable-nodpi:
example_image_hdpi.png (the hdpi version of image)
Yes, it's very ugly. Any better ideas are very welcome.
Artem
On Fri, Oct 30, 2009 at 1:36 PM, webmonkey webmonke...@gmail.com wrote:
drawable-hdpi-v6 does indeed work in the 2.0 emulator but not in a 1.6
emulator. And because it is not exactly clear what the problem is I do
not recommend using it.
I am still hoping to find a solution where I can just use drawable-
hdpi
On Oct 30, 8:49 am, Nikolay Ananiev devuni...@gmail.com wrote:
YES drawable-hdpi-v6 works for me too. I'll use it in my next release as
a
workaround
Thanks Artem!
On Fri, Oct 30, 2009 at 7:15 AM, Artem Petakov p.ar...@gmail.com
wrote:
This will sound crazy, but -v6 works for me. There must be a strange
reason
why this works, or maybe there is a subtle reason why this workaround
does
not work. Can anyone confirm?
On Thu, Oct 29, 2009 at 11:22 PM, Artem Petakov p.ar...@gmail.com
wrote:
Ah, that's too bad. Bugs happen.
I am trying to understand the solution... Somehow having a -v5 version
in
there does not help (as webmonkey reported). I don't have my head
around
this fully, but I think Android somehow prefers the regular drawable
directory (which I have for the Cupcake crowd). What is the
recommended set
of drawable directories at this point?
Artem
On Thu, Oct 29, 2009 at 10:29 PM, Dianne Hackborn
hack...@android.comwrote:
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/...
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asymetric. A default piece of data will match
every request
// but a request for the default should not match odd specifics
// (ie, request with no mcc should not match a particular mcc's
data)
// settings is the requested settings
inline bool match(const ResTable_config settings) const {
...
if (version != 0) {
if (settings.sdkVersion != 0 sdkVersion != 0
sdkVersion != settings.sdkVersion) {
return false;
}
if (settings.minorVersion != 0 minorVersion != 0
minorVersion != settings.minorVersion) {
return false;
}
}
return true;
}
Of course I am not sure where this is used, but I only see an !=
here.
Hopefully, this is not the right code. Or perhaps there is new code
in
Eclair that is not available yet, that makes this better.
Thanks for the help.
Artem
On Oct 29, 9:12 pm, Artem Petakov
Re: [android-developers] Re: Android WVGA support
Yes there are bugs in the version matching. I just submitted a fix that
should go into the first OTA update for Droid; the current 2.0 should only
ever ship on Droid, and be replaced with an update at that point, so
hopefully this will not be a long-term problem.
In the meantime, the work-around is to have the resources as both -v4 and
-v6. I know that is a pain; I am very sorry. (For those curious, there are
two problems: first when the version matching was implemented, this was a
late addition to 1.0 just in case, and was implemented as a simple
comparison because the semantics hadn't yet been defined. Now when we are
actually using it, we've discovered the code never code fully implemented
with the correct semantics. On top of that, there was a change done late in
2.0 so that development builds would match the next version number for
resources, which I messed up and thus broke the final release versioning.)
On Fri, Oct 30, 2009 at 10:06 AM, Artem Petakov p.ar...@gmail.com wrote:
Right, you have to use -v4 for that of course. It's similar to what Dianne
had suggested above (using both -v4 and -v5), except v5 is actually v6. It
just seems that somewhere deep in this part of the Eclair code there is
something that makes it think that the sdkVersion is 6, not 5. Dianne, could
you please comment since this is the only workaround that works so far?
I would love to find this out myself, but since the Eclair code is not yet
available, it's hard to figure this out. I'm assuming the code drop is
coming soon.
I have verified that by using both -v4 and -v6, I can get things to work on
every platform.
For those interested, to avoid duplicating actual pngs/jpgs, I am using an
ugly hack. Here is an example
Folder drawable-160dpi:
example_image.png (the mdpi version of image)
Folder drawable-240dpi-v4:
XML file example_image.xml with the following inside:
bitmap xmlns:android=http://schemas.android.com/apk/res/android;
android:src=@drawable/example_image_hdpi
/
Folder drawable-240dpi-v6:
Same example_image.xml with the following inside:
bitmap xmlns:android=http://schemas.android.com/apk/res/android;
android:src=@drawable/example_image_hdpi
/
Folder drawable-nodpi:
example_image_hdpi.png (the hdpi version of image)
Yes, it's very ugly. Any better ideas are very welcome.
Artem
On Fri, Oct 30, 2009 at 1:36 PM, webmonkey webmonke...@gmail.com wrote:
drawable-hdpi-v6 does indeed work in the 2.0 emulator but not in a 1.6
emulator. And because it is not exactly clear what the problem is I do
not recommend using it.
I am still hoping to find a solution where I can just use drawable-
hdpi
On Oct 30, 8:49 am, Nikolay Ananiev devuni...@gmail.com wrote:
YES drawable-hdpi-v6 works for me too. I'll use it in my next release as
a
workaround
Thanks Artem!
On Fri, Oct 30, 2009 at 7:15 AM, Artem Petakov p.ar...@gmail.com
wrote:
This will sound crazy, but -v6 works for me. There must be a strange
reason
why this works, or maybe there is a subtle reason why this workaround
does
not work. Can anyone confirm?
On Thu, Oct 29, 2009 at 11:22 PM, Artem Petakov p.ar...@gmail.com
wrote:
Ah, that's too bad. Bugs happen.
I am trying to understand the solution... Somehow having a -v5
version in
there does not help (as webmonkey reported). I don't have my head
around
this fully, but I think Android somehow prefers the regular
drawable
directory (which I have for the Cupcake crowd). What is the
recommended set
of drawable directories at this point?
Artem
On Thu, Oct 29, 2009 at 10:29 PM, Dianne Hackborn
hack...@android.comwrote:
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/...
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asymetric. A default piece of data will match
every request
// but a request for the default should not match odd specifics
// (ie, request with no mcc should not match a particular mcc's
data)
// settings is the requested settings
inline bool match(const ResTable_config settings) const {
...
if (version != 0) {
if (settings.sdkVersion != 0 sdkVersion != 0
sdkVersion != settings.sdkVersion) {
return false;
}
if (settings.minorVersion != 0 minorVersion != 0
minorVersion != settings.minorVersion) {
return false;
}
}
return true;
}
Of course I am not sure where this is used, but I only see an !=
here.
[android-developers] Re: Android WVGA support
Thanks for the clarification Dianne.
Is it also OK to use my solution with the normal 1.5 resolution
bitmaps in drawable-mdpi and the high resolution bitmaps in drawable-
hdpi. For some reason the 1.5 emulator correctly gets the bitmaps from
the drawable-mdpi folder if you don't use drawable-ldpi. It seems to
work fine.
On Nov 2, 8:39 pm, Dianne Hackborn hack...@android.com wrote:
Yes there are bugs in the version matching. I just submitted a fix that
should go into the first OTA update for Droid; the current 2.0 should only
ever ship on Droid, and be replaced with an update at that point, so
hopefully this will not be a long-term problem.
In the meantime, the work-around is to have the resources as both -v4 and
-v6. I know that is a pain; I am very sorry. (For those curious, there are
two problems: first when the version matching was implemented, this was a
late addition to 1.0 just in case, and was implemented as a simple
comparison because the semantics hadn't yet been defined. Now when we are
actually using it, we've discovered the code never code fully implemented
with the correct semantics. On top of that, there was a change done late in
2.0 so that development builds would match the next version number for
resources, which I messed up and thus broke the final release versioning.)
On Fri, Oct 30, 2009 at 10:06 AM, Artem Petakov p.ar...@gmail.com wrote:
Right, you have to use -v4 for that of course. It's similar to what Dianne
had suggested above (using both -v4 and -v5), except v5 is actually v6. It
just seems that somewhere deep in this part of the Eclair code there is
something that makes it think that the sdkVersion is 6, not 5. Dianne, could
you please comment since this is the only workaround that works so far?
I would love to find this out myself, but since the Eclair code is not yet
available, it's hard to figure this out. I'm assuming the code drop is
coming soon.
I have verified that by using both -v4 and -v6, I can get things to work on
every platform.
For those interested, to avoid duplicating actual pngs/jpgs, I am using an
ugly hack. Here is an example
Folder drawable-160dpi:
example_image.png (the mdpi version of image)
Folder drawable-240dpi-v4:
XML file example_image.xml with the following inside:
bitmap xmlns:android=http://schemas.android.com/apk/res/android;
android:src=@drawable/example_image_hdpi
/
Folder drawable-240dpi-v6:
Same example_image.xml with the following inside:
bitmap xmlns:android=http://schemas.android.com/apk/res/android;
android:src=@drawable/example_image_hdpi
/
Folder drawable-nodpi:
example_image_hdpi.png (the hdpi version of image)
Yes, it's very ugly. Any better ideas are very welcome.
Artem
On Fri, Oct 30, 2009 at 1:36 PM, webmonkey webmonke...@gmail.com wrote:
drawable-hdpi-v6 does indeed work in the 2.0 emulator but not in a 1.6
emulator. And because it is not exactly clear what the problem is I do
not recommend using it.
I am still hoping to find a solution where I can just use drawable-
hdpi
On Oct 30, 8:49 am, Nikolay Ananiev devuni...@gmail.com wrote:
YES drawable-hdpi-v6 works for me too. I'll use it in my next release as
a
workaround
Thanks Artem!
On Fri, Oct 30, 2009 at 7:15 AM, Artem Petakov p.ar...@gmail.com
wrote:
This will sound crazy, but -v6 works for me. There must be a strange
reason
why this works, or maybe there is a subtle reason why this workaround
does
not work. Can anyone confirm?
On Thu, Oct 29, 2009 at 11:22 PM, Artem Petakov p.ar...@gmail.com
wrote:
Ah, that's too bad. Bugs happen.
I am trying to understand the solution... Somehow having a -v5
version in
there does not help (as webmonkey reported). I don't have my head
around
this fully, but I think Android somehow prefers the regular
drawable
directory (which I have for the Cupcake crowd). What is the
recommended set
of drawable directories at this point?
Artem
On Thu, Oct 29, 2009 at 10:29 PM, Dianne Hackborn
hack...@android.comwrote:
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/...
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asymetric. A default piece of data will match
every request
// but a request for the default should not match odd specifics
// (ie, request with no mcc should not match a particular mcc's
data)
// settings is the requested settings
inline bool match(const ResTable_config settings) const {
...
if (version != 0)
[android-developers] Re: Android WVGA support
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/...
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asymetric. A default piece of data will match
every request
// but a request for the default should not match odd specifics
// (ie, request with no mcc should not match a particular mcc's
data)
// settings is the requested settings
inline bool match(const ResTable_config settings) const {
...
if (version != 0) {
if (settings.sdkVersion != 0 sdkVersion != 0
sdkVersion != settings.sdkVersion) {
return false;
}
if (settings.minorVersion != 0 minorVersion != 0
minorVersion != settings.minorVersion) {
return false;
}
}
return true;
}
Of course I am not sure where this is used, but I only see an != here.
Hopefully, this is not the right code. Or perhaps there is new code in
Eclair that is not available yet, that makes this better.
Thanks for the help.
Artem
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually, we had
made a mistake and originally forgot the v4, which screwed up Cupcake,
but
now we added the v4 (and make no other changes), and it stopped working.
Am I missing something? Or is there perhaps a serious problem? Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion=5
/
Running on a WVGA854 emulator with density 240 and API 5, I get the
following results:
drawable-hdpi-v4
is ignored
drawable-hdpi-v5
is ignored, very strange
drawable-hdpi
works, but we can't use that
On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote:
I am pretty positive it works. Nothing changed in 2.0 -- this has
been
the
same since 1.0, if the platform's SDK version is the resource
version,
then the resource is ignored.
On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com wrote:
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote:
This is how I made my app resolution-independent and with Android
1.5
legacy
support:
Why did I put my high-dpi images in the drawable-hdpi-v4 folder
and
not
in
drawable-hdpi? Because the Android 1.5 OS can't handle the -hdpi
and
tries
to use these images instead of the ones in the res/drawable
folder.
The
-v4
flag is only meaningful for Android 1.6 and works perfect.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time
to
provide private support, and so won't reply to such e-mails. All
such
questions should be posted on public forums, where I and others can
see
and
answer them.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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.comwrote:
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/include/utils/ResourceTypes.hq=ResTable_configl=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
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually, we
had
made a mistake and originally forgot the v4, which screwed up Cupcake,
but
now we added the v4 (and make no other changes), and it stopped
working.
Am I missing something? Or is there perhaps a serious problem? Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion=5
/
Running on a WVGA854 emulator with density 240 and API 5, I get the
following results:
drawable-hdpi-v4
is ignored
drawable-hdpi-v5
is ignored, very strange
drawable-hdpi
works, but we can't use that
On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote:
I am pretty positive it works. Nothing changed in 2.0 -- this has
been
the
same since 1.0, if the platform's SDK version is the resource
version,
then the resource is ignored.
On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com
wrote:
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com
wrote:
This is how I made my app resolution-independent and with
Android 1.5
legacy
support:
Why did I put my high-dpi images in the drawable-hdpi-v4
folder and
not
in
drawable-hdpi? Because the Android 1.5 OS can't handle the
-hdpi and
tries
to use these images instead of the ones in the res/drawable
folder.
The
-v4
flag is only meaningful for Android 1.6 and works perfect.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have
time to
provide private support, and so won't reply to such e-mails. All
such
questions should be posted on public forums, where I and others
can see
and
answer them.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
[android-developers] Re: Android WVGA support
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.comwrote:
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/...
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asymetric. A default piece of data will match
every request
// but a request for the default should not match odd specifics
// (ie, request with no mcc should not match a particular mcc's
data)
// settings is the requested settings
inline bool match(const ResTable_config settings) const {
...
if (version != 0) {
if (settings.sdkVersion != 0 sdkVersion != 0
sdkVersion != settings.sdkVersion) {
return false;
}
if (settings.minorVersion != 0 minorVersion != 0
minorVersion != settings.minorVersion) {
return false;
}
}
return true;
}
Of course I am not sure where this is used, but I only see an != here.
Hopefully, this is not the right code. Or perhaps there is new code in
Eclair that is not available yet, that makes this better.
Thanks for the help.
Artem
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually, we
had
made a mistake and originally forgot the v4, which screwed up Cupcake,
but
now we added the v4 (and make no other changes), and it stopped
working.
Am I missing something? Or is there perhaps a serious problem? Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion=5
/
Running on a WVGA854 emulator with density 240 and API 5, I get the
following results:
drawable-hdpi-v4
is ignored
drawable-hdpi-v5
is ignored, very strange
drawable-hdpi
works, but we can't use that
On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote:
I am pretty positive it works. Nothing changed in 2.0 -- this has
been
the
same since 1.0, if the platform's SDK version is the resource
version,
then the resource is ignored.
On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com
wrote:
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com
wrote:
This is how I made my app resolution-independent and with
Android 1.5
legacy
support:
Why did I put my high-dpi images in the drawable-hdpi-v4
folder and
not
in
drawable-hdpi? Because the Android 1.5 OS can't handle the
-hdpi and
tries
to use these images instead of the ones in the res/drawable
folder.
The
-v4
flag is only meaningful for Android 1.6 and works perfect.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have
time to
provide private support, and so won't reply to such e-mails. All
such
questions should be posted on public forums, where I and others
can see
[android-developers] Re: Android WVGA support
Right, you have to use -v4 for that of course. It's similar to what Dianne
had suggested above (using both -v4 and -v5), except v5 is actually v6. It
just seems that somewhere deep in this part of the Eclair code there is
something that makes it think that the sdkVersion is 6, not 5. Dianne, could
you please comment since this is the only workaround that works so far?
I would love to find this out myself, but since the Eclair code is not yet
available, it's hard to figure this out. I'm assuming the code drop is
coming soon.
I have verified that by using both -v4 and -v6, I can get things to work on
every platform.
For those interested, to avoid duplicating actual pngs/jpgs, I am using an
ugly hack. Here is an example
Folder drawable-160dpi:
example_image.png (the mdpi version of image)
Folder drawable-240dpi-v4:
XML file example_image.xml with the following inside:
bitmap xmlns:android=http://schemas.android.com/apk/res/android;
android:src=@drawable/example_image_hdpi
/
Folder drawable-240dpi-v6:
Same example_image.xml with the following inside:
bitmap xmlns:android=http://schemas.android.com/apk/res/android;
android:src=@drawable/example_image_hdpi
/
Folder drawable-nodpi:
example_image_hdpi.png (the hdpi version of image)
Yes, it's very ugly. Any better ideas are very welcome.
Artem
On Fri, Oct 30, 2009 at 1:36 PM, webmonkey webmonke...@gmail.com wrote:
drawable-hdpi-v6 does indeed work in the 2.0 emulator but not in a 1.6
emulator. And because it is not exactly clear what the problem is I do
not recommend using it.
I am still hoping to find a solution where I can just use drawable-
hdpi
On Oct 30, 8:49 am, Nikolay Ananiev devuni...@gmail.com wrote:
YES drawable-hdpi-v6 works for me too. I'll use it in my next release as
a
workaround
Thanks Artem!
On Fri, Oct 30, 2009 at 7:15 AM, Artem Petakov p.ar...@gmail.com
wrote:
This will sound crazy, but -v6 works for me. There must be a strange
reason
why this works, or maybe there is a subtle reason why this workaround
does
not work. Can anyone confirm?
On Thu, Oct 29, 2009 at 11:22 PM, Artem Petakov p.ar...@gmail.com
wrote:
Ah, that's too bad. Bugs happen.
I am trying to understand the solution... Somehow having a -v5 version
in
there does not help (as webmonkey reported). I don't have my head
around
this fully, but I think Android somehow prefers the regular drawable
directory (which I have for the Cupcake crowd). What is the
recommended set
of drawable directories at this point?
Artem
On Thu, Oct 29, 2009 at 10:29 PM, Dianne Hackborn
hack...@android.comwrote:
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/...
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asymetric. A default piece of data will match
every request
// but a request for the default should not match odd specifics
// (ie, request with no mcc should not match a particular mcc's
data)
// settings is the requested settings
inline bool match(const ResTable_config settings) const {
...
if (version != 0) {
if (settings.sdkVersion != 0 sdkVersion != 0
sdkVersion != settings.sdkVersion) {
return false;
}
if (settings.minorVersion != 0 minorVersion != 0
minorVersion != settings.minorVersion) {
return false;
}
}
return true;
}
Of course I am not sure where this is used, but I only see an !=
here.
Hopefully, this is not the right code. Or perhaps there is new code
in
Eclair that is not available yet, that makes this better.
Thanks for the help.
Artem
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually,
we
had
made a mistake and originally forgot the v4, which screwed up
Cupcake,
but
now we added the v4 (and make no other changes), and it stopped
working.
Am I missing something? Or is there perhaps a serious problem?
Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking
Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey
webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK
with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
[android-developers] Re: Android WVGA support
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? On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote: 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
I am pretty positive it works. Nothing changed in 2.0 -- this has been the same since 1.0, if the platform's SDK version is the resource version, then the resource is ignored. On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com wrote: Looks like -v4 flag doesn't work in Android 2.0. Any ideas? On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote: This is how I made my app resolution-independent and with Android 1.5 legacy support: Why did I put my high-dpi images in the drawable-hdpi-v4 folder and not in drawable-hdpi? Because the Android 1.5 OS can't handle the -hdpi and tries to use these images instead of the ones in the res/drawable folder. The -v4 flag is only meaningful for Android 1.6 and works perfect. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
Hi Dianne, The v flag does indeed not work, I am using the Android 2.0 SDK with the following AndroidManifest settings: uses-sdk android:minSdkVersion=3 android:targetSdkVersion=5 / Running on a WVGA854 emulator with density 240 and API 5, I get the following results: drawable-hdpi-v4 is ignored drawable-hdpi-v5 is ignored, very strange drawable-hdpi works, but we can't use that On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote: I am pretty positive it works. Nothing changed in 2.0 -- this has been the same since 1.0, if the platform's SDK version is the resource version, then the resource is ignored. On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com wrote: Looks like -v4 flag doesn't work in Android 2.0. Any ideas? On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote: This is how I made my app resolution-independent and with Android 1.5 legacy support: Why did I put my high-dpi images in the drawable-hdpi-v4 folder and not in drawable-hdpi? Because the Android 1.5 OS can't handle the -hdpi and tries to use these images instead of the ones in the res/drawable folder. The -v4 flag is only meaningful for Android 1.6 and works perfect. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
Dianne, I am sorry to say it also does not work for me. Actually, we had made a mistake and originally forgot the v4, which screwed up Cupcake, but now we added the v4 (and make no other changes), and it stopped working. Am I missing something? Or is there perhaps a serious problem? Please reply back so we can take action -- we need to publish a new APK for the Cupcake users, but we can't figure out how to do that without breaking Eclair. Artem On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com wrote: Hi Dianne, The v flag does indeed not work, I am using the Android 2.0 SDK with the following AndroidManifest settings: uses-sdk android:minSdkVersion=3 android:targetSdkVersion=5 / Running on a WVGA854 emulator with density 240 and API 5, I get the following results: drawable-hdpi-v4 is ignored drawable-hdpi-v5 is ignored, very strange drawable-hdpi works, but we can't use that On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote: I am pretty positive it works. Nothing changed in 2.0 -- this has been the same since 1.0, if the platform's SDK version is the resource version, then the resource is ignored. On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com wrote: Looks like -v4 flag doesn't work in Android 2.0. Any ideas? On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote: This is how I made my app resolution-independent and with Android 1.5 legacy support: Why did I put my high-dpi images in the drawable-hdpi-v4 folder and not in drawable-hdpi? Because the Android 1.5 OS can't handle the -hdpi and tries to use these images instead of the ones in the res/drawable folder. The -v4 flag is only meaningful for Android 1.6 and works perfect. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
Trying to help by digging up the code.
I found this:
http://www.google.com/codesearch/p?hl=ensa=Ncd=1ct=rc#uX1GffpyOZk/include/utils/ResourceTypes.hq=ResTable_configl=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
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually, we had
made a mistake and originally forgot the v4, which screwed up Cupcake, but
now we added the v4 (and make no other changes), and it stopped working.
Am I missing something? Or is there perhaps a serious problem? Please reply
back so we can take action -- we need to publish a new APK for the Cupcake
users, but we can't figure out how to do that without breaking Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion=5
/
Running on a WVGA854 emulator with density 240 and API 5, I get the
following results:
drawable-hdpi-v4
is ignored
drawable-hdpi-v5
is ignored, very strange
drawable-hdpi
works, but we can't use that
On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote:
I am pretty positive it works. Nothing changed in 2.0 -- this has been
the
same since 1.0, if the platform's SDK version is the resource version,
then the resource is ignored.
On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com wrote:
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote:
This is how I made my app resolution-independent and with Android 1.5
legacy
support:
Why did I put my high-dpi images in the drawable-hdpi-v4 folder and
not
in
drawable-hdpi? Because the Android 1.5 OS can't handle the -hdpi and
tries
to use these images instead of the ones in the res/drawable folder.
The
-v4
flag is only meaningful for Android 1.6 and works perfect.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see
and
answer them.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/include/utils/ResourceTypes.hq=ResTable_configl=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
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually, we had
made a mistake and originally forgot the v4, which screwed up Cupcake,
but
now we added the v4 (and make no other changes), and it stopped working.
Am I missing something? Or is there perhaps a serious problem? Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion=5
/
Running on a WVGA854 emulator with density 240 and API 5, I get the
following results:
drawable-hdpi-v4
is ignored
drawable-hdpi-v5
is ignored, very strange
drawable-hdpi
works, but we can't use that
On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote:
I am pretty positive it works. Nothing changed in 2.0 -- this has
been
the
same since 1.0, if the platform's SDK version is the resource
version,
then the resource is ignored.
On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com wrote:
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote:
This is how I made my app resolution-independent and with Android
1.5
legacy
support:
Why did I put my high-dpi images in the drawable-hdpi-v4 folder
and
not
in
drawable-hdpi? Because the Android 1.5 OS can't handle the -hdpi
and
tries
to use these images instead of the ones in the res/drawable
folder.
The
-v4
flag is only meaningful for Android 1.6 and works perfect.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time
to
provide private support, and so won't reply to such e-mails. All
such
questions should be posted on public forums, where I and others can
see
and
answer them.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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.comwrote:
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/include/utils/ResourceTypes.hq=ResTable_configl=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
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually, we had
made a mistake and originally forgot the v4, which screwed up Cupcake,
but
now we added the v4 (and make no other changes), and it stopped working.
Am I missing something? Or is there perhaps a serious problem? Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion=5
/
Running on a WVGA854 emulator with density 240 and API 5, I get the
following results:
drawable-hdpi-v4
is ignored
drawable-hdpi-v5
is ignored, very strange
drawable-hdpi
works, but we can't use that
On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote:
I am pretty positive it works. Nothing changed in 2.0 -- this has
been
the
same since 1.0, if the platform's SDK version is the resource
version,
then the resource is ignored.
On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com wrote:
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote:
This is how I made my app resolution-independent and with
Android 1.5
legacy
support:
Why did I put my high-dpi images in the drawable-hdpi-v4 folder
and
not
in
drawable-hdpi? Because the Android 1.5 OS can't handle the -hdpi
and
tries
to use these images instead of the ones in the res/drawable
folder.
The
-v4
flag is only meaningful for Android 1.6 and works perfect.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have
time to
provide private support, and so won't reply to such e-mails. All
such
questions should be posted on public forums, where I and others can
see
and
answer them.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android WVGA support
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.comwrote:
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/include/utils/ResourceTypes.hq=ResTable_configl=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
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually, we
had
made a mistake and originally forgot the v4, which screwed up Cupcake,
but
now we added the v4 (and make no other changes), and it stopped
working.
Am I missing something? Or is there perhaps a serious problem? Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion=5
/
Running on a WVGA854 emulator with density 240 and API 5, I get the
following results:
drawable-hdpi-v4
is ignored
drawable-hdpi-v5
is ignored, very strange
drawable-hdpi
works, but we can't use that
On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote:
I am pretty positive it works. Nothing changed in 2.0 -- this has
been
the
same since 1.0, if the platform's SDK version is the resource
version,
then the resource is ignored.
On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com
wrote:
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote:
This is how I made my app resolution-independent and with
Android 1.5
legacy
support:
Why did I put my high-dpi images in the drawable-hdpi-v4 folder
and
not
in
drawable-hdpi? Because the Android 1.5 OS can't handle the
-hdpi and
tries
to use these images instead of the ones in the res/drawable
folder.
The
-v4
flag is only meaningful for Android 1.6 and works perfect.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have
time to
provide private support, and so won't reply to such e-mails. All
such
questions should be posted on public forums, where I and others can
see
and
answer them.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email
[android-developers] Re: Android WVGA support
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.
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.comwrote:
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=ensa=Ncd=1ct=rc#uX1GffpyOZk/include/utils/ResourceTypes.hq=ResTable_configl=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
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually, we
had
made a mistake and originally forgot the v4, which screwed up Cupcake,
but
now we added the v4 (and make no other changes), and it stopped
working.
Am I missing something? Or is there perhaps a serious problem? Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion=5
/
Running on a WVGA854 emulator with density 240 and API 5, I get the
following results:
drawable-hdpi-v4
is ignored
drawable-hdpi-v5
is ignored, very strange
drawable-hdpi
works, but we can't use that
On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote:
I am pretty positive it works. Nothing changed in 2.0 -- this has
been
the
same since 1.0, if the platform's SDK version is the resource
version,
then the resource is ignored.
On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com
wrote:
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com
wrote:
This is how I made my app resolution-independent and with
Android 1.5
legacy
support:
Why did I put my high-dpi images in the drawable-hdpi-v4
folder and
not
in
drawable-hdpi? Because the Android 1.5 OS can't handle the
-hdpi and
tries
to use these images instead of the ones in the res/drawable
folder.
The
-v4
flag is only meaningful for Android 1.6 and works perfect.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have
time to
provide private support, and so won't reply to such e-mails. All
such
questions should be posted on public forums, where I and others
can see
and
answer them.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public
[android-developers] Re: Android WVGA support
On Wed, Oct 21, 2009 at 10:38 PM, Nikolay Ananiev devuni...@gmail.comwrote: 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 hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
On Wed, Oct 21, 2009 at 4:09 PM, Artem p.ar...@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 hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. On Tue, Sep 15, 2009 at 8:17 AM, Mark Murphy mmur...@commonsware.comwrote: 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 Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
[android-developers] Re: Android WVGA support
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 minSdkVersion and targetSdkVersion the same, since you are again tuned for Donut and compatible with 1.5. On Tue, Sep 15, 2009 at 8:17 AM, Mark Murphy mmur...@commonsware.comwrote: 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 Android framework engineer hack...@android.com Note: please don't send private questions to me, as
[android-developers] Re: Android WVGA support
Nope, victory declared too early -- supports-screens actually puts it out of compatibility mode, which defeats the purpose. :( Artem On Oct 21, 7:18 pm, Artem p.ar...@gmail.com wrote: 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 minSdkVersion and targetSdkVersion the same, since you are again tuned for Donut and compatible with 1.5. On Tue, Sep 15, 2009 at 8:17 AM, Mark Murphy mmur...@commonsware.comwrote: 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
[android-developers] Re: Android WVGA support
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. On Thu, Oct 22, 2009 at 2:09 AM, 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 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. On Tue, Sep 15, 2009 at 8:17 AM, Mark Murphy mmur...@commonsware.com wrote: 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.
[android-developers] Re: Android WVGA support
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? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
ellipsoidmob...@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! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. On Tue, Sep 15, 2009 at 8:17 AM, Mark Murphy mmur...@commonsware.comwrote: 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 Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. On Tue, Sep 8, 2009 at 11:26 PM, gasolin gaso...@gmail.com wrote: 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 Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. On Sep 9, 7:35 am, Dianne Hackborn hack...@android.com wrote: 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. On Tue, Sep 8, 2009 at 11:26 PM, gasolin gaso...@gmail.com wrote: 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 Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
You'd do supports-sdk android:minSdkVersion=3 android:targetSdkVersion=4 / and then configure the rest of the manifest as desired. On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton a...@funkyandroid.com wrote: 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. On Sep 9, 7:35 am, Dianne Hackborn hack...@android.com wrote: 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. On Tue, Sep 8, 2009 at 11:26 PM, gasolin gaso...@gmail.com wrote: 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 Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
Thanks. Al. On Sep 9, 5:37 pm, Dianne Hackborn hack...@android.com wrote: You'd do supports-sdk android:minSdkVersion=3 android:targetSdkVersion=4 / and then configure the rest of the manifest as desired. On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton a...@funkyandroid.com wrote: 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. On Sep 9, 7:35 am, Dianne Hackborn hack...@android.com wrote: 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. On Tue, Sep 8, 2009 at 11:26 PM, gasolin gaso...@gmail.com wrote: 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 Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
Did you mean uses-sdk? On Sep 9, 12:37 pm, Dianne Hackborn hack...@android.com wrote: You'd do supports-sdk android:minSdkVersion=3 android:targetSdkVersion=4 / and then configure the rest of the manifest as desired. On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton a...@funkyandroid.com wrote: 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. On Sep 9, 7:35 am, Dianne Hackborn hack...@android.com wrote: 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. On Tue, Sep 8, 2009 at 11:26 PM, gasolin gaso...@gmail.com wrote: 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 Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
Sorry, yes. On Wed, Sep 9, 2009 at 6:59 PM, Ed Burnette ed.burne...@gmail.com wrote: Did you mean uses-sdk? On Sep 9, 12:37 pm, Dianne Hackborn hack...@android.com wrote: You'd do supports-sdk android:minSdkVersion=3 android:targetSdkVersion=4 / and then configure the rest of the manifest as desired. On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton a...@funkyandroid.com wrote: 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. On Sep 9, 7:35 am, Dianne Hackborn hack...@android.com wrote: 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. On Tue, Sep 8, 2009 at 11:26 PM, gasolin gaso...@gmail.com wrote: 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 Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. On Sep 7, 11: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. 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! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. On Mon, Sep 7, 2009 at 11:37 PM, Don Tran arro...@gmail.com wrote: 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 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 Let me correct this: 1.5 HVGA 1.5 w...@160dpi 1.6 w...@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 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. On Sep 8, 7:22 am, Howard M. Harte hhar...@gmail.com wrote: 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
On Mon, Sep 7, 2009 at 11:29 PM, Romain Guyromain...@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: q...@120dpi (low) h...@160dpi (med) WVGA(800854)@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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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: On Mon, Sep 7, 2009 at 11:29 PM, Romain Guyromain...@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: q...@120dpi (low) h...@160dpi (med) WVGA(800854)@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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. On Tue, Sep 8, 2009 at 9:06 AM, Howard M. Harte hhar...@gmail.com wrote: 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 q...@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 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 q...@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 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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. On Sep 8, 4:44 pm, Romain Guy romain...@google.com wrote: 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 h...@160dpi an w...@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 q...@160dpi display... it would be very tiny. The point is that it wouldn't help you at all. -- 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
On Tue, Sep 8, 2009 at 10:44 AM, Al Suttona...@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 dpidpi will scale the emulator to roughly emulate the actual screen size. Using '-scale 96dpi' on a w...@160dpi and w...@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. Xav -- Xavier Ducrohet Android Developer Tools Engineer Google Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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.comwrote: 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 Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
On Tue, Sep 8, 2009 at 11:33 AM, Dianne Hackborn hack...@android.comwrote: 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 Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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=126js=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 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?, tryhttp://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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
On Mon, Sep 7, 2009 at 2:12 PM, Mark Murphy mmur...@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 hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
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)... -- 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! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
