Disable CE access checking for canAccessDataDir.

The access is correct, so we don't want StrictMode to kill us.

Fix: 174750397
Test: Presubmits
Change-Id: I14561a4fc1e0195d658dafd7532c8412f51ba386
This commit is contained in:
Alan Stokes
2020-12-16 17:27:28 +00:00
parent 0e75d9e4dd
commit b5fc9412d0

View File

@@ -729,6 +729,23 @@ public final class LoadedApk {
}
}
private StrictMode.VmPolicy allowVmViolations() {
if (mActivityThread == null) {
// When LoadedApk is used without an ActivityThread (usually in a
// zygote context), don't call into StrictMode, as it initializes
// the binder subsystem, which we don't want.
return null;
}
return StrictMode.allowVmViolations();
}
private void setVmPolicy(StrictMode.VmPolicy policy) {
if (mActivityThread != null && policy != null) {
StrictMode.setVmPolicy(policy);
}
}
private void createOrUpdateClassLoaderLocked(List<String> addedPaths) {
if (mPackageName.equals("android")) {
// Note: This branch is taken for system server and we don't need to setup
@@ -984,13 +1001,20 @@ public final class LoadedApk {
// Temporarily disable logging of disk reads on the Looper thread as this is necessary -
// and the loader will access the directory anyway if we don't check it.
StrictMode.ThreadPolicy oldPolicy = allowThreadDiskReads();
StrictMode.ThreadPolicy oldThreadPolicy = allowThreadDiskReads();
// Also disable logging of access to /data/user before CE storage is unlocked. The check
// below will return false (because the directory name we pass will not match the
// encrypted one), but that's correct.
StrictMode.VmPolicy oldVmPolicy = allowVmViolations();
try {
// We are constructing a classloader for a different package. It is likely,
// but not certain, that we can't acccess its app data dir - so check.
return new File(mDataDir).canExecute();
} finally {
setThreadPolicy(oldPolicy);
setThreadPolicy(oldThreadPolicy);
setVmPolicy(oldVmPolicy);
}
}