On Tue, Jul 17, 2012 at 11:46 AM, String <sterling.ud...@googlemail.com>wrote:
> 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
