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
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
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
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
- Disable audio swicher while Bluetooth feature is not supported
- Error handle before using LocalBluetoothManager in the constructor
Bug: 80491267
Test: make RunSettingsRoboTests ROBOTEST_FILTER="AudioOutputSwitchPreferenceControllerTest" -j42
Change-Id: I971f31cd08dd0a2778548f6d1d675f279d92ef8e
To unify all Settings slices into one row, we change
Settings Slider from user a header and a input range to
only using an Input Range.
Change-Id: I61715a45b29b6a52a47711811e5c6b2c83d50901
Fixes: 80430118
Test: robotests
- In handleDisableable(), call getKeepEnabledPackages() in the same way
as AppActionButtonPreferenceController.
- Update getKeepEnabledPackages() to dynamically query default phone/sms
app packages.
Change-Id: I8dc7d6248cf440dcc053f6acba9d5548d5670c41
Merged-In: I8dc7d6248cf440dcc053f6acba9d5548d5670c41
Fixes: 80328396
Bug: 80312809
Test: robotests
Bluetooth fragment was manually setting intent information,
which meant that the result didn't fire an intent properly.
This type of regression or mistake will be caught in the fix for
b/77921040.
Change-Id: I49f87f40acbfc3f74ea2e97835f2644d443169e2
Fixes: 80317645
Test: robotests
When checking language/build fingerprint to skip reindex, language check
was comparing Locale object and String object, so they would never be
equal, so we accidentally reindex every time.
- Switched Objects.equal to TextUtils.equal, this catches the error at
compiler level.
Bug: 80065409
Test: compile/robotest
Change-Id: I2b3c68bb1c2fd876338f42321605567d7e64d64b
Despite our hope, devices prior to P18 just don't have the dynamic range
to give three distinct vibration intensity settings. Given this, only
show an on / off toggle for devices by default unless they explicitly
opt-in to multiple intensity levels.
Test: m -j RunSettingsRoboTests
Bug: 80243632
Change-Id: I14ece855cf20f9fa44b0648d28f89c0053be5c5f
Special case Uris need to explicitly add their intents.
This unfortunately duplicates a list of special-cased Slices,
but I have attached a bug with a plan to address this duplicity in Q.
Change-Id: I346915c32543713d33716422018d7c950cce323d
Fixes: 80065409
Test: atest SliceDeepLinkSpringBoardTest
