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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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:
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).
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
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
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,
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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:
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
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
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
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
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
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
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
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
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
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
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
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.
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,
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
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
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
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
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
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?
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
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
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
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:
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
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
60 matches
Mail list logo
