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 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 <[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
-~----------~----~----~----~------~----~------~--~---
