It turns out that the performance of
InputMethodManager#getCurrentInputMethodSubtype() is regressed from ~1ms
to ~20ms when
- Settings.Secure.SELECTED_INPUT_METHOD_SUBTYPE == -1 and
- The active IME supports many subtypes (~100)
because we try to find a fallback subtype based on the system locales
every time when IMM#getCurrentInputMethodSubtype() is called.
This could be contributing UI janks because spell checker clients
running in the UI thread indirectly depend on that method.
Fortunatelly the critical path is in
InputMethodUtils#getImplicitlyApplicableSubtypesLockedImpl(), which is
basically a state-less method. We can easily and safely cache its
result by using LocaleList and InputMethod as cache keys.
With this CL the performance basically recovers to the Android M level.
Bug: 28889203
Change-Id: I5ed16c7f14cc18052854f4fd6c9bae8550c332ee
Fixes a particularly bad transition in the case where there
is one incoming message to a group.
Change-Id: Ieddece4a496292a69e14cdcd74d94986938d8223
Fixes: 29043489
When app is resized in multi-window mode we preserve the window along
with the decor view. If action mode view was shown before such config
change, its view is detached, but the mPrimaryActionModeView variable
is not cleared. So when action mode view is shown again after that it
thinks that its view is still alive.
This CL adds additional check to inflate new mPrimaryActionModeView
if it is not attached to any window.
Bug: 28971666
Change-Id: Ia8c24d4322be32e8b2c8967301beb3a4d889d501
Also moves discharge coulomb data to BATTERY_DISCHARGE_DATA checkin line.
Bug:29264326
Bug:28743761
Change-Id: I78881e166c11f40b2397e04d2cab8d5200c71eea
For devices that report battery discharge via a coulomb counter,
record how much of the battery was discharged while the screen
was on/off.
Bug:28743761
Change-Id: Ie2d1708864352029ff466c1fed14fc057e19b93b
Un-reverts ag/1057448, but uses a version of Resources#getText
that returns null rather than throw an exception when no title
is available. This is the same call made before, so this change
should be safer.
Bug: 28744278
Change-Id: I8c123f4f6d74f796ab9e8ffcf955aaf881770da1
If the system_server crashes, when it starts back up
it will assume that the entries in kernelUidCpuTimeReader
are all fresh and we will end up double counting cpu time
and power.
Bug:29163081
Change-Id: I73e693199c170229af57efd610950e90263ac9bc
am: 5a6cf3ac9a
* commit '5a6cf3ac9a3945c2d1f0e5e28ffda9e52124eb15':
Work on issue #29042642: Watchdog going off
Change-Id: Ic0c08c2ab1c0e7b1cc195928492ab4c0eaef782f
Have FastPrintWriter note all cases where an exception is
thrown, and stop trying to push more data into the output
stream when this happens.
Change-Id: I51a1eeb26578f02b2a6f45ef7bc2513dfde702a2
Currently if an action mode is started in onCreate()
it will fade in. This isn't ideal though, especially
since Activities are recreated routinely with
multi-window and resizable Activities. In that instance
we fade it in on every recreate.
This CL fixes this in both the decor and toolbar action
modes to only fade in if the decor has been laid out.
BUG: 29036694
Change-Id: Iae985efcced170a0a4229124c1c132355c2aa71e
To avoid screen garbage or wallpaper shining through, the background
we use there for filling the whole needs to
a) Be non-translucent in all cases except if the window is translucent.
b) Don't infer it from the theme as it might be unexpected. Don't define
it in the theme, and use black if it's not defined.
Bug: 28763785
Change-Id: Ifb724b5c5feea3ed70d68e5bd7615fa91185e743
Add an extra parameter to LocaleHelper.getDisplayLocaleList()
specifying the maximum number of locales to output, as callers
probably won't need the whole list.
Bug: 28872122
Change-Id: Ief136bc1af2841e76ed4d8e65932a9a30821eae3
am: 89046edb4d
* commit '89046edb4d64fe1c7662103cce3a82b69e05cfe4':
Fix issue where max idle time > total idle time
Change-Id: Idfbfa60ec62002712073ae9af3c3e4c0e39be1e7
If the batterystats were reset while the device was
idling (via command line most likely), then also reset the
last time the device started idling so that the max idle time
calculation is correct.
Bug:28452600
Change-Id: I8a3d5dc3081deda76356c03d891e098baa85f88a
