Bug: http://b/197965342
services.incremental depends on libbinder.so, which already depends on
libutils.so. When linking services.incremental with libutils.a, the
linker tries to open objects from libutils.a to redefine undefined
symbols in libbinder.so. This causes a linker failure with upstream
LLD. Switching to shared libutils.so instead doesn't increase the
dependency closure for services.incremental.
Test: build with aosp/1809741 which has lld with the above behavior.
Change-Id: I2735461ae64ef2e4c0afc170f7b765c1b5b9432e
Having a final destructor prevents the class from being inherited from,
adding the designation final to the class makes this behavior more
explicit. This is required to re-enable the error for
-Wno-final-dtor-non-final-class.
Test: m
Merged-In: Ia3126d30e19edfd17f7c8da368e9763ca5501e84
Change-Id: Id1d7c607af9cca0109e1f763052894cf179f4af1
10secs should be more than enough to stop whatever the DL is doing.
Besides, DL has its own set of IncFS FDs and should not crash.
Bug: 189222575
Fixes: 189222575
Test: atest IncrementalServiceTest
Change-Id: I73cb27d61c7418adeea7536c8263e6ba8c77fd3e
Exposing more data loader states as per
go/incremental-crash-reports-1-pager.
BUG: 184844615
Test: atest service.incremental_test
Test: atest android.cts.statsdatom.incremental.AppErrorAtomTests
Change-Id: I532513453411b2ccdb21311d0bc3dee0641837db
Since libbinder is used in many places, lightening it up (vtables in
these classes contribute to private dirty memory).
Bug: 183654927
Test: boot
Change-Id: I73328013bfb701257eb88339f7da2cb92db6809e
The test config takes longer than 15mins to run. Move it to a dedicated
group for running slow presubmit Test Mapping test.
Some more context is in the referenced bug, e.g, b/174495337
The group will work exactly the same as presubmit for now.
Bug: 174654670
Bug: 174495337
Test: none
Change-Id: Id12caa8a87b6be142d49e8e871c6edb01ffbab6a
Also remove streaming health status reporting which could cause
startable state change because it is also not needed any more.
BUG: 171920377
Test: builds
Change-Id: I7284e7a63df79da7dbf3d16ff64302b3d1ce1348
Since libbinder is used in many places, lightening it up (vtables in
these classes contribute to private dirty memory).
Bug: 183654927
Test: boot
Change-Id: I73328013bfb701257eb88339f7da2cb92db6809e
Run a manual timed job that trims all files one by one on the
old version of IncFS, where it didn't do it automatically.
Bug: 183435580
Fixes: 183436717
Test: atest libincfs-test service.incremental_test
Change-Id: I57885b2826e383814822c767802f837135fd8464
- use a never-existing storage ID as a job key
- order the jobs in the map to not skip them on changes, or,
worse, never hang in a loop
- clear the local callbacks vector before moving to the next
storage ID
- try to resume from the closest place on the next processing
iteration
Bug: 183435580
Test: atest service.incremental_test
Change-Id: I36cd5d30c656bed62c20bd7a7f84fb58046a0933
Append path strings to the first argument if it's an rvalue
Bug: 183435580
Test: atest libincfs-test service.incremental_test
Change-Id: I52c4a1f0e4ad3547aeccac96a3393323e3be9adb
+ simplify adding new callbacks on storage state
+ streamline lock story for ifs members
Bug: 183101753
Fixes: 183101753
Test: atest PackageManagerShellCommandTest PackageManagerShellCommandIncrementalTest IncrementalServiceTest PackageManagerServiceTest ChecksumsTest
Change-Id: I86fffa7101eeb42ebccca67ae7f5d133c1ab9dfa
Old code had a tiny chance of ignoring a job if it happens to
be scheduled to the exactly the same time as one already in the
queue. Not that it will ever happen, but better to fix it.
+ make the worker thread code slightly easier to reason about
Bug: 183243150
Test: atest IncrementalServiceTest
Change-Id: Ia3126d30e19edfd17f7c8da368e9763ca5501e84
Listeners and some binder call parameters were using several
different styles when passed around - copy, move, pointer,
pointer to pointer. This CL tries to 'normalize' that.
Bug: 183067554
Test: atest IncrementalServiceTest
Change-Id: Ia28089aa9e4491b0f28e3e747489199cfccb5a1b
Replace the remaining calls to getFilledRanges() with
isFullyLoaded() where we don't care about the progress
Bug: 183067554
Test: atest IncrementalService
Change-Id: Ic8dc2e3a0ef078353883feef7969b29e11dfa2d0
Better to protect the memcpy() and zero-out the target
Bug: 183160959
Test: atest IncrementalService
Change-Id: I3daca749168a8c5a32b1eedc7992006cbe2e9eb4
v2 IncFS driver gives a very lightweight function to check the
loading progress on a file, use it instead of counting the
filled ranges
+ remove the unused mockable toString(IncFsFileId)
Bug: 183067554
Test: atest IncrementalServiceTest
Change-Id: Icd3bd891d671b27654f4194787a15a00cba1eb80
libincfs got a new set of functions for checking the file loaded
status, which works more efficiently than getting filled ranges.
Bug: 183067554
Test: atest IncrementalServiceTest
Change-Id: I3b96bf409f1778c5a89e4802e2005197f70ce0cb
Use the new libincfs APIs to preallocate space for all files
created via the public makeFile() API. This way we ensure
the device won't run out of space much later
Bug: 182185202
Test: atest libincfs-test PackageManagerShellCommandTest \
PackageManagerShellCommandIncrementalTest \
IncrementalServiceTest
Change-Id: I70af97949b29ff5db63201b0e3487fe026e23160
