Hide SIM notification UI based on configuraion.
Bug: 240515161
Test: test cases and local testing
Merged-In: I07d9ddeb96ca590decf28126ce97fba4c1783304
Merged-In: I7a912a3393694155d29614d325796e08598985bf
Merged-In: I0a7e0e9826a301f2aa0ca34f40b5570f0e384b4f
Change-Id: I1b88f0f70f1b7487163849abfce93dbbc35c9ff9
In the P2P page, p2p stops searching when airplane mode is turned on, and should start searching when airplane mode is turned off.
Bug: 255249207
Test: make RunSettingsRoboTests ROBOTEST_FILTER=WifiP2pSettingsTest
Signed-off-by: Yu <zhangyu34@xiaomi.com>
Change-Id: I71d5eb6c3d8533417e8ae9ac09e7fac73983644e
Hide SIM lock UI based on configuraion.
Bug: 240515161
Test: test cases and local testing
Merged-In: I870c0b53112db56b7bc80bfd585f6f7b3cf82737
Change-Id: I70be07dbc1decb5cb8eff384d4cb8bea355ab99d
Hide SIM remove UI based on configuraion.
Bug: 240515161
Test: test cases and local testing
Merged-In: Iea40b89733cc75a41f960fecb2ac24177a4cbd3d
Change-Id: I8f0c1d53c4fe6e30280f2b7ae8f694cd27056e36
Hide SIM provider UI based on configuraion.
Bug: 240515161
Test: test cases and local testing
Merged-In: I1cb83787dc1ac1d61bb6bed6aa9c5e7a3ad6e69b
Change-Id: Ibe22c3ba377a15f770622d235ebddc63b4bf3ed6
This CL contains two fixes:
- Fix potentialcrash when calling getAvailabilityStatus, we should use
the latest packageName to decide.
- Add test class
Bug: 258270151
Test: atest
Change-Id: I3e6aa7e0773a73d2e3dfa996e42087f3ec80627b
IDumpstateDevice HAL switched to AIDL service in P22 devices.
This change will firstly apply to AIDL service if available and
fall back to HIDL service if not, making the feature work for
both HIDL an AIDL based devices.
Bug: 242634531
Test: make && make RunSettingsRoboTests
Change-Id: I4a2ec44092804574a60113e5be3df19b586bfa64
Merged-In: I4a2ec44092804574a60113e5be3df19b586bfa64
(cherry picked from commit 17a9fb6bec)
This commit is part of a large scale change to fix errorprone
errors that have been downgraded to warnings in the android
source tree, so that they can be promoted to errors again.
The full list of changes include the following, but not all
will be present in any one individual commit:
BadAnnotationImplementation
BadShiftAmount
BanJNDI
BoxedPrimitiveEquality
ComparableType
ComplexBooleanConstant
CollectionToArraySafeParameter
ConditionalExpressionNumericPromotion
DangerousLiteralNull
DoubleBraceInitialization
DurationFrom
DurationTemporalUnit
EmptyTopLevelDeclaration
EqualsNull
EqualsReference
FormatString
FromTemporalAccessor
GetClassOnAnnotation
GetClassOnClass
HashtableContains
IdentityBinaryExpression
IdentityHashMapBoxing
InstantTemporalUnit
InvalidTimeZoneID
InvalidZoneId
IsInstanceIncompatibleType
JUnitParameterMethodNotFound
LockOnBoxedPrimitive
MathRoundIntLong
MislabeledAndroidString
MisusedDayOfYear
MissingSuperCall
MisusedWeekYear
ModifyingCollectionWithItself
NoCanIgnoreReturnValueOnClasses
NonRuntimeAnnotation
NullableOnContainingClass
NullTernary
OverridesJavaxInjectableMethod
ParcelableCreator
PeriodFrom
PreconditionsInvalidPlaceholder
ProtoBuilderReturnValueIgnored
ProtoFieldNullComparison
RandomModInteger
RectIntersectReturnValueIgnored
ReturnValueIgnored
SelfAssignment
SelfComparison
SelfEquals
SizeGreaterThanOrEqualsZero
StringBuilderInitWithChar
TreeToString
TryFailThrowable
UnnecessaryCheckNotNull
UnusedCollectionModifiedInPlace
XorPower
See https://errorprone.info/bugpatterns for more
information on the checks.
Bug: 253827323
Test: m RUN_ERROR_PRONE=true javac-check
Change-Id: I29f691a22617b1fc834680ff1cf4ab4244203f06
Search highlight function includes two steps: Scroll list to target position first, then notifyItemChanged to it.
We use a Handler.postDelay to implement this. However, when scheduled runnable starts, the original target position could have changed due to preference list update, calling recyclerview's methods after that will be easy to cause an exception.
This CL ensures highlight position every time before calling recyclerView update, which also contribute to origin fix of RecyclerView IllegalArgumentException to a certain extent.
Test: atest, also test some search results, and see the correct behavior
Fixes: 246411107
Change-Id: Ifa758ce3718b047138079246cdfce99fdf66d5b2
In order to reduce the complexity, LE audio offload couldn't be
enabled as a2dp offload disabled. Remove the combination from the
developer option
1. As a2dp offload disabled, LE audio offload couldn't be switched.
2. As the user disable a2dp offload, LE audio offload would be disabled
as well
Bug: 238268927
Test: make RunSettingsRoboTests ROBOTEST_FILTER=BluetoothLeAudioHwOffloadPreferenceControllerTest
Test: make RunSettingsRoboTests ROBOTEST_FILTER=BluetoothA2dpHwOffloadPreferenceControllerTest
Change-Id: I9ebe26c6a8058798ea654523ad1405a8447268b8
mChannel is nullable and we have to do a null-check before calling its method.
Bug: 245506600
Test: manual and atest
Change-Id: Ib739f0f66f1a2aee1b2741263e7c206341782892
Prior to this cl, we use #getPackagesForUid()
to get a list of calling package names and
pick up 1st package name in the list as target
calling package. And then go to check the
Wi-Fi permission.
This implementation is ok for most apps without
sharing system uid. However, this may not work
if the package is set with sharing system ui.
In this case, we get a list of packages
and we don't know which one is caller. So, if we
decide to choose the 1st package as our
calling package, then it could fail to pass
permission check since that package could be not
a correct calling package.
In this cl, we skip permission check for those
packages running with system uid. So, it can resolve
Wi-Fi Panel problem since Wi-Fi panel runs
on settings process(with system uid).
Test: 1. adb shell am start -a android.settings.panel.action.WIFI
2. Verify on assistant app and system ui launcher and search app.
Bug: 240531998
Change-Id: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
Merged-In: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
(cherry picked from commit 5e785a2d99)
Merged-In: Ia825853dde2e966e3d390cecfbe1a99f6439d31e
The BluetoothDeviceUdater added the checking whether the item is in the
list. It caused this testcase failed.
Add more mocks for this testcase.
Bug: 237223797
Test: make RunSettingsRoboTests ROBOTEST_FILTER=BluetoothDevicesSliceTest
Change-Id: Idb746e42480f99846efb5d1e4d4a411a5a9ca296
Merged-In: Idb746e42480f99846efb5d1e4d4a411a5a9ca296
At the media device, it only shows the active LE device which is
connected.
Bug: 232892046
Test: make RunSettingsRoboTests ROBOTEST_FILTER=AvailableMediaBluetoothDeviceUpdaterTest
make RunSettingsRoboTests ROBOTEST_FILTER=ConnectedBluetoothDeviceUpdaterTest
make RunSettingsRoboTests ROBOTEST_FILTER=SavedBluetoothDeviceUpdaterTest
Change-Id: Iac661206def4d43bc40ab9bb1938f084926899c2
Merged-In: Iac661206def4d43bc40ab9bb1938f084926899c2
* changes:
Grey out LE audio offload switcher as LE audio isn't enabled/supported
Unify the LE audio string and refine the layout to put LE audio switch together
Add LE Audio feature switcher in the developer option menu
Currently, when schedule sets to "Turns on at bedtime", the footer will
show a slid up animation when entering the page, this is because the
"Start time" & "End time" preferences are hidden in onResume().
This is because these 2 preferences always return AVAILABLE in
getAvailabilityStatus(), and manually update visibility in
refreshSummary(), which is called each time updateState() is called.
Usually the controller not set the visibility explicitly, but return
CONDITIONALLY_UNAVAILABLE in getAvailabilityStatus() when they want to
hide the preference.
Because getAvailabilityStatus() is called in onCreate(), by using this,
we can fix the flicker.
Fix: 234399017
Test: visual & robo test
Change-Id: I4cb7dd95d2985bd1ca4c8cb30aaebdc21a5415f8
Add a switcher to enable/disable LE audio feature. The switcher could be
enabled by setprop ro.bluetooth.leaudio_offload.supported=true
screenshot: https://screenshot.googleplex.com/6aGP664S9PX5EMS
Bug: 233018305
Bug: 233005340
Test: make RunSettingsRoboTests ROBOTEST_FILTER=BluetoothLeAudioPreferenceControllerTest
Test: switch LE audio feature, and check LE audio functionality status
Change-Id: I8adcf27edd1438df445d32fca93f35ff5020a3b3
The usage of this dialog is removed in
Change Ie2cf147de53385ae0c626c8472306f1b85317686
But this dialog is created (but not show) in DarkUIPreferenceController
each time dark mode toggle is turned on by user.
So clean this up.
Fix: 234419979
Test: make Settings
Change-Id: Icdc9d7a4fb77dc8b2a3f1a9d8e3f40fc0af4917d
Uri.toSafeString strips out paths and shouldn't be used
for situations other than logging.
Bug: 232694281
Test: PtsPowerTestCases
Change-Id: Iec835b738c3e928e922bd6a14573106f2ce4f526
