Revert submission 12989357-fix_ac_menu
Reason for revert: Bug: 176473169
Reverted Changes:
I6fc50a5ae:Add adaptive charging to the top level settings me...
I8f600287c:Add adaptive charging to the top level settings me...
Change-Id: I2928a96112bb8d2beeb071f231af6595edead4fa
Rather than mocking the PreferenceScreen's getPreference function,
a PreferenceManager has been created, which instantiates the Screen.
The desired Preference is added to the Screen with the testing key.
Rather than using a shadow XML, contexts' resources are mocked.
A mock WifiManager is used instead of a shadow
Duplicate test case removed, and test which succeeds locally but
not on cuttlefish marked as ignored for now.
Bug: 175389659
Test: atest -c DeviceNamePreferenceControllerTest
Change-Id: I643b22993a1d102614fed1883af7f4925947be20
There are couple of newly explored concepts in this CL, which will
hopefully be useful for migrating other tests in the future as well. In
broad strokes, the changes to this file cover:
Android build file species the preferences library, in order to access
PreferenceViewHolder.createInstanceForTests.
Resource ids in JUnit tests differ from the Settings apk. This is true
not only of strings but also views and layouts. Helper functions added
to main class to access the layouts needed by the test.
Shadow activities are not needed to view layouts, the context can be
used.
Context startActivity can be mocked and verified in order to capture and
examine the intent created by the library under test.
Bug: 175389659
Test: atest -c DataUsageSummaryPreferenceTest
Change-Id: Ib8cb87f0299c47a32c3f5d3af7edb20592b727ec
The superclass ContentProvider's "getContext" method is final and
cannot be mocked, so a helper method visible for testing was added
to allow for context injection.
Bug: 175389659
Test: atest -c ModuleLicenseProviderTest
Change-Id: I9e20171340ae0a48d74fae44c7b356ea67dba43b
Connection through new CDS APIs to come once that CL is merged.
Bug: 168065315
Test: atest SettingsUnitTests:com.android.settings.accessibility.ReduceBrightColorsIntensityPreferenceControllerTest
Change-Id: I9cc6a20ea5ea8a11c5fb3ef8a36e372d9c12b4bc
Set default "ON" when we can not get
SWIPE_BOTTOM_TO_NOTIFICATION_ENABLED value.
Bug: 175084985
Test: manual check Settings > System > Gesture > Swipe for notifications
Test: manual check it is disabled after One-handed mode toggled on
Test: make RunSettingsRoboTests ROBOTEST_FILTER=\
"SwipeBottomToNotificationSettingsTest"
Test: make RunSettingsRoboTests ROBOTEST_FILTER=\
"SwipeBottomToNotificationPreferenceControllerTest"
Change-Id: I176ba1c0e18c5ed7d1582d380db6ec190b6e1dec
Haptic once the swiping on the notification item is going to snap in either directions. The snap-in scenario is about the notification item when there is a "snap back point" i.e. if swiping the item back till a certain point it just snaps back to initial state but once it goes past a certain location it snaps into the new location.
- screenshot, https://screenshot.googleplex.com/6A8Gxs7yRwqAVk2
Bug: 175364588
Test: manual
Change-Id: I7e2ed19bfb7f863502e10233e3e23ee5d434b3b4
Before this CL, there is a possible phishing attack allowing a malicious
BT device to acquire permissions based on insufficient information
presented to the user in the consent dialog. This could lead to local
escalation of privilege with no additional execution privileges needed.
User interaction is needed for exploitation.
This CL add more prompts presented for users to avoid phishing attacks.
Bug: 167403112
Test: send intent to test right prompts message is pop up. make -j42 RunSettingsRoboTests
Change-Id: Idc6ef558b692115bb82ea58cf223f5919b618633
canSubscriptionBeDisplayed is more readable.
Reasonale:
When cherry-picking ag/12886476 into Android R branch (ag/13209427), a comment from code reviewer suggested this change.
Since ag/12886476 has been merged for a while, another patch for it is perferred option when comparing with reverting that CL and resubmit it.
Bug: 175830728
Change-Id: Ie91eb82504fd7cff6671803a2bc2560139690952
Test: build pass
Merged-In: Ie91eb82504fd7cff6671803a2bc2560139690952
canSubscriptionBeDisplayed is more readable.
Reasonale:
When cherry-picking ag/12886476 into Android R branch (ag/13209427), a comment from code reviewer suggested this change.
Since ag/12886476 has been merged for a while, another patch for it is perferred option when comparing with reverting that CL and resubmit it.
Bug: 175830728
Change-Id: Ie91eb82504fd7cff6671803a2bc2560139690952
Test: build pass
Some carrier(s) expand their service through providing eSIM in companion
with pSIM. Group UUID is designed to group them together as a single
SIM.
Bug: 169455114
Bug: 175069803
Test: make RunSettingsRoboTests ROBOTEST_FILTER=SubscriptionsPreferenceControllerTest
Change-Id: I0934a45a2917ab106627c733162efbee9a13f216
(cherry picked from commit a6b249d625)
Merged-In: I0934a45a2917ab106627c733162efbee9a13f216
Fixes: 169629017
Test: Wipe device, go through setup flow with a managed account.
Successfully set up credential and fingerprint
During the conversion to GkPwHandle (instead of HAT), the code in
Choose/ConfirmLock* and most of the biometric paths were updated, with
the exception of 2a below.
1) Only multi-biometric devices request Choose/ConfirmLock in
BiometricEnrollActivity.
2) Single-biometric devices (in almost all paths) request credentials
in their intro activities (FingerprintEnrollIntro, etc).
2a) However, there is a special path used by work profiles where
credentials are first set up, and the GkPwHandle is passed into
BiometricEnrollActivity, with the request to skip the fingerprint
enroll introduction page. In this case, we must remember to
forward the GkPwHandle to the relavent enrollment page
(FingerprintEnrollFindSensor).
At some point in the future we should have all credential stuff
done in BiometricEnrollActivity. However, due to legacy APIs, etc,
it may be more work than it's worth right now.
Change-Id: I3f95876de6969fee7130d7a19c8db363da69c4c2
