We got it! You need to put this in the manifest: <supports-screens android:anyDensity="true" />
Artem On Oct 21, 7:09 pm, Artem <[email protected]> wrote: > On Sep 15, 1:05 pm, Dianne Hackborn <[email protected]> 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 <[email protected]>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. > > > > 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 > > [email protected] > > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
