Skip to content
Commit f311e0b2 authored by Jeff Sharkey's avatar Jeff Sharkey
Browse files

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
parent 9bd766de
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment