On Tue, Sep 8, 2009 at 1:21 PM, Al Sutton <a...@funkyandroid.com> 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 because QVGA is a smaller physical screen size than applications are currently targeted for (given a portrait screen of the same width as HVGA, a QVGA screen has less vertical space). If an application is designed to use all of the space on an HVGA screen, there is little that can be done to display it on QVGA except doing a vertical pan and scan, or scaling it down even more so it is letterboxed on the sides. Yuck.
> From the docs in the open repo SDK I would have expected apps to be > available and scaled down using the 0.75 factor.
Density is a separate aspect of the screen, and easily adjusted for by the platform. It doesn't cause any filtering on the market.
The upcoming blog post and documentation will cover this... I don't really want to spend too much time on it here, reproducing the various tables and such showing how this all works.
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.
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 they install the app and feel bad
while the app hang (mostly without notice).
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 a hardware requirement without having a mechanism
for applications to specify that they need the hardware and a strategy for
grand-fathering existing applications into the filtering.
On Tue, Sep 8, 2009 at 11:26 PM, gasolin <gaso...@gmail.com> wrote:
> 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 they install the app and feel bad
> while the app hang (mostly without notice).
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.
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 supports-screens manifest tag and a separate
one for cupcake devices because cupcake won't run apps with minSDK >
3. If there is also a lite & paid for version you're then into 4 app
listings for the same app (lite, paid-for, multi-resolution lite,
multi-resolution paid-for), which seems like its' going to be a it of
a pain.
Thanks,
Al.
On Sep 9, 7:35 am, Dianne Hackborn <hack...@android.com> wrote:
> 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 a hardware requirement without having a mechanism
> for applications to specify that they need the hardware and a strategy for
> grand-fathering existing applications into the filtering.
> On Tue, Sep 8, 2009 at 11:26 PM, gasolin <gaso...@gmail.com> wrote:
> > 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 they install the app and feel bad
> > while the app hang (mostly without notice).
> 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.
On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton <a...@funkyandroid.com> 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 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 supports-screens manifest tag and a separate
> one for cupcake devices because cupcake won't run apps with minSDK >
> 3. If there is also a lite & paid for version you're then into 4 app
> listings for the same app (lite, paid-for, multi-resolution lite,
> multi-resolution paid-for), which seems like its' going to be a it of
> a pain.
> Thanks,
> Al.
> On Sep 9, 7:35 am, Dianne Hackborn <hack...@android.com> wrote:
> > 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 a hardware requirement without having a
> mechanism
> > for applications to specify that they need the hardware and a strategy
> for
> > grand-fathering existing applications into the filtering.
> > On Tue, Sep 8, 2009 at 11:26 PM, gasolin <gaso...@gmail.com> wrote:
> > > 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 they install the app and feel bad
> > > while the app hang (mostly without notice).
> > 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.
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'd do <supports-sdk android:minSdkVersion="3"
> android:targetSdkVersion="4" /> and then configure the rest of the manifest
> as desired.
> On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton <a...@funkyandroid.com> 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 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 supports-screens manifest tag and a separate
> > one for cupcake devices because cupcake won't run apps with minSDK >
> > 3. If there is also a lite & paid for version you're then into 4 app
> > listings for the same app (lite, paid-for, multi-resolution lite,
> > multi-resolution paid-for), which seems like its' going to be a it of
> > a pain.
> > Thanks,
> > Al.
> > On Sep 9, 7:35 am, Dianne Hackborn <hack...@android.com> wrote:
> > > 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 a hardware requirement without having a
> > mechanism
> > > for applications to specify that they need the hardware and a strategy
> > for
> > > grand-fathering existing applications into the filtering.
> > > On Tue, Sep 8, 2009 at 11:26 PM, gasolin <gaso...@gmail.com> wrote:
> > > > 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 they install the app and feel bad
> > > > while the app hang (mostly without notice).
> > > 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.
> 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'd do <supports-sdk android:minSdkVersion="3"
> android:targetSdkVersion="4" /> and then configure the rest of the manifest
> as desired.
> On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton <a...@funkyandroid.com> 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 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 supports-screens manifest tag and a separate
> > one for cupcake devices because cupcake won't run apps with minSDK >
> > 3. If there is also a lite & paid for version you're then into 4 app
> > listings for the same app (lite, paid-for, multi-resolution lite,
> > multi-resolution paid-for), which seems like its' going to be a it of
> > a pain.
> > Thanks,
> > Al.
> > On Sep 9, 7:35 am, Dianne Hackborn <hack...@android.com> wrote:
> > > 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 a hardware requirement without having a
> > mechanism
> > > for applications to specify that they need the hardware and a strategy
> > for
> > > grand-fathering existing applications into the filtering.
> > > On Tue, Sep 8, 2009 at 11:26 PM, gasolin <gaso...@gmail.com> wrote:
> > > > 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 they install the app and feel bad
> > > > while the app hang (mostly without notice).
> > > 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.
> 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.
On Wed, Sep 9, 2009 at 6:59 PM, Ed Burnette <ed.burne...@gmail.com> wrote:
> Did you mean <uses-sdk>?
> On Sep 9, 12:37 pm, Dianne Hackborn <hack...@android.com> wrote:
> > You'd do <supports-sdk android:minSdkVersion="3"
> > android:targetSdkVersion="4" /> and then configure the rest of the
> manifest
> > as desired.
> > On Wed, Sep 9, 2009 at 2:12 AM, Al Sutton <a...@funkyandroid.com> 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 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 supports-screens manifest tag and a separate
> > > one for cupcake devices because cupcake won't run apps with minSDK >
> > > 3. If there is also a lite & paid for version you're then into 4 app
> > > listings for the same app (lite, paid-for, multi-resolution lite,
> > > multi-resolution paid-for), which seems like its' going to be a it of
> > > a pain.
> > > Thanks,
> > > Al.
> > > On Sep 9, 7:35 am, Dianne Hackborn <hack...@android.com> wrote:
> > > > 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 a hardware requirement without having a
> > > mechanism
> > > > for applications to specify that they need the hardware and a
> strategy
> > > for
> > > > grand-fathering existing applications into the filtering.
> > > > On Tue, Sep 8, 2009 at 11:26 PM, gasolin <gaso...@gmail.com> wrote:
> > > > > 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 they install the app and feel bad
> > > > > while the app hang (mostly without notice).
> > > > 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.
> > 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.
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.
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 different screen sizes, then anyone who hasn't upgraded to
Donut won't be able to see my app. Does this mean that we'll all end
up leaving 1.5SDK versions of our apps available on the market, and
then publishing donut/eclair versions with slightly different names?
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 version of your app that supports multiple screen sizes from a single APK.
My interpretation is that the manifest elements that Al Sutton and Ms. Hackborn were describing are used as market and installer filters -- the app will not be installed if you do not meet the manifest criteria. You might use this, for example, as a stopgap to prevent people from trying to use your app on QVGA or WVGA screens before you have had a chance to add support for them.
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.
Again, this is an educated guess, based upon what we had been told for the last ~15 months on this issue, and it could be they have a whole 'nuther system in mind now.
> Use resource sets, and ship one version of your app that supports
> multiple screen sizes from a single APK.
> <snip>
> 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 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?
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.
> 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.
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 <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.
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.
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.
> 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.
> 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 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 <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.
> > 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.
> > > 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 <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.
> > > 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.
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.
> > 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.
On Wed, Oct 21, 2009 at 10:38 PM, Nikolay Ananiev <devuni...@gmail.com>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 support it you'll have to create a custom APK for it.
Is it a high density device? I thought its screen was larger so it would actually count as medium density. Anyway, as you say they did their own customization for their screen support, so are not following the standard platform, so won't be compatible. I would assume that Market won't be on it until this is resolved.
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.
On Wed, Oct 21, 2009 at 4:09 PM, Artem <p.ar...@gmail.com> 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 density display, you will get the nice high density graphics for any buttons or other stock widgets. This is because the framework is picking the correct density graphics for the screen.
Note, however, that this can only happen if you are loading the image as a Drawable from Resources, since there is special magic in BitmapDrawable and NinePatchDrawable to load the bitmap based on the true screen report to the app metrics that match the compatibility scaling it is. Also, if you draw anything into an off-screen bitmap, then you will force everything in to the compatibility scaling and lose any high-density graphics.
As a general rule, the compatibility modes are only there for existing applications that were written before knowing about multiple screens. The first thing you should do is turn them off. I don't really understand why you are trying to keep your app running in compatibility mode on 1.6; that is by and large really what you -don't- want.
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.
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 <devuni...@gmail.com> wrote:
> 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.
> 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 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.
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 <codesec...@gmail.com> wrote:
> Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
> On Oct 22, 8:38 am, Nikolay Ananiev <devuni...@gmail.com> 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 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.
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.
> 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 <codesec...@gmail.com> wrote:
> > Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
> > On Oct 22, 8:38 am, Nikolay Ananiev <devuni...@gmail.com> 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 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.
> 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.
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
back so we can take action -- we need to publish a new APK for the Cupcake
users, but we can't figure out how to do that without breaking Eclair.
> 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-hdpi
> works, but we can't use that
> On Oct 29, 3:45 pm, Dianne Hackborn <hack...@android.com> wrote:
> > 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 <codesec...@gmail.com> wrote:
> > > Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
> > > On Oct 22, 8:38 am, Nikolay Ananiev <devuni...@gmail.com> 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 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.
> > 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.
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asymetric. A default piece of data will match
every request
// but a request for the default should not match odd specifics
// (ie, request with no mcc should not match a particular mcc's
data)
// settings is the requested settings
inline bool match(const ResTable_config& settings) const {
...
Of course I am not sure where this is used, but I only see an != here.
Hopefully, this is not the right code. Or perhaps there is new code in
Eclair that is not available yet, that makes this better.
Thanks for the help.
Artem
On Oct 29, 9:12 pm, Artem Petakov <p.ar...@gmail.com> wrote:
> 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
> back so we can take action -- we need to publish a new APK for the Cupcake
> users, but we can't figure out how to do that without breaking Eclair.
> Artem
> On Thu, Oct 29, 2009 at 11:00 AM, webmonkey <webmonke...@gmail.com> wrote:
> > 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-hdpi
> > works, but we can't use that
> > On Oct 29, 3:45 pm, Dianne Hackborn <hack...@android.com> wrote:
> > > 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 <codesec...@gmail.com> wrote:
> > > > Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
> > > > On Oct 22, 8:38 am, Nikolay Ananiev <devuni...@gmail.com> 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 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.
> > > 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.
