This is a pure refactoring.
Bug: b/153874006
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest
Change-Id: Ieda2be08d7359fa69b2d328c85b3606de6d02b3d
StorageID for an installation changes as we go from a staging
directory to the final one. That's why the only correct way
of waiting for the extraction to complete is by the whole
MountID, even if later it would cause the call to wait on all
instances of the app.
+ measure the waiting timing
Bug: 153513507
Test: adb install megacity.apk
Change-Id: I83558f155867ae5503719ecb63d591fc969c3995
Worker thread has to initialize JNI separately to be able
to call into managed binders implemented in the same
system_server process, e.g. DataLoaderManager
Bug: 153513507
Test: adb install megacity.nov4.apk; adb install megacity.v4.apk
Change-Id: I668e8664361cd2fb3353ec50efd689c7d613658f
IncrementalService can create the library files beforehand, but
delay filling in their data. As it takes quite a while in
general (over a second in cases when the phone is busy), it's
better to run the unzipping and filling in a separate thread
and only make sure it finishes before the whole installation
process is complete.
This speeds up the megacity.apk installation by ~250-300ms,
1000-1100ms -> 750-800ms
Bug: 153513507
Test: adb install megacity.apk
Change-Id: Ia44f7e45b9e0abaebdfb6fe5352f9dcf29ab4ece
Now it's unified with callback FS connector - we are passing the
callback pointer directly to dataloader. This restricts access only
to methods we want and only by someone we want.
Bug: b/153468113
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest
Change-Id: Ib557ebbe7c6c5ce92140eb20534a3626b3ac96d3
Use the "incremental.perflogging" boolean system property
to enable it
+ a bunch of code cleanups
Bug: 152913040
Test: manual
Change-Id: I1cd259ff5821a47ce055003049f77cbf43eba24a
This makes sure DataLoader won't be able to obtain read logs once user
denies access.
Bug: b/152633648
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest
Test: adb shell appops set 1000 GET_USAGE_STATS deny
Change-Id: Ibbb74933b4ef0dd8f5fe27732743e5820b8ee4dc
IncrementalService used to keep the storage parameters in the
directory metadata, but our current incfs doesn't support
metadata on directories - so the storage id is encoded in its
name. But the loading code used to think it's still in the
metadata and couldn't load anything for that reason
Bug: 151241369
Test: install an app and reboot the phone. It's still there
Change-Id: Ic93f8f368b48fc5c5cc9bb726eff80478183596c
To reduce the discrepance between old code which still uses
std::unique_ptr and new code using std::optional.
This might help to avoid merge-conflicts between branches.
Bug: 144773267
Test: m
Merged-In: Ie3196ee5cce17d77950eea9479d2cc1406e9e674
Merged-In: I33822bc76ef87637d5408849f64a0607e121792e
Change-Id: I33822bc76ef87637d5408849f64a0607e121792e
(cherry picked from commit ad62e8cbf5)
Exempt-From-Owner-Approval: cherry-pick from master with owner's approval
Clang's static analyzer is flagging uninitialized struct fields that
we're passing around. In particular, it's not happy that we pass this
partially-initialized struct to a pure-virtual method. I tend to agree
that this may cause issues.
Assuming zero-init gives us reasonable values for all of:
IncFsNewFileParams{}.verification.rootHash
IncFsNewFileParams{}.verification.additionalData
IncFsNewFileParams{}.verification.signature
Bug: None
Test: TreeHugger
Change-Id: I61e556cd8c0e68cdaebd50b0a7be5d5e0a4fd8ff
Basically we configure all the lib files inside Incremental Service,
e.g., create lib dirs, make lib files, extract original
lib file data from zip and then write data to the lib files on incfs.
Test: manual with incremental installation
BUG: b/136132412 b/133435829
Change-Id: I7544d2e78bcf3bdd76ce4c0766ec31ff13fd2011
