* changes:
[automerger skipped] Import translations. DO NOT MERGE skipped: faba866b30 skipped: 38e04d8b0a
[automerger skipped] Import translations. DO NOT MERGE skipped: faba866b30
Import translations. DO NOT MERGE
* changes:
[automerger skipped] Import translations. DO NOT MERGE skipped: cfd1e141b9 skipped: d9cf1de3e4
[automerger skipped] Import translations. DO NOT MERGE skipped: cfd1e141b9
Import translations. DO NOT MERGE
* changes:
[automerger skipped] Import translations. DO NOT MERGE skipped: 65cfd97b69 skipped: 79dc3a3343
[automerger skipped] Import translations. DO NOT MERGE skipped: 65cfd97b69
Import translations. DO NOT MERGE
* changes:
[automerger skipped] Import translations. DO NOT MERGE skipped: c82e0b36ed skipped: 985e4a2c7f
[automerger skipped] Import translations. DO NOT MERGE skipped: c82e0b36ed
Import translations. DO NOT MERGE
* changes:
[automerger skipped] Import translations. DO NOT MERGE skipped: eadf247a57 skipped: 84b233fab0
[automerger skipped] Import translations. DO NOT MERGE skipped: eadf247a57
Import translations. DO NOT MERGE
By requiring an explicit default setting, it eliminates all ambiguous
states where a disambiguation would normally be shown. With this
change in place, at no point should a disambiguation be shown.
Test: manual
Bug: 111603898
Change-Id: Ib32dafbd3c6fcbe11186dc8ecab6b09c9b734067
Merged-In: Id39fdf700ed4ef08ebbc333b5452223430ac2e48
The path-permission element offers prefix or regex style matching of
paths, but most providers internally use UriMatcher to decide what
to do with an incoming Uri.
This causes trouble because UriMatcher uses Uri.getPathSegments(),
which quietly ignores "empty" paths. Consider this example:
<path-permission android:pathPrefix="/private" ... />
uriMatcher.addURI("com.example", "/private", CODE_PRIVATE);
content://com.example//private
The Uri above will pass the security check, since it's not
technically a prefix match. But the UriMatcher will then match it
as CODE_PRIVATE, since it ignores the "//" zero-length path.
Since we can't safely change the behavior of either path-permission
or UriMatcher, we're left with recovering these shady paths by
trimming away zero-length paths.
Bug: 112555574
Test: cts-tradefed run cts -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AppSecurityTests
Change-Id: Ibadbfa4fc904ec54780c8102958735b03293fb9a
The path-permission element offers prefix or regex style matching of
paths, but most providers internally use UriMatcher to decide what
to do with an incoming Uri.
This causes trouble because UriMatcher uses Uri.getPathSegments(),
which quietly ignores "empty" paths. Consider this example:
<path-permission android:pathPrefix="/private" ... />
uriMatcher.addURI("com.example", "/private", CODE_PRIVATE);
content://com.example//private
The Uri above will pass the security check, since it's not
technically a prefix match. But the UriMatcher will then match it
as CODE_PRIVATE, since it ignores the "//" zero-length path.
Since we can't safely change the behavior of either path-permission
or UriMatcher, we're left with recovering these shady paths by
trimming away zero-length paths.
Bug: 112555574
Test: cts-tradefed run cts -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AppSecurityTests
Change-Id: Ibadbfa4fc904ec54780c8102958735b03293fb9a
