On Tuesday, July 17, 2012 6:59:08 PM UTC+2, Dianne Hackborn wrote: > > You can put your data in your own content provider.
I was doing that some time ago, but then I stopped because this imagery is already cached on SD, so I figured it was more direct to just pass through a file:// URI. I'll look into reverting it; thanks for the reminder. 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? > The full discussion is here: https://groups.google.com/d/topic/android-developers/oAl2Ix9erSY/discussion The summary is, passing middling-large imagery to a widget doesn't work; IPC fails silently. The content provider was the recommended workaround, and it's done well until now. > 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. > Understood. The widgets in question aren't a security risk (I'd be quite interested if someone found a way to reuse my imagery), but it's a good point for other widgets. > This isn't a launcher bug. Launcher is just one possible host of app > widgets. > That's what I said in my OP, yes. To fix this from the content-consumer side, every appwidget host out there would have to request the new permission. Which isn't likely. > 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 > Which brings me back around to my main point: this is a permission change that needs to be made *in an app other than the one that's failing*. The file:// URI content provider can't make the change; it's the content-consuming app that needs to request the new permission. And that's not in the docs, nor is it something that's necessarily obvious to the content-consumer dev, especially if the testing they're doing is with non-file URIs. You say it's not a Launcher bug; I do see your point, but I've had differing opinions on that. If Launcher is happily accepting file:// URIs that point to external storage, shouldn't it be requesting the appropriate permission to resolve that URI? On Tuesday, July 17, 2012 7:19:05 PM UTC+2, Mark Murphy (a Commons Guy) wrote: > > > 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. If the file:// URI is pointing to external storage, that is not terribly surprising. > Sure, it's not in hindsight. But see my previous note above - it's not documented, nor especially obvious. > > 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. > > It's more that anyone using URI values from third-party sources need > to add the permission, if there is a chance that such URI values point > to external storage. They would already need WRITE_EXTERNAL_STORAGE if > they would try writing to such URIs, though admittedly that is less > common. > > This is what concerns me. There's nothing in the docs that mentions the URI implications of this change, so URI-consumers probably aren't thinking of it. I'm looking beyond my own widget issues here. > > 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. > > Which means you can't reliably use your workaround anymore. Yup, I'd worked that out already, thanks! :^) > > > 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. > > Which is why we need to publicize this more. I have been holding off > doing so until I have JB hardware, which I will next week. > > And not to beat a dead horse... what needs publicizing in this case is that this change breaks apps (the content providers) *which can't implement the fix*. > > 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? > > That would pretty much eliminate the purpose of the permission. > Uh, yeah, that hadn't occurred to me. Good point! 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
