Add a (configurable) delay between when we start a maintenance
window until the minimum time we will end it.
Also switch to using the alarm manager callback API. (Yay!)
Also fix a little printing problem in the alarm manager dump
so we put the package name and not some class hash in the
summary string of an alarm entry.
Change-Id: I4281e5c80bc8b26ebc1fb6f603ec33ec0e379daa
"Share" didn't make much sense here since SENDTO is used for sending
content to a specific recipient, e.g. emailing a person from their
Contacts page in the dialer.
Bug 23626568
Change-Id: I8ac4f2aee5c41aa6c2d546b39283c6f22127cefe
Zygote process forks every child process for launch the SystemServer and other
applications. When child process is forked, unmount storage inherited
from Zygote process is executed before it gains its own root storage
space.
If Zygote have no storage spaces, unmount operations not needed to
get relevant permission storage space.
Thus unmount is executed only once shortly before the SystemServer is forked.
And the child processes do not unmount its inherited root storage space.
Change-Id: I311ca7ea2c93085f42579f8cf8bdc7ef1d570a04
This patch sets the visibility of a panel to INVISIBLE when it's
alpha is 0. This will ensure that a user cannot interact with a
view that cannot be seen. Not doing this resulted in a bug where
the user will tap on an area of the toolbar and activate an
unintended action.
It also removes the redundant mResetOverflowButtonDrawable. It's
actions are already performed in setPanelsStatesAtRestingPosition.
Bug: 27693433
Change-Id: Iafcde23622c7d1604924c520f6748fdbb8b135e7
The last caller of the deprecated constructor of InputMethodSettings was
just removed [1]. Since it is not a public API, we can now safely
remove it.
[1]: I09cba4066b95c4a9e89a3e4f83d75b97882502dc
143a6869476a4be5962d4bba3b222d078f46b9a0
Bug: 26279466
Change-Id: I9035c417d6a8166c0ef4e4c7a00c151ffdd5fb49
* changes:
Add more @NonNull/@Nullable to TextServicesSettings.
Remove an unnecessary int to String conversion.
Add more @NonNull/@Nullable to InputMethodSettings.
This follows up to a previous CL [1] for Bug 26279466.
It turns out that we have not clearly defined how nonexistent key should
be handled in InputMethodSettings#getEnabledInputMethodsStr(), e.g. it
returns "" for when mCopyOnWrite is true but returns null when
mCopyOnWrite is false.
Also, since InputMethodSettings now can revert changes made during
mCopyOnWrite is true, the caller may also start receiving null in the
following scenario.
1. call mSettings.switchCurrentUser(userId, true).
2. call mSettings.putEnabledInputMethodsStr(str) where str is non-null.
3. call mSettings.switchCurrentUser(userId, false).
4. call mSettings.getEnabledInputMethodsStr().
If the caller of getEnabledInputMethodsStr() has assumed that it would
never return null, then it would start crashing due to NPE.
With this CL, getEnabledInputMethodsStr() is marked to be @NonNull we
should no longer see such kind of NPE.
[1]: I9c6f9bb3d51174198e5f73588637f87ea0d90e11
68645a638a
Bug: 27687531
Change-Id: I169ad4957e68b65c64251b0849056195b8ca4911
Summary:
This CL introduces a unified mechanism to deal with the situation
where the application directly implements InputConnection but some of
methods are not implemented. Note that there should be zero overhead
when the application extends BaseInputConnection or
InputConnectionWrapper.
Background:
When ever we add a new method to InputConnection, there has been a
risk that existing applications that directly implement
InputConnection can get java.lang.AbstractMethodError exception at
runtime, because older SDKs do not require the application developer
to implement the methods that are newly added in later SDKs. Because
of this we strongly discouraged developers to directly implement
InputConnection interface, and encouraged them to subclass
BaseInputConnection or InputConnectionWrapper instead. That said, as
requested in Bug 26945674, there is a certain demand to be able to
implement InputConnection without depending on BaseInputConnection.
The goal of this CL is to provide a reliable and sustainable solution
to above missing method scenario in InputConnection.
One of the reasons why dealing with missing InputConnection methods is
so difficult is that what InputMethodService receives to communicate
with the target application is actually a proxy class
com.android.internal.view.InputConnectionWrapper
that runs in the IME process and immediately returns true for most of
methods in InputConnection such as #commitText() and
#finishComposingText(). Because of this asynchronous nature, it is
too late to change the actual return value that the IME receives when
the application receives those one-way asynchronous IPC calls.
Solution:
To handle those cases, this CL checks the availability of
InputConnection methods that did not exist in the initial release
before the target application calls startInput(), and let the
application to send its availability bits to IMMS so that
InputConnectionWrapper running in the IME process can be initialized
with such availability bits. Note that we do know that
BaseInputConnection and its subclasses support all the InputConnection
methods, hence for most of applications we can just assume that all
the methods are available without reflection.
With such availability bits, InputConnectionWrapper is now able to
gracefully return failure code to the IME because the availability of
those methods is immutable, except for a tricky case where the
application relies on a proxy object that dynamically changes the
dispatch target.
Here is the list of APIs that we start checking the availability in
this CL.
[API Level 9+]
- InputConnection#getSelectedText(int)
- InputConnection#setComposingRegion(int, int)
[API Level 11+]
- InputConnection#commitCorrection(CorrectionInfo)
[API Level 21+]
- InputConnection#requestCursorUpdates(int)}
[API Level 24+]
- InputConnection#deleteSurroundingTextInCodePoints(int, int)
- InputConnection#getHandler()
Ideas alternatively considered: Default methods in InputConnection
We once considered having default methods in InputConnection but
abandoned this idea because it does not directly solve the problem
about how to tell the that the API does not take effect.
Also having default methods would make it difficult for application
developers to be aware of newly added methods in InputConnection.
Bug: 27407234
Bug: 27642734
Bug: 27650039
Change-Id: I3c58fadd924fad72cb984f0c23d3099fd0295c64
We were returning the RxtimeMillis counter instead of idleTimeMillis
counter in |getIdleTimeCounter|.
BUG: 27268322
Change-Id: If08a64095b375e078aef2a935b144c4285ead08b
We now wait until both the wallpaper imagery and the metadata have
been restored [if present], and then explicitly regenerate the crop
from the source based on that.
Bug 27423845
Change-Id: I986efd13b6b73d25b5ab1215af516ccea3a5c609
- When setting blanket user restrictions, per-package
exemptions may be granted.
- Exempt the current active VrListenerService from the
blanket restriction on drawing overlays while in VR mode.
Bug: 26775563
Change-Id: I14b17a126502c7905a970ad42d25d6dd600b86b1
With this CL, we expand the target of Bug 27129703 and Bug 27348943 to
non-keyboard subtypes.
Suppose there is a handwriting IME (mode == "handwriting") that supports
the following 5 subtypes.
- en-US
- en-GB
- fr
- sr-Cyrl
- sr-Latn
Also suppose the system languages are configured as follows.
1. sr-Latn-RS
2. ja-JP
3. fr-FR
4. en-GB
5. en-US
In this case we want to enable [sr-Latn, fr, en-GB] by default when
"use system language" is checked in the subtype enabler.
See previous commits [1][2] about how we addressed those issues for
keyboard subtypes.
[1]: Iaf179d60c12b9a98b4f097e2449471c4184e049b
e985c240e3
[2]: I8fc774154f5175abff2f16e8f12a4847bf5f5b7c
072a95a309
Bug: 27560993
Change-Id: I416b5671602c550805ed6267dd210968aa1de83c
This CL addresses a regression introduced by a recent CL [1] that
non-keyboard subtypes are no longer implicitly enabled based on the
system language (a.k.a. "use system language" in the subtype enabler)
due to a type mismatch in comparison.
Here is the original logic:
if (language.equals(systemLanguage) && systemLocale.startsWith(locale))
And here is the logic replaced by [1]:
if (locale != null && locale.equals(systemLanguage)) {
The new logic is simply broken, because locale is a Locale object while
systemLanguage is a String object. It never matches.
With this CL we will compare the system language with the locale
language again, with several test cases that should have been included
in [1], as a temporary solution until we start relying on
LocaleUtils#filterByLanguage() for non-keyboard subtypes.
[1]: Iaf179d60c12b9a98b4f097e2449471c4184e049b
e985c240e3
Bug: 27560993
Change-Id: If2d1710174853180465832e6ecbbb91235b76210
Each Activity has a Resources object whose underlying state changes
when a configuration change occurs, both global and for that activity only (multi-window).
Views and other clients of the Resources object can safely cache it knowing that
they always have a reference to the most up-to-date resources.
This applies to Resources.Theme objects as well.
Bug:26854894
Change-Id: Ifd3da5a1086e17f747dfc265a447fe92a3a5c692
Meta + [ / ] will dock top window to left / right or cycle
between 1/3 1/2 2/3 of screen if it's already in docking mode
Change-Id: I546418235a9b9699d406b04f52914c85bd950532
(cherry picked from commit 63635675b56564a17e3897a221d73a19cfbc77f7)
* changes:
Removed the group expand button
Removed the bundle number from the header
Fixed a crash with notification children
Fixed a bug where the media header wasn't indented
Fixed fading and dozemode for custom notifications
Fixed a group bug with a single expanded child
Fixed a bug where the top child notification wasn't expandable
Fixed a bug where heads up where not expandable by touch
Fixed a bug where the wallpaper was shining through the background
This is 2nd attempt of I5bb1bd8cdb9096d516d60beb9936e55bf2b757ae
The motivation of this CL is enhance the default IME subtype enabling
algorithm. The new approach is done by score based algorithm. The
design of the matching score is determined as follows:
- The matching score for the each two locale is up to 3 and determined
as follows:
- Score of 3 : matches all language, script and country.
- Score of 2 : matches the language and script.
- Score of 1 : matches the language regardless of country.
- Score of 0 : doesn't match the language regardless of script and
country.
- All locales are fully expanded before matching by addLikelySubtags in
ICU.
Bug: 27129703
Bug: 27348943
Change-Id: I8fc774154f5175abff2f16e8f12a4847bf5f5b7c
This reverts commit 9e7a1c9824.
Seems that that CL causes ArrayIndexOutOfBoundsException when
initializing InputMethodManagerService, which results in an infinite
boot animation.
Bug: 27129703
Bug: 27348943
Change-Id: I474a87876670ac018c675ac7b4608e90fbb2434b
The motivation of this CL is enhance the default IME subtype enabling
algorithm. The new approach is done by score based algorithm. The
design of the matching score is determined as follows:
- The matching score for the each two locale is up to 3 and determined
as follows:
- Score of 3 : matches all language, script and country.
- Score of 2 : matches the language and script.
- Score of 1 : matches the language regardless of country.
- Score of 0 : doesn't match the language regardless of script and
country.
- All locales are fully expanded before matching by addLikelySubtags in
ICU.
Bug: 27129703
Change-Id: I5bb1bd8cdb9096d516d60beb9936e55bf2b757ae
If the list of providers for the application being bound is empty,
don't bother trying to register them.
Bug: 27510621
Change-Id: I921fb70a4c97433fa123fa88e170745ee013ee35
Saving the scroll position and the search string when the region
selection list is displayed, and restoring them when we get back.
Bug: 26939696
Bug: 26943248
Change-Id: Ia01348923be7d8b9f9d0a3d3377c3bf8ce3132f7
The reason was that we're using a different textview there which uses
a SimpleLayout. This is now changed to also use the same one.
Bug: 27436418
Change-Id: I7e6dd503e09cf69ba8ed5bb6dd07fc79ee519cd3
Even if English US is suggested, when choosing English I should
still see US in the country list.
Because now the same LocaleInfo object (from cache) can be present
in both lists (language & region), it means that the label should
depend on the context.
We also need to explicitely disable suggestions in the region list.
Bug: 26590073
Bug: 26939203
Change-Id: Ib1cbad9d26a8b183bf462505335bef04193e82f4
It turns out that my previous CL [1] unexpectedly changed the behavior
of InputMethodUtils#getImplicitlyApplicableSubtypesLocked() in terms of
when "EnabledWhenDefaultIsNotAsciiCapable" extra value is taken into
account.
Suppose if an IME X has the following three subtypes:
A. locale: en_US
mode: handwriting
extraValue:
B. locale: hi
mode: keyboard
extraValue:
C. locale: en_US
mode: keyboard
extraValue: AsciiCapable
D. locale: zz
mode: keyboard
extraValue: AsciiCapable, EnabledWhenDefaultIsNotAsciiCapable
Given the above subtypes, here are results of what subtypes are enabled
by InputMethodUtils#getImplicitlyApplicableSubtypesLocked() I) before
the CL [1] and II) after the CL [1].
- system language: hi:
I: B, D
II: B, D
- system language: hi-IN:
I: B, D
II: B, D
- system language: en-US
I: A, C
II: A, C
- system language: en-GB
I: A, C
II: A, C
- system language: ja-JP
I: B
II: D
What my previous CL actually broke is the the last one, and it's broken
because we accidentally started using
"EnabledWhenDefaultIsNotAsciiCapable" even when there is no subtype that
matches to the requested language. Previously that attribute was used
if and only if 1) there is a subtype that matches the requested language
and 2) that subtype is not marked to be AsciiCapable.
If there there is no subtype that matches to the requested language,
what we had relied on is actually the result of
InputMethodUtils#findLastResortApplicableSubtypeLocked() called with
canIgnoreLocaleAsLastResort = true,
which means that we had just picked up the first keyboard subtype as the
last fallback candidate regardless of it's locale. This is why the
subtype B should be picked up in the last case where system language is
ja-JP.
This CL fixes the above unexpected behavior change regarding
"EnabledWhenDefaultIsNotAsciiCapable" so that the previous behavior can
be preserved.
[1] Iaf179d60c12b9a98b4f097e2449471c4184e049b
e985c240e3
Bug: 27129703
Bug: 27425459
Change-Id: Icd86cad955bf827a1eb41255f57fdf4ec315b93b
From the runtime perspective extract-only/profile-guide-compiled/fully-
compiled oat files are up-to-date and don't need dex2oat. However,
wihout knowing the exact "class" of the aot file we are not able to do a
full compilation of something previously only-extracted, or limit
profile-guide compilation to only previously profile-guide or extract-
only oat files.
GetDexOptNeeded now accepts a mask of desired types of compilation
that the runtime takes into account when advising what's needed.
This CL adds the necessary handling in DexOptimizer.
Also:
- removes the contraint to use extract-only oat files only when
profiles are enabled.
- removes mDexOptPerformed which interfere with the different types of
compilation and only saved a call to GetDexOptNeeded.
Bug: 27189430
Change-Id: Iced2bdcc3aa7866ff888a3bace43f4b71fffb353
