When the device is not yet provisioned and settings is launched:
- disable the entry point for changing device lock
- set display search menu to false
- disallow update to display the search menu
Bug: 110034419
Test: make RunSettingsRoboTests
Change-Id: Ieb7eb0e8699229ec0824ccc19d7b958ac44965a2
When the device is not yet provisioned and settings is launched:
- disable the entry point for changing device lock
- set display search menu to false
- disallow update to display the search menu
Bug: 110034419
Test: make RunSettingsRoboTests
Change-Id: Ieb7eb0e8699229ec0824ccc19d7b958ac44965a2
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
- the resource for the summary text is in the support library. However,
the prebuilt version in the build does not contain the latest change for
the summary text. Add the overlay for the summary resource here with the
updated translation to remove the redundant summary prefix in the
advanced button.
Change-Id: Ib6db0c402d79a2d965e6060b1851d7b898ae3f94
Fixes: 111195268
Test: manual
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
Rename the new mode (only available on 2018 devices) from Automatic to Adaptive.
Bug: 110524699
Test: manual
Change-Id: I56e87ad11a94915155cff56a6a13a9e167383e0c
This CL adds an intent that can be used to start
WifiTether Settings.
Test: SettingsGatewayTest still passes
Bug: 110235497
Bug: 80251951
Change-Id: Iac94e563a91b1f821f69f18234d8176350ae5f29
Respect config_battery_percentage_setting_available to determine whether
or not to allow showing battery percentage in the status bar.
Test: visual
Bug: 80129194
Change-Id: I23b0065ed99865a8df37c098b2f0f16d57799706
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
Error handle before using LocalBluetoothManager in the onStart
and onStop
Bug: 80491267
Test: make RunSettingsRoboTests ROBOTEST_FILTER="AudioOutputSwitchPreferenceControllerTest" -j42
Change-Id: I47f7d3b7cddc2fbbafb8fb5cf0fb6adb2d0d2d55
In this controller the context is stored into a global singleton but was
not cleared, thus leaking context and associated views.
Change-Id: I4247f8ff753bc0a331c6c81a0e4b5b4bc41588de
Fixes: 80507279
Test: robotests
Test: inspected hprof before/after change
This activity alias is here since android 4.x for backward
compatibility. We no longer need it, and keeping it will cause security
issue.
Change-Id: Ib7817fd7cf8c8e66ca50534a0387cdc5773f837b
Merged-In: I3f985e7fe14bd290db73b8c46dd817591df02015
Fixes: 92497653
Test: manual
Historically, the debug menu intentionally did not
save the preferred network mode once chosen. This
causes problems because some settings cause a phone
switch which overrides the preferred network mode,
which can cause another phone switch and again
override the preferred network mode, completely
obliterating the requested debug setting. This change
will now save the debug menu setting to the system
settings, which will prevent the circular changes and
loss of setting due to phone switching.
However, caching the debug setting to prevent the phone
switch logic from overriding the setting has a side
effect, which is why it wasn't done historically.
If a debug setting of the preferred network mode
is set, it will cause the UX of the non-debug network
preference screen to change. Thus, someone who uses
the debug menu to make changes must be careful to
re-set the setting to return to the correct UX of the
publicly displayed menu.
Bug: 95133265
Test: -manually set preferred network mode using the
RadioInfo menu and observed that there is no
phone switch when setting CDMA.
-confirmed that changing the network mode in
RadioInfo will cause UX changes to the public
network preference menu.
Change-Id: I91f669956a6d02515530855c4617cd0a767d73fa
They aren't being used now, but by declaring them now we can consolidate
what we are encouraging OEMs to do in the PI timeframe.
Bug: 78013987
Test: treehugger
Change-Id: I7f86491448e799081b18d71274d2629a902d4972
