You can put your data in your own content provider. Actually, you should stop and think about doing this approach at all. You say this is for an app widget... why not provide the bitmaps as bitmaps instead of having it load the data elsewhere? Note that if you don't provide the bitmaps directly, anything you do means you are making this data globally readable by everyone (because you can't make any assumptions about the permissions available to whoever is hosting your app widget), which is generally a big no-no for security reasons.
This isn't a launcher bug. Launcher is just one possible host of app widgets. You can't assume whoever is hosting your app widget will have any specific permissions. Also this is why the protection in JB is turned off by default. Right now app developers should be updating their apps to fix these issues, so when this protection is turned on for all users in a future release they will still work. Btw this change is described in the permissions section of the 4.1 API overview: http://developer.android.com/about/versions/android-4.1.html On Tue, Jul 17, 2012 at 9:21 AM, String <sterling.ud...@googlemail.com>wrote: > Throwing this out for discussion here... > > Now that I have a JB device in-hand, I've found a sneaky little problem > with the new READ_EXTERNAL_STORAGE permission. Specifically, if you pass > another app a URI - say via a ContentProvider - that uses the "file://" > protocol, then the receiving app NEEDS the new permission in order to read > from that URI. Thus, the new permission has the (presumably unintended) > potential to break an unknown number of existing apps when it enters > production: their ContentProviders will suddenly cease to work. > > I ran into this because I've re-implemented most of my AppWidgets to use > file:// URIs for their imagery, rather than passing the bitmap directly > through RemoteViews. [This was done as a workaround for > http://code.google.com/p/android/issues/detail?id=17509.] And it works > fine unless you enable the READ_EXTERNAL_STORAGE check on JB hardware, at > which point the images fail to load due to a permission failure from > Launcher. > > One solution would obviously be to report this as a bug in Launcher, and > for the appropriate team at Google to add READ_EXTERNAL_STORAGE to its > permissions. Not a great solution, though, because it only fixes this > single case. All other homescreen-replacement apps, from everyone from OEMs > to indie devs, would need to make the same change. And I can promise you > some won't. > > Another possible solution would be for me to keep these images in internal > storage, making them world-readable so the URI recipient can read them. I > haven't tested this to see if it'll work, but even assuming it does, it's a > change that anyone who generates a file:// URI would need to make. And > probably, some of them are generating URIs to files that can't reasonably > be moved to internal storage. So we're back in the business of breaking > existing apps. > > I don't know the internals well enough, but is it possible that there's a > solution that could be implemented at the platform level? That whatever > platform mechanism fulfills file:// URIs would bypass the > READ_EXTERNAL_STORAGE permission check? > > Or is this by design, platform team? If so, I think it really needs to be > publicized. > > Comments? > > String > > -- > 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 -- 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
