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
Bug: 80507279
Test: robotests
Test: inspected hprof before/after change
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
Programatically lower casing letters is bad for translations
Change-Id: Iea39186b9716f628ed96ad457b09440bd177d821
Fixes: 77961695
Test: ZenModeSettingsTest.java
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
The icons on this page were being displayed at 48dp because we were
using a generic Preference element, instead of the custom settings
AppPreference which we use in lots of other places in settings for
displaying app entries in a list (and has a custom layout that ends up
with 32dp icons).
Fixes: 78654919
Test: manual (go to Settings -> Connected devices -> Connection
preferences -> Printing)
Change-Id: Icf21ab6b41fc00936cd58f3342a8c5502c6dd87f
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
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
