Obsolete
Status Update
Comments
ra...@google.com <ra...@google.com>
ra...@google.com <ra...@google.com> #2
Thank you for the feedback. We’ve shared this with our product and engineering team for the possible consideration.
sa...@google.com <sa...@google.com>
fr...@gmail.com <fr...@gmail.com> #3
I am curious to know whether this is being considered for solving in the near term? I see it is designated as a P3/S3. For us this is quite a serious limitation. Any update?
fr...@gmail.com <fr...@gmail.com> #4
It has been over three months since this was submitted, and I have noticed very little activity. Is there an update on the likelihood of this getting addressed any time in the near term?
mu...@gmail.com <mu...@gmail.com> #5
If it is not possible to address in the near future, then at least mention this limitation in the documentation.
fr...@gmail.com <fr...@gmail.com> #6
Hi all - just checking in again. Any response to either me or Mark? This 128 grant limit is really a problem!
Thanks!
Tad
Thanks!
Tad
bo...@google.com <bo...@google.com> #7
As an update, Android 11 increased the
private static final int MAX_PERSISTED_URI_GRANTS = 512;
fr...@gmail.com <fr...@gmail.com> #8
That's good - can you tell me when will this be available in a release? And also, is it only for people running Android 11 or will it be supported back to API 21+?
Thanks!
Tad
Thanks!
Tad
fr...@gmail.com <fr...@gmail.com> #9
Hi I am reaching out again to understand whether this is an Android 11 and up only fix?
pr...@gmail.com <pr...@gmail.com> #10
Is there any progress or update to it? It's been many years
Description
AI-192.7142.36.36.6186006, JRE 1.8.0_212-release-1586-b04x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 1920x1200, 1920x1200
AS: 3.6 RC 3; Kotlin plugin: 1.3.61; Android Gradle Plugin: 3.6.0-rc03; Gradle: 5.6.4; NDK: from local.properties: (not specified), latest from SDK: (not found); LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)
Any app which uses a ContentResolver to invoke takePersistableUriPermission() in the manner described by the Android docs will fail doing so after 128 grants. For example:
private void chooseSamplePhotos() {
Intent intent = new Intent(Intent.ACTION_OPEN_DOCUMENT);
intent.addCategory(Intent.CATEGORY_OPENABLE);
intent.setType("*/*");
intent.setFlags(Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION);
String[] mimeTypes = {"image/*","video/*"};
intent.putExtra(Intent.EXTRA_MIME_TYPES, mimeTypes);
intent.putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true);
startActivityForResult(intent, FIND_FILES_CODE);
}
Then in onActivityResult, assuming the user selected multiple files:
protected void onActivityResult(int requestCode, int resultCode, @Nullable Intent data) {
if ( resultCode != Activity.RESULT_OK ||
requestCode != FIND_FILES_CODE ||
data == null ) {
return;
}
int takeFlags = data.getFlags() & (Intent.FLAG_GRANT_READ_URI_PERMISSION);
ArrayList<Uri> uriList = new ArrayList<>();
ContentResolver contentResolver = getContentResolver();
Uri uri = null;
try {
uri = data.getData();
if (uri != null) {
// Single item selected
contentResolver.takePersistableUriPermission(uri, takeFlags);
uriList.add(uri);
} else {
ClipData clipData = data.getClipData();
if (clipData != null) {
// Multiple items chosen
for (int x = 0; x < clipData.getItemCount(); x++) {
uri = clipData.getItemAt(x).getUri();
contentResolver.takePersistableUriPermission(uri, takeFlags);
uriList.add(uri);
}
} else {
return;
}
}
} catch (SecurityException se) {
Log.e("Test",
"Got SecurityException attempting to take persisted URI permissions, message was: " +
se.getMessage());
return;
}
}
This appears to be built in to the framework (see com.android.server.uri.UriGrantsManagerService, where private static final int MAX_PERSISTED_URI_GRANTS = 128 is defined and utilized).
This is artificially quite low. Our app, for example, allows users to create media playlists that reference media from a variety of sources via Uri, and we need persistence granted in order to accommodate their ability to reference these items upon application reboot. The work-around to use ACTION_GET_CONTENT and store media locally makes no sense in this case - why copy media to the mobile device when it is already stored in the cloud and can simply be streamed as needed?
It is understandable that a Uri may no longer be valid after some period of time and that this is a risk the app developer makes when utilizing ACTION_OPEN_DOCUMENT and takePersistableUriPermission(). However, it should be up to the app to manage that - not be prevented from handling an exception involving a Uri no longer being valid because the grant wasn't allowed in the first place.
If there is concern within the Android framework that allowing "unlimited" grants will bog down the system (which is a reasonable concern), there are better ways of handling this than artificially limiting it to 128.
I suggest allowing the limit to be set as a property (or if not, raising the value from 128 to much higher), then if that limit is reached throw something other than a security exception so the developer can implement a recycling strategy.
For the latter, it would be very helpful to have a simple "grant recycling policy/framework" available that would make it easy to identify grants that could be the subject of a FIFO or LIFO recycling policy.