Since emulated FBE is no longer supported, isFileEncryptedNativeOnly()
and isFileEncryptedNativeOrEmulated() are the same as the new method
isFileEncrypted(). Replace all calls to these deprecated methods in
this repository with isFileEncrypted().
Bug: 232458753
Change-Id: I95beea86ef771396c2e08f2d6a643fdc629ad89f
Add getSystemService(Class<T>) to align the capability with framework
part.
This is a back port from aosp/1639943, aosp/1645152 and aosp/1648047
Bug: 179640862
Test: local
Change-Id: I035db55a71f94000ca35f8d71f03c19208423c73
Biometric enrollment will not request a Gatekeeper HAT during
initial credential setup or credential confirmation anymore.
Instead, it is broken down into the following steps now.
Bug: 161765592
1) Request credential setup / confirmation to return a
Gatekeeper Password
2) Biometric enrollment will generate a challenge
3) Biometric enrollment will request LockSettingsService to
verify(GatekeeperPassword, challenge), and upon verification,
the Gatekeeper HAT will be returned.
Since both LockSettingsService and Biometric enroll/settings
make use of biometric challenges, this allows us to make the
challenge ownership/lifecycle clear (vs. previously, where
LockSettingsService has no idea who the challenge belongs to).
Exempt-From-Owner-Approval:For files not owned by our team,
(StorageWizard), this change is just a method rename
Test: RunSettingsRoboTests
Run the following on face/fingerprint devices
Test: Remove credential
adb shell am start -a android.app.action.SET_NEW_PASSWORD
Set up credential + fingerprint
Test: Remove credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ChooseLock* logic in FingerprintSettings
Test: Set up credential,
adb shell am start -a android.settings.FINGERPRINT_SETTINGS
This tests the ConfirmLock* logic in FingerprintSettings
Test: Remove device credential, enroll fingerprint/face. Succeeds.
This tests the ChooseLock* returning SP path from
BiometricEnrollIntro
Test: With credential and fingerprint/face enrolled, go to
fingerprint/face settings and enroll. This tests the
ConfirmLock* path in Fingerprint/FaceSettings
Test: Remove device credential, enroll credential-only, enroll
fingerprint/face separately. Succeeds. This tests the
ConfirmLock* returning SP path in BiometricEnrollIntro
Test: In SUW, set up credential, then biometric. This tests
the ChooseLock* path in SUW
Test: In SUW, set up credential, go back, then set up biometric.
This tests the ConfirmLock* path in SUW
Change-Id: Idf6fcb43f7497323d089eb9c37125294e7a7f5dc
The multitude of slightly different launchConfirmationActivity(*)
methods are a big unsustainable pyramid. It's too difficult to
read, too difficult to track which clients are interested in which
parameters, and too difficult to add new parameters, since we need to
1) Read through all of them and find one that's the closest
2) Try not to affect other callers, so potentially add yet another
3) Modify the internal paths, which all basically call each other
until it reaches the biggest launchConfirmationActivity which
has ALL of the parameters
This change should have no behavioral change.
Note: CredentialStorage doesn't need returnCredentials anymore as of
ag/6073449
Test: make -j56 RunSettingsRoboTests
Test: Manually traced code paths for each invocation. A few hidden
dependencies (such as explicitly setting challenge=0 with
hasChallenge=true) were found. Left them the way they were in
case they were intended
Test: Enroll face, fingerprint
Test: Enable developer options
Test: Change to PIN, Pattern, Password, then back to PIN (so each
type requests confirmation)
Test: adb shell am start -a android.app.action.CONFIRM_DEVICE_CREDENTIAL,
authenticate
Test: adb shell am start -a android.app.action.CONFIRM_FRP_CREDENTIAL
(shows confirm credential screen)
Fixes: 138453993
Change-Id: Ic82ef3c3ac2e14d624281921f2d816bcdacbd82b
"Move content later" button doesn't work on StorageWizardMigrateConfirm
screen which is shown when end-user try to migrate data from adopted
SD Card to internal storage.
The cause is "Move content later" button triggers to StorageWizardReady
screen but cannot launch because the mDisk is null when the destination
of migration is internal storage.
This CL fixes to just exit StorageWizardMigrateConfirm screen when mDisk
is null.
Bug: 117082495
Test: manual
Change-Id: Iccdccf4dda126d77458b9db35e4ec6ae6a263cb7
These metrics help us understand more about how users in the field
are interacting with adoptable storage.
Bug: 37284068
Test: atest com.android.settings.ui.StorageWizardTest
Change-Id: I2bb9b5b3683c6ed080233aa595c2626685384923
Certain volumes (like internal storage) don't have a corresponding
DiskInfo object, so we need to fall back to using the VolumeInfo
description instead.
Bug: 77991425
Test: atest com.android.settings.ui.StorageWizardTest
Change-Id: I92d377035b6028dd31527100da54bfb1d1828ae9
Mostly shuffling around strings and layouts. Slow device warning is
now a full-screen activity, and format warning is now a dialog.
Bug: 76097999
Test: atest com.android.settings.ui.StorageWizardTest
Change-Id: Ifd74e3b1389f0cc9590f6a6a2cd49671f3bbc746
When moving apps or shared storage between storage media on FBE
devices, we need all users to be unlocked to successfully move
the data. This change asks the user to enter the credentials for
any locked users as part of the moving/migration wizard flows.
To do this we relax Utils.enforceSameOwner() to let us prompt for the
credentials of unrelated users, but we carefully only extend this
capability to callers interacting with the "internal" activities,
which require the MANAGE_USERS permission.
Test: builds, boots, users are unlocked before moving
Bug: 29923055, 25861755
Change-Id: Ifaeb2557c4f8c4354e1d380eaa0e413768ee239f
Users can try migrating primary storage while the current location
is missing/unmounted. Fail gracefully instead of runtime restarting.
Bug: 21927076
Change-Id: I54b92487faf9e62d5d309734bf4c436a9259d156
Previously the storage setup wizard shows 'internal' header illust before user
selects storage type. The CL turns the initial illust into 'setup' header
illust.
BUG=22211635
Change-Id: Ie429a6197d210e0bd1ef8d0af6abb6f83295ac50
Storage wizard screens now have updated assets from UX, and various
assets are tinted consistently. We're using our own navigation bar
and wholesale replacing the layout from upstream.
Fix text colors in night mode. Tell SystemUI when we're finished
with the wizard flow.
Bug: 21830731
Change-Id: Ic8d09cc152bfb4dcc6089b5c61d28cbdd4be3ee9
Bring primary storage migration back into the adoption flow, and
provide a path for long-lived notifications to re-launch into the
Settings app. Also provide option to initiate migration if skipped
during wizard. For now, estmiate migration size and time based on
a Class 10 card.
Follow other callback refactoring.
Bug: 19993667
Change-Id: Ia0c28eb114bc6c8066c17b3142ed74f962140c91
Move to using new public accessors on DiskInfo and VolumeInfo.
Persist nickname changes, and remember when user has initialized a
public volume. Also skip the migration part of storage wizard until
it's implemented.
Bug: 19993667
Change-Id: I642fb43afb95380fddd48a1dad438e87b06454da
Also add entry point for SystemUI unmounting, and require permissions
when launching into those flows.
Bug: 19993667
Change-Id: I703d2e5f118848a2e2e96ce1d7f970e5705a288a
Use frameworks/opt/setupwizard/library/ for consistent behavior and
styling on phones and tablets. Implement every step of wizard flow
and connect them together, even though some steps are currently
non-functional. All strings to match UX spec, with some adjustment.
Wizards inherit from helper base class.
New interstitials before unmounting or formatting private storage
to confirm user knows consequences.
Bug: 19993667
Change-Id: I2c774e1718d513805ee8aecfc96d066d4730450c
