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

Reply via email to