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
- It retrieves the flashlight status from Settings.Secure.
- It uses the broadcast relay to update flashlight status
without action on the slice.
Test: robotests
Change-Id: Ib4d636541f5166b8634326cce76aed5665989b76
Fixes: 74913192
When we query the package manager for activities that can handle the
web data uri, different capable activities within the same package will
be returned as separate entries. However, when we show the default
browser apps to the user, the entries are simply base on package name.
So, if there are multiple activities within the same package that can
handle the web data, they will be shown as duplicate entries.
When we process the resolved activities, check the corresponding package
name for duplicate entries before adding it to the default browser list.
Change-Id: I4e1f1e1ea22781efe24d791b367246423ca7a3c4
Merged-In: I70c88866eb3d5fe6466554749e23c85f429dd30c
Fixes: 84207432
Test: make RunSettingsRoboTests
When running monkey, the authority in the preference might not have been
properly set. Add a check for valid authority before trying to update
the sync automatically setting.
Change-Id: I59f910565fc9f128e86bd92337135fe46fed12e1
Fixes: 80551551
Test: make RunSettingsRoboTests
When we query the package manager for activities that can handle the
web data uri, different capable activities within the same package will
be returned as separate entries. However, when we show the default
browser apps to the user, the entries are simply base on package name.
So, if there are multiple activities within the same package that can
handle the web data, they will be shown as duplicate entries.
When we process the resolved activities, check the corresponding package
name for duplicate entries before adding it to the default browser list.
Change-Id: I70c88866eb3d5fe6466554749e23c85f429dd30c
Fixes: 84207432
Test: make RunSettingsRoboTests
The full page verion of prevent ringing is still searchable.
- Created a new controller for parent entry.
- On the child controller, inherit the same getAvailabilityStatus() but
override AVILABLE_UNSEARCHABLE to AVAILABLE so it becomes searchable.
Fixes: 72748524
Test: existing robotests for PreventRingingPreferenceController
Change-Id: Id2454db110c81b59fa4a98338602b03de0812f8a
