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 wrote:
> Th
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.
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
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 sur
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
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 wrote:
> YES drawabl
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 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 wo
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 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
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 wrote:
> This will sound crazy, but -v6 works for me. There must be a strange reason
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 wrote:
> Ah, that's too bad. Bugs happen.
>
> I am trying to unders
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).
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 wrote:
>
> Trying to help by digging up the code.
>
> I found this:
>
> http://www.google.com/codesearc
Trying to help by digging up the code.
I found this:
http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#uX1GffpyOZk/include/utils/ResourceTypes.h&q=ResTable_config&l=787
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asym
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
b
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
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-hdp
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 wrote:
>
> Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
>
> On O
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev 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
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 wrote:
> Why did I put my high-dpi images in the drawable-hdpi-v4 folder and not in
> drawable-hdpi? Becau
On Wed, Oct 21, 2009 at 4:09 PM, Artem 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 densi
On Wed, Oct 21, 2009 at 10:38 PM, Nikolay Ananiev wrote:
> The only problem with this setup is with the ARCHOS 5 Tablet - it's the
> only Android 1.5 device that has a resolution different than 320x480 and it
> won't be able to load the images in the drawable-hdpi-v4 folder. So, if you
> want to s
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:
3. Leaved all the standard images for the 320x480
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 wrote:
> We got it!
>
> You need to put this in the manifest:
>
>
> Artem
>
> On Oct 21, 7:09 pm, Artem wrote:
>
>
>
> > On Sep 15, 1:
We got it!
You need to put this in the manifest:
Artem
On Oct 21, 7:09 pm, Artem wrote:
> On Sep 15, 1:05 pm, Dianne Hackborn 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
>
On Sep 15, 1:05 pm, Dianne Hackborn 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
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:targetSdkVers
> 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 conce
> Use resource sets, and ship one version of your app that supports
> multiple screen sizes from a single APK.
>
>
> 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 f
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 versi
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
Sorry, yes.
On Wed, Sep 9, 2009 at 6:59 PM, Ed Burnette wrote:
>
> Did you mean ?
>
> On Sep 9, 12:37 pm, Dianne Hackborn wrote:
> > You'd do > android:targetSdkVersion="4" /> and then configure the rest of the
> manifest
> > as desired.
> >
> >
> >
> > On Wed, Sep 9, 2009 at 2:12 AM, Al Sutto
Did you mean ?
On Sep 9, 12:37 pm, Dianne Hackborn wrote:
> You'd do android:targetSdkVersion="4" /> and then configure the rest of the manifest
> as desired.
>
>
>
> On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton wrote:
>
> > Dianne,
>
> > In the blog post can you cover how to produce one app whic
Thanks.
Al.
On Sep 9, 5:37 pm, Dianne Hackborn wrote:
> You'd do android:targetSdkVersion="4" /> and then configure the rest of the manifest
> as desired.
>
>
>
> On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton wrote:
>
> > Dianne,
>
> > In the blog post can you cover how to produce one app which w
You'd do and then configure the rest of the manifest
as desired.
On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton 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 momen
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 su
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
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 th
On Tue, Sep 8, 2009 at 1:21 PM, Al Sutton 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
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
beca
On Tue, Sep 8, 2009 at 11:33 AM, Dianne Hackborn wrote:
> And this all ignores what is to me probably likely to be an even bigger
> part of the market, lower density QVGA and WQVGA screens.
>
And speaking of... http://www.htc.com/www/product/tattoo/overview.html
One of the important things to k
On Tue, Sep 8, 2009 at 10:44 AM, Al Sutton 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 Marke
On Tue, Sep 8, 2009 at 10:44 AM, Al Sutton 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
> 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
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 QV
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, wh
> 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 minS
> 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 ea
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 Mon, Sep 7, 2009 at 11:29 PM, Romain Guy 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 ru
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
>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 Googl
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
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 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 v
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 befo
> 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.x
> 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 hig
On Sep 7, 3:41 pm, Mark Murphy 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 dev
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 fi
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 H
On Mon, Sep 7, 2009 at 2:12 PM, Mark Murphy 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 su
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 WVG
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'
61 matches
Mail list logo
