The existing code asks the main user's userManager if there's a
private profile belonging to it. If a private profile exists then the
answer to that question will always be true. So, we always end up
showing the apps from the private profile for the personal case.
We should instead ask the userManager if it belongs to the private
profile or not.
Bug: 327598131
Test: manual
Change-Id: I7bc9d58c371341235579d3456b54ea85f598892b
Adding this flag check since we are putting all the implementations of Private Space features behind this flag.
Bug: 326060689
Test: Run presubmits and verify that nothing breaks
Change-Id: I2c0e9a1afc3787232425f79d06d4aeba001283ec
Allows a user to disable or enable Thread network / radio from
settings.
In this commit, a toggle is added to Settings > Connected devices >
Connection preferences to control Thread state. See the screenshots
below:
1. Thread is on: https://screenshot.googleplex.com/7FqqbzRX6rGwvSb
2. Thread is off: https://screenshot.googleplex.com/AmfRAhzuukULAAG
3. Thread is disabled by airplane mode: https://screenshot.googleplex.com/7zcesyomrveCqFE
4. Thread is searchable: https://screenshot.googleplex.com/9yFL2jeSuEhJwrS
Requirements:
1. the in-take bug: b/327098435
2. See the screenshot above
3. Test with `atest SettingsUnitTests` and manual tests
4. +2 from Yuwen
5. Flagged by "com.android.net.thread.platform.flags.Flags.thread_enabled_platform"
6. It doesn't need B&R, no preferences are added (the state is in
Android framework (mainline module))
7. Confirmed searchable
8. Code written in Kotlin
Bug: 296990038
Bug: 319077562
Test: atest SettingsUnitTests
Change-Id: Ifa2264b8e59a5112290fd0224cb75ad228732077
This adds a toggle in the Private Space Settings page to control the
lockscreen sensitive notifications for the private profile.
Sensitive notifications for private profile will still be disabled if
sensitive notifications are disabled for the main user.
Demo link:https://drive.google.com/file/d/1--LNXziTRTMvfdsJZAh90SiNiPxWNcI8/view?usp=sharing
Bug: 317067050
Test: atest SettingsUnitTests:HidePrivateSpaceSensitiveNotificationsControllerTest
Change-Id: Ie7f18c1a940e5ffd64112a01c48ac9dee58cb1ab
A new ECM service was introcuded in changeId
I831391e4437b51b3312b5273a2360bd029a3d8ee.
We begin calling it, and update/cleanup method signatures to match.
Note: There are two feature flags:
1. enhancedConfirmationModeApisEnabled - read only, protects the
mainline API.
2. extendEcmToAllSettings - runtime - gates calls to the above APIs.
We use both so we can ramp up in teamfood as needed.
Bug: 297372999
Test: Tested on device
Test: atest SpaPrivilegedLibTests
Test: atest com.android.settings.applications.specialaccess.notificationaccess
Test: atest com.android.settings.datausage
Test: atest PremiumSmsAccessTest
Test: atest RestrictedPreferenceHelperTest
Change-Id: I945ec51df5cd63de548a8ffdd1acc4f09f2301e5
This change enables the remaining settings for ECM, and adds tests for
both this and previous ECM changes.
Bug: 297372999
Test: Tested on device
Test: atest SpaPrivilegedLibTests
Test: atest com.android.settings.applications.specialaccess.notificationaccess
Test: atest com.android.settings.datausage
Test: atest PremiumSmsAccessTest
Test: atest RestrictedPreferenceHelperTest
Change-Id: I73d39d765dba0c1a75111c37b29ccf1c85d2cdd8
There is a case where there is a single primary service (e.g.
a fresh device) and we should hide additional services in that
case.
Test: unit + manual
Bug: 325077523
Change-Id: I9efb785ac3f7a328fdccd138e585f766d46fa282
The limit of 5 providers had two issues, one it did not
reserve one slot for primary which meant that you could
enable 6 and also even though it wouldn't save and would
show an error when you hit that limit the toggle was not
reset which made it look like it was enabled.
Test: on device + unit
Bug: 324426504
Change-Id: Ibec4efd6394835729869194181161fe8ae743e76
This CL is created as a best effort to migrate test targets
to the new android ownership model. If you find incorrect or unnecessary
attribution in this CL, please create a separate CL to fix that.
For more details please refer to the link below,
go/new-android-ownership-model
Bug: 304529413
Test: N/A
Change-Id: I7fbd55a92f4302a6e03bcff0283737fd9295165d
Merged-In: I7fbd55a92f4302a6e03bcff0283737fd9295165d
This CL is created as a best effort to migrate test targets
to the new android ownership model. If you find incorrect or unnecessary
attribution in this CL, please create a separate CL to fix that.
For more details please refer to the link below,
go/new-android-ownership-model
Bug: 304529413
Test: N/A
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:3f65505208d57fa18be353f815c44fdd6f004f4b)
Merged-In: I7fbd55a92f4302a6e03bcff0283737fd9295165d
Change-Id: I7fbd55a92f4302a6e03bcff0283737fd9295165d
This CL is created as a best effort to migrate test targets
to the new android ownership model. If you find incorrect or unnecessary
attribution in this CL, please create a separate CL to fix that.
For more details please refer to the link below,
go/new-android-ownership-model
Bug: 304529413
Test: N/A
Change-Id: I7fbd55a92f4302a6e03bcff0283737fd9295165d
Android camera extensions
(https://source.android.com/docs/core/camera/camerax-vendor-extensions)
will be able to use SW fallback implementations
on devices that do not ship the corresponding
the device specific functionality.
Since the SW fallback will be using a new data
path, it was suggested that users must be able to
control and enable/disable the SW fallback
via the Settings app.
Bug: 297083874
Test: atest packages/apps/Settings/tests/unit/src/com/android/settings/privacy/CameraExtensionsFallbackPreferenceControllerTest.java
Change-Id: I1b97777babe1c9f4ea4f2f6ee3d8251fea11146e
See b/323650746 and b/323649900 for issues that should’ve been caught by pre-submit.
Bug: 323649900
Bug: 323650746
Change-Id: I77d664b6fce6a3f76a4c9a6b39202f6e9d47da33
Test: atest SettingsUnitTests
