Re: [android-developers] New READ_EXTERNAL_STORAGE permission breaks file:// URIs
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.comwrote: 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
Re: [android-developers] New READ_EXTERNAL_STORAGE permission breaks file:// URIs
On Tue, Jul 17, 2012 at 12:21 PM, String sterling.ud...@googlemail.com 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. 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. 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. 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. 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. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- 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
Re: [android-developers] New READ_EXTERNAL_STORAGE permission breaks file:// URIs
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
Re: [android-developers] New READ_EXTERNAL_STORAGE permission breaks file:// URIs
On Tue, Jul 17, 2012 at 11:46 AM, String sterling.ud...@googlemail.comwrote: 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. I would really suggest reducing the memory of your bitmaps then. This limit is actually important -- if you are pushing huge bitmaps into the launcher, you run the risk of the launcher failing when it exhausts its heap due to them. We have limits. Limits are important. Respect the limits. :) 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. More than not likely, it's not going to happen. 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. Not sure what you mean not in the docs -- it is described in the document I pointed to. I do agree that there should be more discussion of this, and I can assure you there will be -- that is why we are doing things this way, to have the facility in place for JB for developers to test against before a later change actually impacts apps. 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? No. We are pushing to get away from the free-for-all of external storage; this is one of the steps in that. We want a system in which as few apps as possible are requesting these permissions. -- 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
Re: [android-developers] New READ_EXTERNAL_STORAGE permission breaks file:// URIs
2012/7/17 String sterling.ud...@googlemail.com 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. Can't you use a content provider that implements openFile() and uses ParcelFileDescriptor to return a reference to the same file(s) you have on the external storage? This, too, would avoid the unnecessary copying of bitmap data. IIRC, content:// URIs are supported by ImageView since 2.2. -- K -- 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
Re: [android-developers] New READ_EXTERNAL_STORAGE permission breaks file:// URIs
On Tuesday, July 17, 2012 9:15:39 PM UTC+2, Dianne Hackborn wrote: Not sure what you mean not in the docs -- it is described in the document I pointed to. What isn't documented is the impact on URI consumers, who don't think they're using external storage, so they don't think they need the new permission. My goal here is to publicize the fact that the new permission is required by such apps, who aren't reading external storage directly. 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
Re: [android-developers] New READ_EXTERNAL_STORAGE permission breaks file:// URIs
On Tuesday, July 17, 2012 9:33:48 PM UTC+2, Kostya Vasilyev wrote: Can't you use a content provider that implements openFile() and uses ParcelFileDescriptor to return a reference to the same file(s) you have on the external storage? This, too, would avoid the unnecessary copying of bitmap data. IIRC, content:// URIs are supported by ImageView since 2.2. Yes, I can revert to that; as I mentioned earlier, I had been doing that at first. I'll just need to do some version-dependent code since I still support pre-2.2. But that's not a big deal. 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
