1

I know similar questions have been asked several times here, but I am looking for a workaround.

Considering the "Share"-function. Apps like Google Photos and others grant uri permissions for receiving-app components (i.e. the launched activity which is registered as share receiver). My "share receiver" needs to save data to the disk and thus hands on the uri to a service that handles saving in the background. However, this is where it gets nasty. When the originally permission-granted activity dies / is not in foreground, the uri permission is revoked and the service throws a Securiy Exception when trying to access the data.

My standard approach is to keep the activity alive, as I've not found any work around yet. However, I don't have any indicator (other than a list of "bad" providers from my experience) to check if this is needed, as I don't want to have the activity need to stay alive for all files.

TLDR: So: Is there a way to either

  • a) "transfer" the uri permission to the background service to avoid the activity-stay-alive workaround
  • or b) check if the current context has permissions / which components have permission to access / need to stay alive ... etc.

Thanks in advance!

Aeefire
  • 888
  • 10
  • 25
  • 1
    ""transfer" the uri permission to the background service to avoid the activity-stay-alive workaround" -- no, and that shouldn't be needed. If you have `android:process` on your `` element, to have it run in a separate process, *then* I can see you perhaps running into this sort of trouble, as I haven't tried that scenario. Otherwise, the `Uri` permission grant is supposed to be for the life of the process containing the activity that received the permission. – CommonsWare Jul 25 '16 at 00:00
  • I thought that it shouldn't be needed too but it's not the case for e.g. Google Photos or Giphy. Most content providers work without issues! The service declaration is a mere: But nevertheless, processes are a good hint. I'll try to examine if service and activity are running on different processes (despite no explicit declaration) and respond again (although all components should run on the same process by default...). Thanks for your input so far. – Aeefire Jul 25 '16 at 07:50
  • "I thought that it shouldn't be needed too but it's not the case for e.g. Google Photos or Giphy" -- that suggests that those apps are doing something stupid, though I cannot think of what they could be doing that would cause problems here. The only workaround I can think of would be to have the activity make a local copy of the data (e.g., slurp the content to a local file), then kick off the service to work with the local file. – CommonsWare Jul 25 '16 at 10:28
  • Well.. Yes, but considering it's Google (for the Photos app) I somewhat doubt that it's stupid and unwanted. And a local copy would defeat the whole purpose of my app (which is simply storing the file, as I essentially would do it twice then) and possibly be bad for big files.... – Aeefire Jul 25 '16 at 14:10

0 Answers0