StorageStatsManager.getTotalBytes currently takes the size of /data and
rounds up to known probable sizes to guess the size of internal storage.
This is not always correct.
Instead, find the device /data is on and get the size of that device.
This should give a more accurate answer.
Bug: 295358118
Test: vdc volume getStorageSize returns storage size
Change-Id: I907892041b1ce2cd72092a9877ac34c12bf3f254
This reverts commit 78f806198f.
There is no code that reads this system property, logcat already shows
whether the FS keyring is being used, and all devices launching with
Android 11 and later are guaranteed to use the FS keyring anyway.
Bug: 154327249
Change-Id: Id906efedd89d5bcac5370fb141cdbf7848932d95
vold_prepare_subdirs should create apexdata directories for each APEX.
Previously, it gets the list by scanning /apex directory. However,
vold/vold_prepare_subdirs run in the bootstrap mount namespace, they can
see only bootstrap apexes in /apex. The reason why it worked was that
unintended side effects of how we managed /apex directory for both mount
namespace.
Instead, since apexdata directories are already populated by init in
/data/misc/apexdata, we can use that directory for the same purpose.
Bug: 295345486
Test: CtsPackageSettingHostTestCases
Change-Id: I453cd59f54ccbb140f73b5e8576b36fa49f9bc59
In this change, the logic to get the list of apexes is replaced with
the query to apexservice, which is the source of truth. This dedups
the manual scanning of /apex for the apex list, which should be
internal to apexd. (Note how vold_prepare_subdirs filtered out
directories with "@" character).
This also makes vold_prepare_subdirs immune to the upcoming changes:
/apex directory containing only bootstrap APEXes in the bootstrap NS.
Until now, getting the list of apexes by scanning /apex was okay
because of the accidental fact that /apex directory has directories
for all the apexes, not only bootstrap apexes.
Bug: 293949266
Bug: 293546778
Test: CtsPackageSettingHostTestCases
Change-Id: I3fe373ca6f4c2281439bb2449845a1a14357131e
Newer versions of libc++ check that an allocator can be rebound to the
same element type. We need to add a rebind member to ZeroingAllocator
to fix this compiler error:
prebuilts/clang/host/linux-x86/clang-r498229/include/c++/v1/vector:376:19: error: static assertion failed due to requirement 'is_same<android::vold::ZeroingAllocator, std::allocator<char>>::value': [allocator.requirements] states that rebinding an allocator to the same type should result in the original allocator
static_assert(is_same<allocator_type, __rebind_alloc<__alloc_traits, value_type> >::value,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It likely doesn't matter in practice because this allocator is only
used with std::vector, which probably doesn't use allocator rebinding,
because it won't allocate an internal node type (e.g. unlike std::map,
std::list, etc).
Alternatively, ZeroingAllocator could be changed to a
ZeroingAllocator<T> that can zero arbitrary types, but it doesn't seem
necessary currently, and types other than char wouldn't be used.
Bug: b/175635923
Test: treehugger
Change-Id: I42e9d8f02a18637fc67e94cc1358d2ed733a7268
when the idlemaint run is working, if two or more idlemaint abort concurrency are working.
all idlemaint abort will hold the wakelock, until idlemaint run finished,
but it just nofity one idlemaint abort thread to stop and release the wakelock.
Remaining idlemaint abort threads will hold the wakelock until next idlemaint run to notify them.
Bug: 292383791
Test: see the issue Description
Change-Id: I5312be2e0e92c41483cab26e627a4ae562e5aed8
When a volume is ejected from a user but not removed from the device
and mounted again by calling StorageManager#mount, the volume is
mounted for the user from which it was last ejected. This causes the
path of the mounted volume to be inaccessible to the current user.
Whenever StorageManager#mount is called, check if the
VolumeInfo#mountUserId is same as the current userId maintained by
StorageManagerService, if it is not, change the mountUserId for the
Volume to the current userId known to StorageManagerService if it
is not the primary volume and the volume is visible.
This change also fixes a bug where the volumes are unmounted for the
wrong user which causes StorageSessionController go out of sync
which would cause errors during mounting the volumes again as it
maintains sessions per user. The bug also caused volume event
broadcasts to be sent to wrong user handles. To solve the issue
add an extra paramter in IVoldListener#onVolumeStateChanged for userId
which will update the copy which is used for informing
StorageSessionController and also for sending broadcasts.
Test: Perform the following steps:
1. Format SD Card as portable storage in system user.
2. Eject the SD Card from Storage Settings.
3. Switch to a non-system user
4. Mount the SD Card again.
5. Check that the Storage Summary is shown correctly instead
of 0B out of 0B.
Also, checked from the logs the volume state broadcasts are sent to
the correct user handles.
Change-Id: I60b8954cdaee4a54ea6a6299fe5ddda2006faf1c
Properly handle the exit status 1, which shows filesystem errors
corrected, returned by fsck.
Test: manually hot-plugs SD card and check logcat logs
Change-Id: Iacaa8b1d1a7b59931014c1ab6a4708ffc3cd0c06
