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" android:targetSdkVersion="4" />
3. Leaved all the standard images for the 320x480 resolution in the
res/drawable folder
4. Put all images for the high-resolution devices (800x480) in the
res/drawable-hdpi-v4 folder
5. Put all images for the low-resolution devices (240x320) in the
res/drawable-ldpi-v4 folder
6. Make sure you are not using Android 1.6 APIs in your code (This is very
important to check manually, because Eclipse will not warn you)
7. Compile
Why did I put my high-dpi images in the drawable-hdpi-v4 folder and not in
drawable-hdpi? Because the Android 1.5 OS can't handle the -hdpi and tries
to use these images instead of the ones in the res/drawable folder. The -v4
flag is only meaningful for Android 1.6 and works perfect.
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 support it you'll have to create a custom APK for it.
On Thu, Oct 22, 2009 at 2:09 AM, 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
> > 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 <mmur...@commonsware.com
> >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
> > hack...@android.com
> >
> > 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
