Keyboard shortcuts are requested via WindowManager, and
the request pipes through to the view root and the window
callback.
Bug: 22405482
Change-Id: Ic0071e91c7b554be3ac9df71e9539ee8a60e822e
Cancel() has apparently never worked. Calling cancel() results
in the startTime being set to Long.MIN_VALUE. In theory, this means that
on the next animation frame (getTransformation()), the elapsed time
(currentTime - startTime) should result in a large positive number, which
is way more than needed to prove that the elapsed fraction is >1 and
therefore that the animation has ended. But in practice, anything subtracting
MIN_VALUE will result in a large negative number due to Long wraparound, so the
end check fails and the animation continues. Forever.
Moreover, event fixing the cancel issue results in a repeating animation
continuing to repeat, because the logic was never there to determine whether
a repeating animation was canceled.
This fix addresses both issues, but in a minimal way. The risk in fixing this
for real is changing the behavior of cancel in a way that existing apps would not
expect. For example, it's weird that cancel causes one more frame to run. And even weirder
that it does so with a negative elapsed duration (resulting in an animation fraction of 0).
But I wouldn't want to change that behavior for fear that I'd break apps who rely on
that weird behavior.
Instead, there's a simple check for for the "expired" check and the "repeat?" check that
sees whether the startTime has the magic value of MIN_VALUE, which should only happen
when an animation has been canceled. If this is the case, it ensures that the animation ends.
For real.
Issue #24984018 canceled animation runs forever
Change-Id: Ia137eb04bd7df3976a4d9cef86fd39a78dc56f39
For split-user cases it has been identified that provisioning
a profile-owner during user setup-wizard shouldn't cause
the setup-wizard to exit early generally. Adding this extra
allows a DPC to control whether the user can take further steps
in the setup-wizard after management provisioning completes.
Adding as a hidden extra since we don't expect this to be useful
until after N release.
Bug: 25858670
Change-Id: I599a5df4aef659769a6323402efe078d0d12d2ed
Change the current static condition to a per-user condition so we
can check and enable/disable the work challenge properly. Also add
an isAllowed API, as the Work Challenge can only be used when the
user's DPC targets N or above to maintain backwards compatibility.
Change-Id: I0cb8b475838816801868ffb24726407aa257b4de
* changes:
Report SwapPss in dumpsys meminfo when requested and available
Report SwapPss in am_pss reports
Add Swap and SwapPss to meminfo checkin dump.
Report SwapPss usage if available as part of Pss
Remove PersistableBundle.aidl from the Java framework, since it
has been moved to the native libbinder.
BUG: 26292234
Change-Id: Ia3dc49a3ad92f4c579e6dff0606c1db8fb3be76b
TEST: aosp_arm builds successfully.
- Add startActivityAndCollapse, to make collapsing the shade easy
- Add isSecure()
- Add isLocked()
- Add unlockandRun(Runnable)
- Add unavailable, active, and inactive states
The states are added to allow consistent UI across OEM devices, by
allowing UI tweaking and tinting to match system tiles with custom
ones.
The combination of isSecure() and isLocked() and unlockAndRun(Runnable)
allows all combinations of launching show when lockend and triggering
an unlock when needed for sensitive tiles.
Change-Id: Iade98ad9f2c22aa174e62090d8ccd44c86f3bb3c
- Previously when don't re-launch an activity due to configuration
change if the activity is currently pausing. And, once the pause is
complete we destroy the activity. This logic is based on the assumption
that all activities are fullscreen and pausing is the same as stopping
which means the activity is no longer visible and can be destoried.
This assumption is not true in multi-window mode where you can have
visible activities in the paused state.
We now relaunch the activity once it is done pausing.
- Previously we set the return type of the top task in a stack to home
if the previously focused stack is home while add the task to the stack.
This logic is based on the assumption that the focus stack is the front
stack which isn't true for pinned stack. This causes an activity behind
the top translucent activity in the pinned stack to be marked as invisible
and stopped since the top task is over the home task so we should be
showing the home task behind it and not other tasks in the stack.
We now set the return to task type to application type for task added to
the pinned stack.
Bug: 26273032
Change-Id: I0ffac81f46c57e2d0d900db3417381f059aee7ea
When the caller hasn't specific encryption-related matching flags,
we should match both aware and unaware components.
Bug: 26508249
Change-Id: I2c35f6e00e451ba3f5fa0810223b7a3d80dee233
This is a follow up CL for the previous commit [1], which may have
triggered an unknown bug in either Android Framework or LatinIME.
[1]: Id4d332e3909590c68345e10e1f2e18650efb2eb7
7b739a802c
InputMethodService#mSettingsObserver is initialized in #onCreate() and
cleard with null in #onDestroy(). Hence hitting NPE against it implies
that InputMethodService#onEvaluateInputViewShown() can be called before
InputMethodService#onCreate() or after InputMethodService#onDestroy().
Both possibilities are equaly problematic. Note that this might be a
long-standing issue that just became obvious because of [1].
This CL does not attempt to fix the root cause but just tries to
suppresses the NPE to unblock QA tasks. A proper fix should be made in
subsequent CLs.
Bug: 22517687
Bug: 26511607
Change-Id: I6bc87c3d18b560fe2253fb9f05557b95b04d0cf0
As seen in frameworks/support!
Previously we would not set a fragment's new state until the move to a
new target state was fully complete. This causes problems when other
parts of the fragment manager infrastructure (such as lazily
initializing a child fragment manager) read that state while we're
dispatching a state change call to a fragment.
In this situation, adding a child fragment and then calling
executePendingTransactions on the child FragmentManager would not have
the intended effect, as the child FragmentManager would still be in
state INITIALIZING. The expected lifecycle callbacks to the child
fragment would then occur later.
Fix this by updating the fragment state as we go through each phase of
moveToState before we dispatch to the associated onState method,
matching our usual pattern of invoking onFoo methods after foo has
occurred. Delete the redundant resumed field as we now can use the
state directly.
Bug 25019275
Change-Id: I97fe45578d59ab643c9779eaeb475a331e446335
Parse "SwapPss:" lines from /proc/pid/smaps if it exist, and store them
in a seperate stat entry.
Report SwapPss if made available by kernel, otherwise we fall back to
legacy Swap.
Fix getTotalSwappablePss documentation.
Change-Id: I361928c0f44c7dc9b959b91c127c916215063866
Signed-off-by: Thierry Strudel <tstrudel@google.com>
This adds android:externalService boolean attribute to <service>. If that
attribute is true, then bindService() may be called with
BIND_EXTERNAL_SERVICE to create the new service process under the calling
package's name and uid. The service will execute the code from the package in
which it is declared, but will appear to run as the calling application.
External services may only be used if android:exported="false" and
android:isolatedProcess="true".
Bug: 22084679
Bug: 21643067
Change-Id: I3c3a5f0ef58738316c5efeab9044e43e09220d01
Prevents infinite invalidation loop when reusing a drawable asset within
a single draw() call. Also reduces unnecessary extra invalidations due to
drawable setters (ex. setBounds()) being called during draw().
Bug: 26329675
Change-Id: I31b3c99e8efd4193415cc562a84c8939a2f56c2d
(cherry picked from commit 8cda8e9159)
Also adds final where the method was being called, adds Nullable
annotation to method, and updates docs.
Bug: 25985497
Change-Id: I847a8507f2e3970f1340cddf4abf8650dda22b35
(cherry picked from commit ad52693cf3)
