It's a compatibility issue in this sense: * I have an app currently targeted at 1.5.
* I need to target 1.6 to support devices with lower screen densities. * For current users I need to continue supporting 1.5. * My code generates a picture based on bitmaps loaded via BitmapFactory.decodeResource(). * On a device with 1.6, that code doesn't produce the desired picture because the bitmaps are being scaled. * I can't place the bitmaps into no-dpi (not supported in 1.5). * I can't disable the scaling with the Option flag (not supported in 1.5) ergo. 1.5 and 1.6 are incompatible with each other, at least as far as my application is concerned (and I'm sure some others). Tom. 2009/10/1 Dianne Hackborn <hack...@android.com> > This isn't a compatibility issue -- 1.5 doesn't know anything about "nodpi" > so if you try to use it there you will not get the right result. (I am > pretty sure what happens is it sees this as a really high dpi and thus > scales it down.) It's just a case of not being able to use newer APIs on an > older platform. > > > On Thu, Sep 17, 2009 at 4:29 PM, Tom Gibara <m...@tomgibara.com> wrote: > >> I just published a simple class for dealing with this minor compatibility >> issue; it seems to be working well for my application and it might be useful >> for anyone else in the same situation. >> http://blog.tomgibara.com/post/190539066/android-unscaled-bitmaps >> >> Tom. >> <http://blog.tomgibara.com/post/190539066/android-unscaled-bitmaps> >> >> 2009/9/17 Tom Gibara <m...@tomgibara.com> >> >> Hmm, interesting... >>> Just had a chance to try this out on 1.5. >>> >>> If I move my bitmaps into a drawable-nodpi directory then the application >>> compiles and executes, but I don't see the images. Inspection with the >>> debugger (plus logging just to make sure) indicates that the bitmaps, when >>> loaded from "nodpi" always have a width and height of 1px. >>> >>> Move them back to the basic drawable directory and it all works perfectly >>> again. >>> >>> Shame, looks like it was *almost* implemented :) >>> >>> Tom. >>> >>> 2009/9/17 Romain Guy <romain...@google.com> >>> >>>> >>>> Give it a try, 1.5 already had all the scaling code based on display's >>>> density. I don't know about nodpi specifically but it's worth the try. >>>> >>>> On Thu, Sep 17, 2009 at 11:46 AM, Tom Gibara <m...@tomgibara.com> wrote: >>>> > Duh, I misread the docs for the inScaled flag. Thanks for pointing >>>> that out. >>>> > The drawable-nodpi/ sounds perfect, but I'm guessing I can't use that >>>> and >>>> > remain compatible with API 3, since I don't see "nodpi" listed the >>>> > documentation for resources in 1.5. >>>> > Tom. >>>> > >>>> > 2009/9/17 Romain Guy <romain...@google.com> >>>> >> >>>> >> > private Bitmap loadBitmap(int resId) { BitmapFactory.Options >>>> options = >>>> >> > new >>>> >> > BitmapFactory.Options(); options.inTargetDensity = 1; >>>> options.inDensity >>>> >> > = 1; >>>> >> > return BitmapFactory.decodeResource(context.getResources(), resId, >>>> >> > options); >>>> >> > } >>>> >> >>>> >> That's the wrong way to do it. You're assigning your bitmap a density >>>> >> of 1dpi, which can have bad consequences. There's a much simpler way >>>> >> to do it: just set options.inScaled = false. >>>> >> >>>> >> But the right way to do it really is to place the assets in the right >>>> >> directory: >>>> >> drawable-ldpi/ for 120dpi displays >>>> >> drawable-mdpi/ for 160dpi displays >>>> >> drawable-hdpi/ for 240dpi displays >>>> >> >>>> >> and in your case: >>>> >> drawable-nodpi/ for assets that should not be scaled. >>>> >> >>>> >> > I have two related queries: >>>> >> > Is there a simpler way of doing this? >>>> >> > Is there a way to support android:minSdkVersion="3" without jumping >>>> >> > through >>>> >> > the hoop of creating two implementations (for API 3 and API 4) of >>>> an >>>> >> > "image >>>> >> > loading" interface and selecting one at runtime? >>>> >> > Tom. >>>> >> > > >>>> >> > >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Romain Guy >>>> >> Android framework engineer >>>> >> romain...@android.com >>>> >> >>>> >> Note: please don't send private questions to me, as I don't have time >>>> >> to provide private support. All such questions should be posted on >>>> >> public forums, where I and others can see and answer them >>>> >> >>>> >> >>>> > >>>> > >>>> > > >>>> > >>>> >>>> >>>> >>>> -- >>>> Romain Guy >>>> Android framework engineer >>>> romain...@android.com >>>> >>>> Note: please don't send private questions to me, as I don't have time >>>> to provide private support. All such questions should be posted on >>>> public forums, where I and others can see and answer them >>>> >>>> >>>> >>> >> >> >> > > > -- > 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. > > > > > > -- Tom Gibara email: m...@tomgibara.com web: http://www.tomgibara.com blog: http://blog.tomgibara.com twitter: tomgibara --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
