summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
47 hoursMerge "Support multiple partition for /data" into mainHEADmastermainTreehugger Robot
3 daysSupport multiple partition for /dataJaegeuk Kim
Bug: 336319772 Change-Id: I92eca566063b7d8ad74a15c7b74d809b452ace72 Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
9 daysMerge "Get the correct fstab entry if there are more than one" into mainKelvin Zhang
10 daysGet the correct fstab entry if there are more than oneKelvin Zhang
vold currently uses the first fstab entry for moun point /data . However, if there are multiple fstab entries for /data and the first one isn't the entry actually being used, checkpoint may fail. Test: boot a device with ext4 entry placed after f2fs Bug: 293313353 Change-Id: Id374c622c53fd61047d62743555234d36bd038ec
12 daysMerge "Migrate Test Targets to New Android Ownership Model" into mainTreehugger Robot
2024-04-18Merge "Replace string secret with a byte[] for CE storage in vold binder" ↵Ellen Arteca
into main
2024-04-17Replace string secret with a byte[] for CE storage in vold binderEllen Arteca
Replace the current `string secret` argument to the lock/unlock of CE storage with a `byte[]`. This is part of an effort to remove instances of the LSKF and LSKF-derived secrets that are available in a RAMdump -- since the strings are passed from Java, they cannot be cleared, but `byte[]` can be. This CL is the described argument change, and the propagation of this change to the various functions that are called by the vold binder functions. Bug: 320392352 Test: Manual upgrade test: 1. Flash the device with a build not including these changes 2. Rebuild with these changes 3. Flash the device (but do not wipe) with the build including these changes 4. See if the device boots and works normally -- if the CE storage cannot be unlocked it will not start up and be usable when the user logs in. Change-Id: Icd4c925f2fd79e7533fdf9027e16f6736dbe1ab3
2024-04-17Merge "Fix some special usb can't mount issue." into mainTreehugger Robot
2024-04-17Fix some special usb can't mount issue.Xiuqin Wang
[Description] The usb has invalid partition table, but vold thinks it has partition. So vold not to treat entire disk as partition. Bug: 160433451 [Test Report] Build pass. The special usb can mount ok. Change-Id: I0b0e761641f6961e69d7d7f7fbc58d33eeab3a08
2024-04-02Merge "Revert^2 "Add @SensitiveData tag to IVold"" into mainEllen Arteca
2024-03-29Revert^2 "Add @SensitiveData tag to IVold"Ellen Arteca
This reverts commit 697c6a52173abcb6106180c36b0b0574db21cb2c. It is reapplying the change in I0439f63fd4739bf5a6c957695cc9c3003ec89eb0. Reason for revert: Undoing the revert (putting the change back in); after looking at the performance bug, it seems impossible it was caused by the addition of the `@SensitiveData` tag on IVold. Performance bug: 331045735 Bug: 320392352 Test: launch_cvd -daemon Change-Id: I522f63836155ea404260e89fd2f209738f37d5b3
2024-03-27Merge "Revert "Add @SensitiveData tag to IVold"" into mainEllen Arteca
2024-03-27Revert "Add @SensitiveData tag to IVold"Ellen Arteca
This reverts commit da1d160074b90eb349d058321bad5175a2f90824. Reason for revert: reverting while figuring out what is causing performance bug 331045735 Change-Id: Ib306e679e65c3a585304ad4c33304c549cbb240e
2024-03-22Merge "Add @SensitiveData tag to IVold" into mainEllen Arteca
2024-03-21Add @SensitiveData tag to IVoldEllen Arteca
Mitigate data leak across the Binder boundary to Vold, of secrets derived from the LSKF. Specifically: the `String secret` argument to both `setCeStorageProtection` and `unlockCeStorage` is a secret derived from the user's synthetic password. This CL is part of an effort to wipe instances of the LSKF and secrets derived from it, so they are not available in a RAMdump. Bug: 320392352 Test: launch_cvd -daemon Change-Id: I0439f63fd4739bf5a6c957695cc9c3003ec89eb0
2024-03-21Merge "Revert "Reduce AppFuse max read size."" into mainTreehugger Robot
2024-03-08Revert "Reduce AppFuse max read size."Martijn Coenen
This reverts commit fb014fc6e81b086c63398267d996d6972b7f35ce. Reason for revert: b/325994066 Change-Id: Ia8bb76ac69713df8bd9df5501b3dde9a86a5fd99
2024-03-07Merge "Merge Android 14 QPR2 to AOSP main" into mainXin Li
2024-03-06Merge Android 14 QPR2 to AOSP mainXin Li
Bug: 319669529 Merged-In: Ib360884801c37c093d9836109f0b817987abd850 Change-Id: I29925f20f929ec0522ce12e58e8a05f44490ba88
2024-03-05Merge "vold: Unmount StubVolume disks before unmounting EmulatedVolumes" ↵temp_319669529Momoko Hattori
into main am: 2f20c808c2 Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2850049 Change-Id: Ib360884801c37c093d9836109f0b817987abd850 Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2024-03-05Merge "vold: Unmount StubVolume disks before unmounting EmulatedVolumes" ↵Momoko Hattori
into main
2024-02-28Merge "Delete unused code conditional on MANAGE_MISC_DIRS" into main am: ↵Eric Biggers
cc2f93829c Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2978556 Change-Id: If24e84ecff3eff052814ec5f275d464ab9ebf0e9 Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2024-02-27Merge "Delete unused code conditional on MANAGE_MISC_DIRS" into mainEric Biggers
2024-02-27Delete unused code conditional on MANAGE_MISC_DIRSEric Biggers
Since MANAGE_MISC_DIRS is hardcoded to 0, and it always has been, there is no need to have it in the code. Test: build Change-Id: I30a73e67999841271e07dbc3eeb1b8568529a7c3
2024-02-22vold: Unmount StubVolume disks before unmounting EmulatedVolumesMomoko Hattori
The current shutdown / reset logic in VolumeManager unmounts EmulatedVolume first, and unmounts the other disks. In ARC (Android on ChromeOS), ChromeOS Downloads directory (exposed from ChromeOS to Android as a disk having StubVolume) is bind-mounted to /data/media/0/Download in the ARC-customized version of StubVolume::doMount() (http://shortn/_lKaAhTLhY3), and the current unmount order causes EmulatedVolume not to be cleanly unmounted. This patch hence changes the order of the unmount of volumes to first unmount StubVolume disks, then unmount the EmulatedVolumes, then unmount the non-StubVolume disks. Bug: 304369444 Test: On an Android phone, create a virtual public volume with the following commands on adb shell (taken from android.scopedstorage.cts.lib.TestUtils.createNewPublicVolume()): $ sm set-force-adoptable on $ sm set-virtual-disk true $ sm list-disks # <- This returns the virtual disk name $ sm partition <virtual disk name> public Then, run `vdc volume reset` on lynx adb shell, observe logcat from vold and check that no error is observed. Test: Run `vdc volume reset` on ARC adb shell, and confirm that: * Without this patch, the primary emulated volume fails to unmount with "Device or resource busy", followed by MyFiles volume unmount. * With this patch, MyFiles volume is unmounted before the primary emulated volume, and no error is observed. Change-Id: I54f60e3320574ccf8d3589545ff77967fff14fc7
2024-02-19Merge "Reduce AppFuse max read size." into main am: 527a52874eTreehugger Robot
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2859125 Change-Id: Ib3c5e4302d38e527d3c15e94b25991994ea9bdfc Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2024-02-19Merge "Reduce AppFuse max read size." into mainTreehugger Robot
2024-02-02Migrate Test Targets to New Android Ownership ModelAditya Choudhary
This CL is created as a best effort to migrate test targets to the new Android ownership model. It is based on historical data from repository history and insights from git blame. Given the nature of this effort, there may be instances of incorrect attribution. If you find incorrect or unnecessary attribution in this CL, please create a new CL to fix that. For detailed guidelines and further information on the migration please refer to the link below, go/new-android-ownership-model Bug: 304529413 Test: N/A Change-Id: Ifbead75f744dc00b84aa71b5847ec6a5e0289251
2024-02-01Merge "Add API to get remaining lifetime as a percentage." into main am: ↵David Anderson
f75d8fc237 Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2940229 Change-Id: Ifbecbd4442b970b87605b6c223e89efd11f5bcba Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2024-02-01Merge "Add API to get remaining lifetime as a percentage." into mainDavid Anderson
2024-01-31Add API to get remaining lifetime as a percentage.David Anderson
This differs slightly from the previous API, which exists for idle maintenance, whereas this value is intended to be displayed to users. First, it returns remaining lifetime, rather than used lifetime. Second, it rounds up the returned value for usabilty purposes. This isn't an issue on Pixel (which reports at 1% granularity), but devices which report at 10% granularity should show 100% out-of-box, which is not possible to distinguish in the old API. Bug: 309886423 Test: StorageManager.getRemainingStorageLifetime Change-Id: Ic5f6ec9969667302ba8bad95b2765e2cc740bed4
2024-01-23Merge Android 24Q1 Release (ab/11220357)Xin Li
Bug: 319669529 Merged-In: I8efef8efbc9f01e1177fbe3105513166ad90d22f Change-Id: If7ebdccc494c7edb5b1603eb3154ca508e14dc33
2024-01-19Merge "Add time_offset=<UTC offset> to mount arguments" into main am: 5b711b10dbNeil Fuller
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2901301 Change-Id: I96fac82b8cbad9f471b0dbcb26ac6fbc54a51273 Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2024-01-19Merge "Add time_offset=<UTC offset> to mount arguments" into mainNeil Fuller
2024-01-19Add time_offset=<UTC offset> to mount argumentsNeil Fuller
Add time_offset=<UTC offset> to mount arguments for the vfat driver. This is not being release flagged as it's a fix for a regression but is a cosmetic fix that shouldn't affect anything besides reported file timestamps. Changes for issue 246256335 in Android U stopped Android syncing the current time zone UTC offset to the kernel because doing so is discouraged. It is discouraged because the current offset alone is not very useful - it tells the kernel nothing of DST or historic UTC offsets. Converting to and from local times are are best left to userspace where time zone rules information is available, and different users can use different time zones. However, because FAT32 is poorly designed WRT timestamps, the kernel FAT32 driver, vfat, does use the kernel offset when available and when it isn't given a fixed offset to use at volume mount time. This means that Android devices after the change from issue 246256335 displayed more obviously incorrect times. This change adds the argument necessary to vold when mounting a FAT32 volume to set a fixed UTC offset to adjust FAT32 local times to a UTC-like time ("UTC time" from now on). Userspace then uses the UTC offset for that UTC time, calculated using TZDB rules, to convert back to a local time. This is still prone to generating some incorrect times, e.g. due to DST or other historic offset changes, or a user time zone change on device after mounting the volume. FAT32 lacks the information about "what was the UTC offset at file time X?" (unlike exFAT) AND the vfat driver has no way to look up the time zone rules itself. This change is a reasonable "better than nothing" change to address times being obviously wrong after the change from issue 246256335, especially when a user copies a file from a desktop computer to USB / sd card storage and immediately plugs the device into an Android device. It does this without reverting to kernel UTC offset syncing, which is flawed (i.e. it would never work completely), discouraged, and more effort/code to improve, e.g. because userspace would have to schedule alarms for offset changes. Testing: 1) Obtain a USB FAT32 formatted USB storage device that can be plugged into a pixel device, e.g. with an OTG USB adapter. 2) On a desktop computer, mount the device and write some files / note times associated with existing files. These times will already be adjusted by this OS to be "local time" based on its own logic, but if it's working correctly that time will be exactly the local time value stored in the FAT32 volume itself. 3) On a rooted Android device where you can use adb via Wifi (adb tcpip / adb connect), leaving the USB port free for external USB devices.... a) $ adb root b) Insert the USB storage c) $ mount | grep 'fat' d) For the USB storage drive, observe the time_offset argument (or tz=UTC when time_offset == 0) reported (this would not be reported without this patch) e) ls -l /mnt/<mount location from (3c)> f) Confirm the local time displayed is as expected. e.g. the time should be the same as shown in (2), regardless of the device's time zone. 4) To observe the "fixed offset behavior" at mount time, alter the time zone setting on the device via Settings -> System -> Date & Time a) Repeat 3c-3e. b) The times shown will have changed by the difference between the original and new time zone chosen. c) Extract / re-insert the USB storage device. d) Repeat 3c-3e e) The times shown should match the times from (2) again 5) Confirm the write behavior: a) $ touch /mnt/<mount location from (3c)>/foobar b) $ ls -l /mnt/<mount location from (3c)> c) The time should match the device's displayed local time (status bar) d) Unmount the USB device and insert the USB device into a desktop computer e) Confirm the timestamp matches the Android device's local time when (5a) took place, e.g. using "ls -lT" on MacOS. Testing was done with numerous zones with positive, negative and zero offsets. Interesting zones like India (UTC+5:30), Kiribati (UTC+14), Wake Island (UTC-11), the various fixed offset zones like Etc/GMT+12, Etc/GMT-14 were tried. Note: Depending on the time zones being used on devices (Android and desktop) and when the files were written / testing took place during the year, you may see file times shifting by 1 hour from the "ls -l" step depending on whether they were written in summer or winter time. This is because the userspace code for rendering times knows about DST but the kernel driver is applying a fixed offset and does not. This is expected and illustrates the points at the top of this comment about FAT32 integration never being perfect. See https://www.google.com/search?q=fat32+dst for other examples. Bug: 319417938 Bug: 315058275 Bug: 246256335 Test: See above Change-Id: Ic7ce159d88db5d5cf5894bcc26ea60bd7c44917d
2024-01-11Merge "Don't use std::allocator::pointer" into main am: 55af483b78Treehugger Robot
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2901505 Change-Id: I110e19f98b191da52c353e979dfa4e00da270d7f Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2024-01-11Merge "Don't use std::allocator::pointer" into mainTreehugger Robot
2024-01-10Don't use std::allocator::pointerTomasz Wasilczyk
It's removed in C++20 Bug: 175635923 Test: m MODULES-IN-system-vold Change-Id: Ief2875bfd3e2d2e5023ad4c0bb754a616fd42419
2024-01-05Merge "Remove userSerial param from vold methods that don't use it" into ↵Eric Biggers
main am: 7730a4944f Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2871777 Change-Id: I7ed86185213bec08b4e626df05b356c4fc1358f8 Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2024-01-05Merge "Remove userSerial param from vold methods that don't use it" into mainEric Biggers
2024-01-04Remove userSerial param from vold methods that don't use itEric Biggers
createUserStorageKeys(), unlockCeStorage(), and prepareUserStorage() have a user serial number parameter, but they don't actually do anything with it except log it. Remove this unnecessary parameter. Bug: 316035110 Test: presubmit Flag: N/A, mechanical refactoring Change-Id: I73ebae1afb2bdb7ca856b40b34ce806fdda718fe
2024-01-04Merge "vold: remove session keyring workaround for old kernels" into main ↵Eric Biggers
am: 69c4d769ed Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2834717 Change-Id: I7efb8ff4d350d02611956e6c118e164dfc50e9ca Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2024-01-04Merge "vold: remove session keyring workaround for old kernels" into mainEric Biggers
2023-12-05vold: remove session keyring workaround for old kernelsEric Biggers
The android-4.14-stable and later kernels support the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY ioctls. This has superseded the old way of adding fscrypt keys to the kernel, which was to use the add_key() syscall to add keys to the "session" keyring. On kernels that support the ioctls, Android doesn't use the obsolete way. Since upgrading even just to Android 14 requires at minimum a android-4.14-stable kernel (according to https://source.android.com/docs/core/architecture/kernel/android-common#compatibility-matrix), there is no need to support the obsolete way anymore. Therefore, this commit removes the code that added and removed keys to/from the session keyring. Now the ioctls are used unconditionally. Flag: N/A for the following reasons: - Removing obsolete code, which is fairly safe - Very early code, so runtime flag cannot be used - This topic also removes code from init, which cannot use aconfig libraries because they do not support recovery_available Bug: 311736104 Test: Build and boot Cuttlefish Change-Id: I0d9abbda77b1ac838ea6f014dbe22ab032c0e5ae
2023-12-05Reduce AppFuse max read size.Hyeeun Jun
Since the max read size of FUSE is 128KB in default, the socket header of the appfuse epollcontroller is allocated in order 4 (64KB). When memory environment is in insufficient situation that has a lot of fragment, order 4 size memory allication is impossible, so more than several tens of seconds could take to allocate the socket header. To prevent the issue, limit the fuse read size to 64KB, so that the memory allocation order of the socket header is changed to order 2. Bug: 312503249 Test: atest AppFusePerfTest Change-Id: I7020801b7539d980515885396916f8be1f1008e9
2023-12-01Merge "Add support for 16k F2FS" into main am: 1dd20644dc am: 057ea22258 am: ↵Daniel Rosenberg
caceb0aae1 Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2836451 Change-Id: Ibb1fa146dc5c9fef81fb25bceedc7b116836ab6e Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2023-12-01Merge "Add support for 16k F2FS" into main am: 1dd20644dc am: a6fcafe382 am: ↵Daniel Rosenberg
2213944986 Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2836451 Change-Id: I2c63d6101ea7f55914ff6c5893e833b3b536d72a Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2023-12-01Merge "Add support for 16k F2FS" into main am: 1dd20644dc am: 057ea22258Daniel Rosenberg
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2836451 Change-Id: I2d0326a46081b3347ba549f8c48ab9c39c177008 Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2023-12-01Merge "Add support for 16k F2FS" into main am: 1dd20644dc am: a6fcafe382Daniel Rosenberg
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2836451 Change-Id: I860125d475e75f2bccc7fcb82fde10bc4627ac0f Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
2023-12-01Merge "Add support for 16k F2FS" into main am: 1dd20644dcDaniel Rosenberg
Original change: https://android-review.googlesource.com/c/platform/system/vold/+/2836451 Change-Id: I8ffea2f471bfb36ceaffc3cb6fb143f7474d7d32 Signed-off-by: Automerger Merge Worker <android-build-automerger-merge-worker@system.gserviceaccount.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 18:59:09 +0000