More robust createAppData() batching.
The perf team noticed that createAppData() is pretty slow, holding up typical device boot timings because it loops over all installed apps twice (once for DE, once for CE storage), making blocking installd calls for each individual app. There was a createAppDataBatched() method added awhile back, but it was only wired up for multi-user initialization, and it was fragile because any failure in the batch would leave the device in a non-deterministic state. This change rewrites the installd batch call to return a unique result object for each request, allowing us to share both detailed success (returning CE inode values) and detailed error messages, instead of failing the entire batch request. On the framework side, we use CompletableFuture to collect multiple requests for batching, while also allowing "chaining" of follow-up work, which PackageManagerService heavily relies upon. (For example, when a specific package fails, we might want to try destroying and recreating its data directories.) Bug: 163861619 Test: atest FrameworksServicesTests:com.android.server.pm Test: atest android.appsecurity.cts.DirectBootHostTest Change-Id: I79aa28b59067f5b82e448359ff2febb2d1bcdafc
Loading
Please register or sign in to comment