Spec: go/ebs-low-battery-mode-flow
- Basically when the user manually enables battery saver 4 times,
we show this notification to suggest turning on "scheduled"
(i.e. auto) battery saver.
- We show it through 8th time. If the user hits "no thanks",
or if auto-saver is enabled already, we will not show it.
- Introduced a new notification channel "HINTS" with
IMPORTANCE_DEFAULT.
Bug: 74120126
Test: Manual test with ll development/scripts/battery_simulator.py
Change-Id: I713abc59dc7caee6882ba848c3e3aabaf778c2bd
DynamicLayout is required when
- The text is Editable.
- The selection is enabled on TextView.
This CL stops using DynamicLayout when the TextView is not selectable
TextView and the input text is PrecomputedText.
Bug: 72998298
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: Ic4a66ad3ed8868570735e3199879b74132a8c4aa
- When battery saver is enabled manually (i.e. via PM.setPowerSaveMode()),
it'll stick, and we'll re-enable battery saver even after a reboot
or a charge.
- Extracted all battery saver state transition logic into a separate
class.
Fix: 75033216
Bug: 74120126
Test: Manual test with "dumpsys battery set ...."
Test: atest $ANDROID_BUILD_TOP/frameworks/base/services/tests/servicestests/src/com/android/server/power/batterysaver/BatterySaverStateMachineTest.java
Change-Id: If020cd48f341b339783fe09dd35bc7199e737a52
Test: dumpsys power
Test: incident_report power
Test: atest CtsBatterySavingTestCases
TimeSparseArray - used to store UsageEvents - can keep at most one event
per millisecond, which can result in an event being replaced by another
event that occurred close enough that the system records it at the same
millisecond.
Test: atest android.app.usage.TimeSparseArrayTest
Fixes: 73832306
Change-Id: I860a101ab098f65d5c5832758832f43572865690
Permits syncing over a specific network instead of the default for
the process. This was causing an issue with Android Wear devices
paired with iOS where the default network is bluetooth
(see b/32663274).
This CL is in support of ag/3776564
Bug: 32663274
Test: adb shell am instrument -e class android.net.SntpClientTest -w \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Change-Id: Ic9fc169cf75457810d4992121d85d7642e350b90
The flag should only ensure that smart linkify calls behave in the
legacy way instead of totally disabling linkify.
Also, to keep the flag consistent with smart_selection_enabled and
smart_text_share_enabled flags, the flag should only disable the
SmartLinkify (i.e. Linkify.addLinksAsync) feature not TextClassifier
APIs (i.e. TextClassifier.generateLinks).
Also fixes issue with non-focusable TextViews by firing the primary
action instead of showing the floating toolbar. (b/73156794)
Bug: 75967597
Bug: 73156794
Test: bit FrameworksCoreTests:android.text.util.LinkifyTest
Test: bit CtsTextTestCases:android.text.util.cts.LinkifyTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: manual - checked behaviour turning flag on/off
Test: manual - checked behaviour with TextView.setFocusableInTouchMode(true/false)
Change-Id: I541f60161b9cd63ce7e57235607500f2fb0841e7
This is so we can add a GTS test to affirm that GMS devices include the
Google Cloud Key Vault root certificate.
Test: runtest frameworks-core -p android.security.keystore.recovery
Bug: 74621045
Change-Id: Ib6431f5739f3dff066832e6aa300dd9da5bc0727
The syntax of that setting changed from P Developer Preview1 to the final P, so
it's safer to use a new name than risk breaking devices during the update.
Bug: 74458004
Test: atest CtsAutoFillServiceTestCases:VirtualContainerActivityCompatModeTest\
FrameworksCoreTests:SettingsBackupTest
Change-Id: I1c507e8eae20f598dfe259178667ae6c2bc892ff
updateBluetoothStateLocked does not check for null values, causing
NPE. This patch reverts part of the change in 3445570. Instead, an
update method is added to LongSamplingCounter, which accepts
cumulative values.
Fixes: 75963520
Test: LongSamplingCounterTest
Change-Id: I89eba8e20f8f055c60f4ff250653345a22536189
- Show the battery saver confirmation dialog only for the first time.
- Start counting # of manual activations, which will be used in a
follow-up CL.
Bug: 74120126
Test: Manual tests with ./vendor/google_experimental/users/omakoto/android-battery-tester
Test: m -j ROBOTEST_FILTER=BatterySaverUtilsTest RunSettingsLibRoboTests
Test: cd frameworks/base/packages/SystemUI/tests && \
atest src/com/android/systemui/power/PowerUITest.java src/com/android/systemui/power/PowerNotificationWarningsTest.java
Change-Id: If6a081a6222e6a87c4cd332364c89856e7648a36
Imagine the scenario where three IMEs are installed, and only the last
two are enabled:
IME A:
* a pre-installed IME
* has a subtype [mode="keyboard" && isAuxiliary=false]
* disabled by user (hence not included in ENABLED_INPUT_METHODS)
IME B:
* a pre-installed IME
* has a subtype [isAuxiliary=true]
* currently enabled (included in ENABLED_INPUT_METHODS)
IME X:
* not a pre-installed IME
* has a subtype [mode="keyboard" && isAuxiliary=false]
* currently enabled (included in ENABLED_INPUT_METHODS)
In this scenario, when the IME X is uninstalled, the current
implementation of InputMethodManagerService (IMMS) does not try to
hard reset enabled IMEs because there is still one enabled IME, even
though it is an auxiliary IME.
This can, however, be problematic because an auxiliary IME is just a
supplemental IME and user may not be able to easily access the UI to
re-enable non-auxiliary IME such as IME A. For instance, on the lock
screen there is no way to manually re-enable the IME A.
With this CL, every time the available IME list is updated, IMMS
ensures that at least one non-auxiliary IME is enabled. If no
non-auxiliary IME is enabled, then IMMS tries to pick up one from the
pre-installed IME by using the same logic when choosing the default
enabled IMEs for the hard-reset scenario.
Bug: 71509065
Fix: 71509065
Test: atest FrameworksCoreTests:com.android.internal.inputmethod.InputMethodUtilsTest
Test: Manually verified in the above scenario
Change-Id: I88c69f548526b35f0e4ba37489365b2433373b04
For experimentally varying parameters of the framework's various wifi
scoring methods.
Bug: 65216267
Test: atest SettingsBackupTest
Change-Id: I6b1476aff8c18e4dd2b5ae8d41b5a48d2b4de283
To hold the original text in PrecomputedText, need to create
SpannableString, but copying NoCopySpan causes some side effect.
This CL introduces a way of copying SpannableString/SpannedString
with all spans other than NoCopySpan.
Bug: 72998298
Bug: 35638900
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: I20dea2114ccaa54b16ff679c97682a5003f9a4c1
It is not clear when the day should start. Further a day might have
25 hours in the case of daylight savings time.
Hence a day in this case is the last 24 hours, not a calendar day.
Keeping track of the time of each operation might waste memory as we
don't need that much precision.
Hence keep track how many operations were performed in the last 24
hours in buckets of hours. If the total count reaches a maximum suppress
any further operations.
The maximum is configurable via global settings. It can be updated
by apps that have the appropriate permissions. Hence if the default
value turns out to be incorrect, it can be adjusted after release.
This does not throttle based on battery state as it is better to
completely unload the sound model to not even have a detection event.
Test: atest SoundTriggerDetectionServiceTests (separate CL)
atest android.provider.SettingsBackupTest
Bug: 73829108
Change-Id: Ied8570b60b61b6a055bd2576d1502c1b36424efa
The service is meant to replace the PendingIntent based API. Once all
users of the PendingIntent based API switched the PendingIntent based API
will be removed.
To have as little as possible impact on the whole SoundTrigger framework
the RemoteSoundTriggerDetectionService class implements the same
interface as the PendingIntent based class. Hence the exising code has
very little change. Further once the old code can be removed the amount
of changed (and added) code is limited.
The RemoteSoundTriggerDetectionService -> SoundTriggerDetectionService
is a vanilla as possible service implementation. The special behaviors
are:
- The system holds a wakelock while service operations are in progress
and the service is bound as foreground. Hence the service can e.g.
listen to the microphone.
- Service operations have a certain amount of time they are allowed to
run. Once every operation is either finished or the the operation
exceeded the allotted time, the system calls onStopOperation for each
still pending operation. This is a similar model as for the commonly
used JobService.
Please note that if the time allowed for an operation is 15s and
op1 was run as 0si, and op1 was run at 5s, the service is allowed to run
until 20s. Hence _both_ onStopOperations will happen at 20s. This is
done for ease of implementation but should not give the service more
power than calling onStopOperation exactly 15s after each operation is
triggered.
- If an operation is done before the allotted time is reached, the
service can declare the operation as finished manually by calling
onOperationFinished. This is a call back into the system, hence a
'client' binder is sent to the service. If the operation is finished
by calling this method onStopOperation will not be called.
- As the service instance might be killed and restored between
operations we add a opaque bundle 'params' to each operations. The users
of the API can use this to send data from the start command to the
operations. It can also just be set to null. The params are not meant to
store changing state in between operations. Such state needs to be
persisted using the regular methods (e.g. write it to disk)
- A service can be used for multiple recognition sessions. Each
recognition is uniquelity defined by its sound model UUID. Hence each
operation gets at least tree arguments: Operation ID, sound mode UUID, params
- As a small optimization the params are cached inside of the service
instance.
The time allowed for each operation is in a @SystemAPI global setting,
so the service can make sure it finishes the operations before they are
stopped. It might take some time to deliver the operations via the
binder, hence it is not recommended to try to use every last ms of
allotted time.
Test: atest SoundTriggerDetectionServiceTest (added in separate CL)
atest android.provider.SettingsBackupTest
Change-Id: I47f813b7a5138a6f24732197813a605d29f85a93
Fixes: 73829108
This enables us to mess with the different scan intervals and shift
clients to a different scan mode in the background based on what scan
interval values we choose for the different power modes.
Bug: 71765044
Test: None. Just adding a key.
Change-Id: Id48ebc521dd3fe8a68c9c4c0bdb1018ea5b3743e
A double stop request is possible when display is being locked.
An activity may receive a "sleep" message followed by "stop",
both of which try to move it to stopped state.
An example when this happens: a keyguard is set up and the screen
is being locked. The keyguard will occlude the activity, which
causes a transition to paused state and, eventually, to stopped
state. A "sleep" message can be sent sometime before "stop" message
and will ignore that activity is in the process of becoming stopped.
Change-Id: I09e2c26004664b6e73ac5c2b6fe88bdf8271cf34
Fixes: 74967786
Test: FrameworksCoreTests:ActivityThreadTest
This reverts commit 6750352248.
Reason for revert: Added SElinux policy to allow the service to be started. Verified by local testing on the latest pi-wear-dev.
Bug: 74018496
Bug: 75974893
Change-Id: I9bd8939f6292be9c160e19ebdf934023792059ba
