android:targetSdkVersion An integer designating the API Level that the application is targetting.
With this attribute set, the application says that it is able to run on older versions (down to minSdkVersion), but was explicitly tested to work with the version specified here. Specifying this target version allows the platform to disable compatibility settings that are not required for the target version (which may otherwise be turned on in order to maintain forward-compatibility) or enable newer features that are not available to older applications. This does not mean that you can program different features for different versions of the platform—it simply informs the platform that you have tested against the target version and the platform should not perform any extra work to maintain forward-compatibility with the target version.
Introduced in: API Level 4
I'm curious because it appears that switching from:
Can change defaults for supports-screens. Can also disable compatibility features, like reporting a smaller size than the actual display and scaling your app up.
> android:targetSdkVersion > An integer designating the API Level that the application is > targetting.
> With this attribute set, the application says that it is able to > run on older versions (down to minSdkVersion), but was explicitly > tested to work with the version specified here. Specifying this target > version allows the platform to disable compatibility settings that are > not required for the target version (which may otherwise be turned on > in order to maintain forward-compatibility) or enable newer features > that are not available to older applications. This does not mean that > you can program different features for different versions of the > platform—it simply informs the platform that you have tested against > the target version and the platform should not perform any extra work > to maintain forward-compatibility with the target version.
> Introduced in: API Level 4
> I'm curious because it appears that switching from:
> Can change defaults for supports-screens. Can also disable > compatibility features, like reporting a smaller size than the actual > display and scaling your app up.
> > android:targetSdkVersion > > An integer designating the API Level that the application is > > targetting.
> > With this attribute set, the application says that it is able to > > run on older versions (down to minSdkVersion), but was explicitly > > tested to work with the version specified here. Specifying this target > > version allows the platform to disable compatibility settings that are > > not required for the target version (which may otherwise be turned on > > in order to maintain forward-compatibility) or enable newer features > > that are not available to older applications. This does not mean that > > you can program different features for different versions of the > > platform—it simply informs the platform that you have tested against > > the target version and the platform should not perform any extra work > > to maintain forward-compatibility with the target version.
> > Introduced in: API Level 4
> > I'm curious because it appears that switching from:
On Wed, Jan 6, 2010 at 3:10 PM, Matt Kanninen <mathias...@gmail.com> wrote: > <supports-screens android:smallScreens="false" > android:normalScreens="true" android:largeScreens="true" />
If you don't specify anyDensity, then the system will run your app in density compatibility mode on high and low density devices. You really want to avoid this, since it can result in some artifacts in the UI such as some text being clipped.
If you are designing your app to support different screens/densities, I highly recommend that you make the target SDk version at least 4, since this will allow the system to do the correct default configuration to make it work correctly. It also allows various other compatibility features to be turned off, which we try to document under each API version here:
As for running out of memory -- it is probably because outside of compatibility mode the system is being allowed to pre-scale some of your loaded bitmaps to allow them to be drawn faster. I would guess this is just a matter of you being close to the memory limit, and this pushing you over (the high density or large screen devices should always have a higher memory limit to account for this... though I don't think the emulator changes this, come to think of it, so it could just be an emulator issue).
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 try hard not test on the emulator, and have access to the Android phones users are using. This bug happened only on the Droid, and our application depends on the Camera and Mic to function.
> On Wed, Jan 6, 2010 at 3:10 PM, Matt Kanninen <mathias...@gmail.com> wrote: > > <supports-screens android:smallScreens="false" > > android:normalScreens="true" android:largeScreens="true" />
> If you don't specify anyDensity, then the system will run your app in > density compatibility mode on high and low density devices. You really want > to avoid this, since it can result in some artifacts in the UI such as some > text being clipped.
> If you are designing your app to support different screens/densities, I > highly recommend that you make the target SDk version at least 4, since this > will allow the system to do the correct default configuration to make it > work correctly. It also allows various other compatibility features to be > turned off, which we try to document under each API version here:
> As for running out of memory -- it is probably because outside of > compatibility mode the system is being allowed to pre-scale some of your > loaded bitmaps to allow them to be drawn faster. I would guess this is just > a matter of you being close to the memory limit, and this pushing you over > (the high density or large screen devices should always have a higher memory > limit to account for this... though I don't think the emulator changes > this, come to think of it, so it could just be an emulator issue).
> 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.
The camera doesn't use memory (for the most part) that would be accounted
against the app and thus cause you to run out of memory. It is, however, a
higher megapixel camera, and the resulting bitmaps you are making due to
that in combination with the additional memory needed for higher density
resources could easily account for you using too much memory.
On Fri, Jan 8, 2010 at 2:38 PM, Matt Kanninen <mathias...@gmail.com> wrote:
> Diane,
> I try hard not test on the emulator, and have access to the Android
> phones users are using. This bug happened only on the Droid, and our
> application depends on the Camera and Mic to function.
> java.lang.OutOfMemoryError: bitmap size exceeds VM budget
> Sometimes out of memory errors, especially DEVICE SPECIFIC MEMORY
> ERRORS, are best fixed in the framework, or the specific devices code.
> I can't help debug this issue too much longer either, I'll be off the
> project, and on to other Android applications soon.
> -MK
> On Jan 6, 4:27 pm, Dianne Hackborn <hack...@android.com> wrote:
> > On Wed, Jan 6, 2010 at 3:10 PM, Matt Kanninen <mathias...@gmail.com>
> wrote:
> > > <supports-screens android:smallScreens="false"
> > > android:normalScreens="true" android:largeScreens="true" />
> > If you don't specify anyDensity, then the system will run your app in
> > density compatibility mode on high and low density devices. You really
> want
> > to avoid this, since it can result in some artifacts in the UI such as
> some
> > text being clipped.
> > If you are designing your app to support different screens/densities, I
> > highly recommend that you make the target SDk version at least 4, since
> this
> > will allow the system to do the correct default configuration to make it
> > work correctly. It also allows various other compatibility features to
> be
> > turned off, which we try to document under each API version here:
> > As for running out of memory -- it is probably because outside of
> > compatibility mode the system is being allowed to pre-scale some of your
> > loaded bitmaps to allow them to be drawn faster. I would guess this is
> just
> > a matter of you being close to the memory limit, and this pushing you
> over
> > (the high density or large screen devices should always have a higher
> memory
> > limit to account for this... though I don't think the emulator changes
> > this, come to think of it, so it could just be an emulator issue).
> > 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+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
