Bug: 80507279
Test: inspected hprof before and after fix
Change-Id: I6ea2925695deb6261263649e858484e1667ec522
Merged-In: I6ea2925695deb6261263649e858484e1667ec522
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
Because I missed them in the long whitelist the first time...
Change-Id: I9fbd7b33e06b3f2f6e5e5778f78abfdb1a52006a
Merged-In: I01c8c80fe306667c1d3ac007b16fad546c5a5f40
Fixes: 79779103
Test: robotests
- Update preference key to match the key defined in SettingsSlicesContract
- Model TwoStateButtonPreference similar to TwoStatePreference (add
setChecked, isChecked method)
- Remove TwoStateButtonPreferenceController entirely because all methods
are moved into Preference directly for better encapsulation.
- Make BatterySaverButtonPrefController direclty implement
TogglePreferenceController. It was not possible before because the
interface between TwoStateButtonPreferene is too different from
TwoStatePreference.
Bug: 80106671
Test: robotests
Change-Id: Ib72807dcf1b36e959e08df8d80538c3f9f79b76d
Merged-In: Ib72807dcf1b36e959e08df8d80538c3f9f79b76d
Before this CL, we use packageManager to get uid for battery
restriction. However it may not be correct all the time.
For example, RestrictedAppDetails will be opened as main user
however inside we also show work profile apps, in this case
we can't get correct uid by only using normal API in PackageManager.
This CL change it to use uid from AppInfo, which is correct all
the time.
Bug: 79992590
Test: RunSettingsRoboTests
Change-Id: Id33a5f6409d6bace0d756e5ac06432acb8b2cf65
This CL adds confirmation dialog in "Restrict app page". By go through
BatteryTipDialogFragment, it will find the correct action, in which
we already have log:
1. RestrictAppAction
2. UnRestrictAppAction
Bug: 79992590
Test: RunSettingsRoboTests
Change-Id: I179fbd17a012528fdfacf42e4a93943eaefff23d
Merged-In: I179fbd17a012528fdfacf42e4a93943eaefff23d
When restrict tip update, we should also update app list unless it goes
from NEW to INVISIBLE. After that it won't show "0 apps been
restricted".
Change-Id: Iedf4288fcddfe632a9ba8c16afdfb5bc044bce2e
Fix: 79890132
Test: RunSettingsRoboTests
Before this CL, we will drop log for excessive bg anomaly that
target O or higher. This CL doesn't drop it however merge it to
ACTION_ANOMALY_IGNORED
Bug: 79944380
Test: RunSettingsRoboTests
Change-Id: I46d0bdb1191d8843ba373e59afb1b0ba16057661
Add a type for battery receiver, then in callback client know for
which reason it been invoked:
1. battery level change
2. battery saver state change
3. battery plug state change
So in this CL, we won't update battery tip for battery level change,
then battery tip won't be dismissed by itself.
Also note in onResume() we will manually update battery tip. So if
user stay in battery settings page and close the screen, once he opens
it we will still force update everything.
Fixes: 79171742
Test: RunSettingsRoboTests
Change-Id: I997844216fd8267e545d74e0d434de9e338f76a1
Merged-In: I997844216fd8267e545d74e0d434de9e338f76a1
Power whitelisting and background restrictions are opposing rules, so to
keep apps out of confusing states, unrestricting an app whenever it is
put on the power whitelist.
Test: atest RunSettingsRoboTests:HighPowerDetailTest
Bug: 77924141
Change-Id: I4952ac6c893bc7e98aa1b6ad3a86906fc299dea5
The action should be same as EarlyWarningTip.
1. Option to "turn on battery saver" is battery is low
2. Or show "battery saver is on" and take user to "battery saver" page.
Fixes: 76113067
Test: RunSettingsRoboTests
Change-Id: I896358305a8ae4cd97c3864bbf6e556b4d025dd7
1. Message in high usage dialog
2. Title in app usage list
Change-Id: Iac610483e10e8d2a93a18ca664aec17d9561aaf8
Fixes: 78638843
Test: RunSettingsRoboTests
Even though onStopJob is called, the service may still exist, so
we need to reset the mIsJobCanceled in onStartJob
Also remove the batteryStats since we don't need it anymore.
Change-Id: I6d48efecb750ad4e464569cac426d87014a8db90
Fixes: 77968649
Test: RunSettingsRoboTests
This tip was punted however we need to bring it back to P. It happens
when battery level is low or remaining time is less than 3 hour. The
suggestion is to turn on battery saver.
1. Extend tip from EarlyWarningTip since it has most common logic
2. Update the detector to align it to battery saver notifcation in
systemui.
3. Update tip order to surface low battery tip.
Follow CL will:
1. Hook up the low battery threshold to server side
2. Add test stub for this tip, so we could trigger it by adb.
Change-Id: I14f9696a549393bf980e31838fb86afd5d9efbc7
Bug: 76113067
Test: RunSettingsRoboTests
Distinguish between settings which are permanently unavailable on
the device, and temporarily unavailable. This enables us to restrict
which setting slices are exposed in onSliceGetDescendants.
The primary changes in this CL are renaming:
"DISABLED_UNSUPPORTED" -> "UNSUPPORTED_ON_DEVICE"
to be more clear the the setting will cannot be accessed on the device, and,
adding a new enum to encapsulate settings which are currently unavailable, but
could be enabled in the future.
Also remove UNAVAILABLE_UNKNOWN. Devs should never need this enum.
Bug: 78910582
Fixes: 79245656
Test: robotests
Change-Id: I42c2cedab66be2d76999795f46470a079cc1ec71
Merged-In: I58821a6cfd6134b3b351657b6edf5f74ead00643
We don't need it anymore because we don't auto restrict this
anomaly.
Bug: 79210436
Test: robo test still pass
Change-Id: I186213a57f9bf54a0e19985f2c92169c6dc0571c
1. Strings for the tip preference
2. Strings for the tip dialog
Change-Id: I59c371328ec735a0b22f707d440f3be85cf59c77
Fixes: 79171948
Test: Manual & RunSettingsRoboTests
If job has been stopped by any reason, we should cancel the background
thread, otherwise it will throw SecurityException when dequeuing from
JobParams.
This CL adds a lock to synchronize the method and stops dequeue work
if job has been canceled.
Change-Id: I7732b7f7d444a55a4b4ba6645cd2c16b6f840a6c
Merged-In: I7732b7f7d444a55a4b4ba6645cd2c16b6f840a6c
Fixes: 77968649
Test: RunSettingsRoboTests
The summary is "Battery may run out soon", it doesn't make sense
when device is charging.
Change-Id: I27394c8a75dac4dcad171e5e215102d39cb33546
Fixes: 78261389
Test: RunSettingsRoboTests
1. Dismiss this tip once user clicks it and goes to detail page.
2. In auto restriction, since apps are automatically restricted,
we need to remove apps in list that unrestricted by user.
3. Refactor the code to remove the unnecessary parameter(i.e.
SettingsActivity)
Bug: 78187414
Test: RunSettingsRoboTests
Change-Id: I1c950f7c55df35795641c2ea8579ce9e011dba28
APP_STANDBY_ENABLED is controlled by server side to do experiment.
Before this CL, Adaptive Battery is hooked up to this flag, so
even though if user turns it off, it may be turned on by server.
Add a high level ADAPTIVE_BATTERY_MANAGEMENT_ENABLED to control
the feature in settings UI side.
Bug: 78153913
Test: RunSettingsRoboTests
Change-Id: I1a18d622ddc31ec4d45db918bf981516fbb926c1
