For each visible battery tip, logs its type and state. For battery tip
with app list, also log that list:
1. HighUsageTip: apps that used too much battery
2. RestrictAppTip: apps with anomaly, also logs the anomaly type
Bug: 73888115
Test: RunSettingsRoboTests
Change-Id: I1b61eb1d793d979baab4864d2d652e12260b590d
Only disable the controllers not the whole fragment because
user might need to have entry for other features.
Fixes: 73664409
Merged-In: I98ed248cf33d11715dd523e711cbc68ebf128ef8
Change-Id: I98ed248cf33d11715dd523e711cbc68ebf128ef8
Signed-off-by: Weilun Du <wdu@google.com>
(cherry picked from commit 68a195ae93)
- other changes might have caused this test to start failing. Need more
time to investigate or properly fix the tests. Since they are blocking
presubmit right now, will ignore the tests first and provide fix
later.
Bug: 74444815
Test: make RunSettingsRoboTests
Change-Id: I985abe74c64a562fb117b91056a23895181897bd
- Remove emoji region flag in the region picker.
It's more consistent with locale picker which shows no flag in region
picker
- Remove redundant information in the summary field
e.g. same GMT offset in primary and secondary field in fixed offset
picker
- Better mode switching flow. Switch region/fixed offset mode
only when the user confirms their selection in the picker.
Bug: 73952488
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.datetime.timezone
Change-Id: Id5da8a2516acd10c9a3d71181e94bc617d797d20
- one tracking id for every picker type
Bug: 73952488
Test: m RunSettingsRoboTests ROBOTEST_FILTER=com.android.settings.datetime.timezone
Change-Id: Ia487f1657d6ed1f0fb40b61f39f4a47c38bd6179
After this cl, when user slides the slider, the text will be
updated continuously.
Bug: 73763634
Test: Manual
Change-Id: Ief9278d39426f6ec9ce9bbcc0be911d083673684
This CL logically reverts Settings app changes for Bug 25752812, which
aimed to improve UX by tightly integrating physical keyboard layout
with input method subtype.
What went wrong is that the concept of input method subtype is not
widely accepted by the ecosystem actually. Until we figoure out any
other better way here, let's revert back to the good old way that
enables users to specify multiple keyboard layouts per physical
keyboard device, not one layout per one input method subtype.
Note that we cannot simply revert the CL that originally introduced
the new flow [1] because it was indeed a huge CL that also touched IME
settings, which we want to continue using. In that sense, this CL is
a kind of re-implementation of the previous style on top of the recent
language settings flow.
Note also that a fix [2] fox Bug 25062009 was also ported from
previous InputMethodAndLanguageSetting to
KeyboardLayoutPickerFragment.
[1]: I728d7ee185827ed328c16cb7abce244557a26518
976bb3f459
[2]: I4483dfc89afc8d148b2cfa7c6a5f66d2a02f712a
17b6319884
Fix: 66498367
Test: make -j RunSettingsRoboTests
Test: Manually done with two Bluetooth keyboards
Change-Id: I7a2ed6dd39dcd8207d3d94e12cd01d5d67ba4bb5
Create the notion of an official platform slice.
This includes:
- Adding a second authority to the provider
- tagging slices in xml with a platform slice flag
- Including authority in the getUri method
Bug:73359139
Test: robotests
Change-Id: I581ee6dfcdf935f452a15e89e5d055e375ff1877
After this cl, in AppInfo we could store mutilple anomalyTypes, so
AppInfo list will only contain one instance for each uid(however
still keep all the anomaly data)
In this way we could remove the duplicate items in app dialog.
Bug: 74335346
Test: RunSettingsRoboTests
Change-Id: I2ef7c218df2a956eea66aa6bdf03f5ddd19948e3
