Some time zone related libcore classes are moving from
libcore.util to libcore.timezone.
Bug: 119026403
Test: build only
Merged-In: I920411dfa7e000a0da9678826a035e0461211619
Change-Id: I920411dfa7e000a0da9678826a035e0461211619
(cherry picked from commit 1e1961a5b3)
Test: Unit test + manual test: Mount and unmount stubvolume in ARC++,
check settings show the device correctly and could browse it using
DocumentsUI.
Bug: 110380403
Change-Id: I96fc82e731225776ac7070ef035687f83da94245
In the Device details of Settings App and when using two Hearing Aids
devices (left and right sides), this will fix the connect state messages
for these two devices. Also added Robo tests for the changes.
Test: Manual tests and also ran RunSettingsLibRoboTests and RunSettingsRoboTests.
Bug: 117074814
Bug: 116725094
Change-Id: I169cda4a1658b0a67cc7c7367b38d57a021e6953
Merged-In: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
Merged-In: I169cda4a1658b0a67cc7c7367b38d57a021e6953
Using the Settings App-Developer Options-Feature Flag, allow the user to
enable or disable the Hearing Aid Profile.
Bug: 116725094
Bug: 116044083
Test: Manual testing using Settings App
Change-Id: I16b51d7feabc914219c24731eb39a23bd1782571
Merged-In: I16b51d7feabc914219c24731eb39a23bd1782571
(cherry picked from commit 068c2547f6)
When hearing aid device has been set active, we shouldn't invoke
1. a2dpProfile.setActiveDevice()
2. hfpProfile.setActiveDevice()
Change-Id: Ie13dea041dd98d0cb9d913e1f28574b300095db9
Merged-In: Ie13dea041dd98d0cb9d913e1f28574b300095db9
Fixes: 113625278
Test: RunSettingsRoboTests
LocalBluetoothProfile.isConnectable() checks whether the user can initiate a connection
for a specific profile, not really whether the profile is connectable.
Change-Id: If6c6cd1554acf35db2460ea6ddb65148a7e86e45
Bug: 79982487
Test: atest tests/robotests/src/com/android/settings/bluetooth/BluetoothDetailsProfilesControllerTest.java
Remove wrapper for LocationManager
Remove LocationManagerWrapper from SettingsLib
Bug: 76167422
Test: RunSettingsRoboTests
Remove OverlayManagerWrapper class out from Settings
Remove OverlayManagerWrapper and use IOverlayManager instead. Based on
comment from reviewer to refactor ThemePreferenceController.
Bug: 76167422
Test: RunSettingsRoboTests
Change-Id: I13a7997b5e21a16ffb723971d267132fbf65e4a6
Task affinity updates
- Remove task affinity for AppDrawOver Settings
- Remove task affinity for ConfigNotificationSettings
The task affinity is messing with the back stack for this activity when
launched externally
Fixes: 80281932
Fixes: 80290571
Test: manual
Disable uninstall update option for secondary users.
Fixes: 110249550
Test: manual
Suppress some gesture search when there is no hardware
Fixes: 110250839
Test: robotests
Check wifi password length by byte, not char.
Change-Id: Ic25ef766886507211c3de8764c1cffef2b27a025
Fixes: 79209073
Test: robotest
- change the way that default home query the resolve activity to only
check for LAUNCHER activity.
Change-Id: Ib53154afe7951f4e2c7c3ab147be4c691113e0e7
Merged-In: Ib53154afe7951f4e2c7c3ab147be4c691113e0e7
Fixes: 112249115
Test: make RunSettingsRoboTests
When the device is not yet provisioned and settings is launched:
- disable the entry point for changing device lock
- remove the search panel from settings home page
- remove the search menu
Bug: 110034419
Test: make RunSettingsRoboTests
Change-Id: Ieb7eb0e8699229ec0824ccc19d7b958ac44965a2
Merged-In: Ieb7eb0e8699229ec0824ccc19d7b958ac44965a2
(cherry picked from commit 770f4abf9d)
Only primary user can set LOCK_SCREEN_SHOW_NOTIFICATIONS,
profile can only set notifications to be redacted. When the
user changes notification settings for a work app, this class
is invoked from the profile, meaning it attempts to read
LOCK_SCREEN_SHOW_NOTIFICATIONS for the profile, which is not
there. As a result the function always returs 0 for work apps.
Bug: 111112011
Test: atest packages/apps/Settings/tests/robotests/src/com/android/settings/notification/VisibilityPreferenceControllerTest.java
Change-Id: Ifb50209ea8ea8fb6639f00ca8b7cf8a4295890ad
(cherry picked from commit f14de789f4)
Use string arguments instead of ints for mcc/mnc
Bug: 35064313
Test: manual, unit
Change-Id: Ib460d6294d8fb86de7c2fee065defb0a890af15a
(cherry picked from commit 02c5f3c7ac)
Use string arguments instead of ints for mcc/mnc
Bug: 35064313
Test: manual, unit
Change-Id: Ib460d6294d8fb86de7c2fee065defb0a890af15a
(cherry picked from commit 02c5f3c7ac)
In the WifiTetherApBandController the incorrect method was
being called to check if the device is 5Ghz compatible. We
were calling is5GhzBandSupported directly, but we were
supposed to call isDualBandSupported instead.
Test: robotests updated
Bug: 110793581
Change-Id: I61d3ff10abedde6196b8e29591ebfd3272dbbcd9
Only primary user can set LOCK_SCREEN_SHOW_NOTIFICATIONS,
profile can only set notifications to be redacted. When the
user changes notification settings for a work app, this class
is invoked from the profile, meaning it attempts to read
LOCK_SCREEN_SHOW_NOTIFICATIONS for the profile, which is not
there. As a result the function always returs 0 for work apps.
Bug: 111112011
Test: atest packages/apps/Settings/tests/robotests/src/com/android/settings/notification/VisibilityPreferenceControllerTest.java
Change-Id: Ifb50209ea8ea8fb6639f00ca8b7cf8a4295890ad
Merged-In: Ifb50209ea8ea8fb6639f00ca8b7cf8a4295890ad
(cherry picked from commit f14de789f4)
The PowerUsageSummary fragment doesn't use the regular pattern
of a static method to build preference controllers, which can be
accessed by both DashboardFragment and BaseSearchIndexProvider,
because it depends on the Activity & Fragment in the creation of
the preference controllers.
The correct & long-term solution here would be to move those dependencies
out of the getPreferenceControllers method, such that the we could use a
static buildPreferenceControllers method, as seen in DisplaySettings.java.
In the mean time, we know that BatteryPercentagePrefController should not
show up on devices, so we conditionally add the the preference controller's
into getNonIndexableKeys method based on controller Availability, which
BasePreferenceController normally does automatically with a getPreferenceController
method in the host fragment's SEARCH_INDEX_DATA_PROVIDER.
Since this is a short-term solution, it should not be merged into master, and thus
I am not marking the bug as fixed.
Bug: 110894466
Test: Robotests
Change-Id: I06f814571d0b72fbf020dd11a9d23a9eb9907bfd
Merged-In: I5993d332dbd218c981ef5432aebb735d0000f67a
We decided to use the list preference after all due to
some devices not supporting various combinations of AP
configurations. This change makes it so that there are
three different UIs depending on the configurations
which are supported.
- 5.0 GHz unsupported: disable the preference and just
set the value to 2.4 GHz
- all supported, no dual mode: allow the user to choose
EITHER 2.4 GHz or 5.0 GHz
- all supported, dual mode: allow the user to choose
2.4 GHz or BOTH 2.4 GHz & 5.0 GHz with 5.0 being
preferred
Test: atest SettingsRoboTests
Bug: 80315296
Change-Id: I888d35811a98b8cf0155a3cb96c42ff762763378
Merged-In: I888d35811a98b8cf0155a3cb96c42ff762763378
This reverts commit ca85cc9d27.
Reason for revert: This patch should be submitted with whole topic.
Bug: 80227045
Change-Id: I446329aa3370b64b2a943a0f970d0236258455a3
