This is a follow up CL for I7d932e60311b80c05be8f02c9e803f18da0e0054,
which revealed that we could not use deprecated 2-letter code like "in"
to query subtype which has new language codes like "id".
This CL addresses the above issue by normalizing the language code
with Locale#Locale(String, String) before comparing one to another.
Change-Id: I26e3aa0333aa3c76c80a3c1c9090cc2b368c8e10
This CL adds several unit tests for following CLs, both of which enabled
InputMethodUtils (and dependent IMF logic) to handle 3 letter language codes
and conversion from deprecated two-letter codes to new ones correctly.
- Ibb9eb9f65323795d139b16d76b7e7e36a4e0568c
- I6571d464a46453934f0a8f5e79018a67a9a3c845
As described in tests, the input method framework has already been able to
recognize 3 letter language codes. However, there remain inconsistencies
when we use deprecated 2-letter code to query subtype like "in" but the
subtype has new language codes like "id". Subsequent CLs are supposed to
address remaining issues.
bug: 10090157
Change-Id: I7d932e60311b80c05be8f02c9e803f18da0e0054
If we were drawing text with drawTextAbsolutePos() false, we would
draw the first character at 0,0 but subsequent characters would get
improperly offset by y. (or x if vertical text)
Change-Id: I4e76cd9d95bf1bb6ac021d99ef7cdd6333a290ba
Every time the battery level changes, a new extended
detailed use data structure is written to the history.
This currently only contains delta CPU use since the
last detailed entry (total CPU and to three uids), but
it gives us the infrastructure for adding more detailed
data in the future.
A detail entry for regular history looks like:
Details: cpu=15730u+2307s (u0a57=11312u+502s, 1000=2344u+701s, 0=473u+991s)
/proc/stat=15377 usr, 1797 sys, 197 io, 0 irq, 8 sirq, 23103 idle (42.9% of 6m 44s 820ms)
u is user-space cpu time, s is system/kernel time.
The equivalent check-in output is:
9,h,0,Dcpu=15730:2307/10057:11312:502/1000:2344:701/0:473:991
9,h,0,Dpst=15377,1797,197,0,8,23103
Also add a new "unplug" command to the battery service,
to easily put it into a state where it always considers
the device to be running on battery.
Change-Id: Ic76d966f11e592b9dd671879977bf999ebc11eef
When a device was woken up in a different orientation than what it
went to sleep in, the window manager would force a resize to get it to
predraw in the new orientation. The predraw was done in the old
orientation however because layouts are skipped when the activity was
stopped.
This change allows layouts to proceed when the activity is stopped if
the flag to report resize events is true.
Fixes bug 18444400.
Change-Id: Ib2def3449dd67918f6fb838bdb1fe5cc6ec57f8e
- Recognizing that computeScreenConfigurationLocked() only returned
false if mDisplayReady was false allows multiple code
simplifications.
- Make computeNewConfigurationLocked() always return a non-null
value.
- Remove unused Session parameter from removeWindowInnerLocked().
- Just allocate mForceRemoves one time.
- Since ADJUST_WALLPAPER_VISIBILITY_CHANGED was unused have
adjustWallpaperWindowsLocked() return a boolean.
- Remove unused long parameter from handleNotObscuredLocked().
Change-Id: Ifd15736b163ab6e989f8ca32cf8f94b316386216
Also,
* Only restore recent task to a full screen stack instead of any
randomly sized stack.
* Fixed issue where we were restore task from recents for some
operations when we didn't need to.
* Null out TaskRecord.stack when the task is removed from the
stack.
Bug: 19083170
Change-Id: I4e006f101f9d0f2aebde130ad77afc4d258c6612
There are several places in the code that currently attempt to parse the
sub ID directly from the phone account which is undesireable. Before we
can change from using the subID to using an ICC ID with the phone
accounts, we need to create a conversion method so that no other
components are parsing the sub ID out of the phone account directly.
Change-Id: I74547fe0807da2fe13f3ff4422cd1d0a7a20d04c
This change will allow us to create ActionMode representations on the
fly after onCreateActionMode by using the Decorator pattern. The new
ActionModeWrapper will be responsible for the creating the
appropriate ActionMode depending on the type chosen by the client,
and setting it up.
Things pending that are NOT addressed by this CL:
- ActionModes created by callback.onWindowStartingActionMode(). This
includes all current usages in an existing ActionBar, as it is
handled by Activity. This requires some additional refactoring.
- Representing the floating type
- Moving the view creation code specific to StandaloneActionMode
from DecorView to ActionModeWrapper, decoupling DecorView from
StandaloneActionMode completely
- Supporting two ActionModes in parallel in DecorView, one of each type
Change-Id: I1a8db711f53b771eac74f0e6496106acf1ca2727
