When multiple windows get created at once, multiple starting windows
will be created as well. The first window will get an animation and a
dummy animation. If another window will get shown shortly after, it
will receive the animation of the first starting window. However, no
new dummy animation should be created for it since otherwise it might
never get an animation end notification.
This CL also reverts previously added changes to ignore dummy animations.
reverted change: Ie907d31f51e130e245a70249a983d490f3d42b21
Bug: 21643278
Bug: 21403998
Change-Id: I228d77a2d9c3597df0eb9c340a65c0c592c35ce6
Add new APIs to associate a Request with a name, get all active
requests, and get active request by name.
Also add a new Activity.onProvideReferrer() which will allow
applications to propagate referrer information to the assistant
(and other apps they launch) in a consistent way.
Change-Id: I4ef74b5ed07447da9303a74a1bdf42e4966df363
PHONE_STATE_PERMISSION should not be required to register to the following
event types:
- PhoneStateListener.LISTEN_CALL_STATE
- PhoneStateListener.LISTEN_DATA_ACTIVITY
- PhoneStateListener.LISTEN_DATA_CONNECTION_STATE
In case of LISTEN_CALL_STATE, an empty string should be passed instead of
incomingNumber, when caller has no PHONE_STATE_PERMISSION.
Bug: 21588537
Change-Id: I5b6d0308924f7e4cd13a983b8e0c9b3a5bbb119b
These are more consistent and have placeholders for the description of
whatever VPN apps are actually active.
Bug: 20516964
Bug: 17474682
Change-Id: I37ff287b795f10bbbb192540f09f8100bb27b1a0
When starting an activity with Intent.FLAG_ACTIVITY_CLEAR_TOP flag,
the activity is destoried which can also cause its task to be removed
from its current stack if the activity process record is null. We now
recompute the stack for the activity task when this occurs so we
don't NPE later on.
Bug: 19552874
Change-Id: I50f51ca6dc32d4642f78d59cae93b0774bc6cdb7
(cherry picked from commit 86920fe630)
- Fix the case in WindowAnimator where the real window was ready
to draw while the starting window was playing the unlock animation.
- Always delay Keyguard done when clicking on a notification. Some
notifications started services/broadcasts instead and thus we didn't
wait, making it a jarring transition. In case the notification click
doesn't result in an activity start at all, we still have the timeout
that saves us from freezing (3s), but most notifications should start
an activity.
Bug: 19412725
Change-Id: I78f6839f59986f8f7ecdff70227d5690a504f475
In the previous CL Ib871141e3381e45c2623c5f4d692da7a7e78fcc5,
a null or empty EditorInfo#packageName was still allowed in case
there might be applications that simply forgot to set it.
However, after checking the code again, it would be safe to say
that having a null or an empty string in EditorInfo#packageName
would never happen unless the application intentionally clears it
in View#onCreateInputConnection. If there were such applications,
probably we could ask developers to stop doing that.
With this CL the system no longer accepts such an empty package
name. IME developers do not need to handle such an exceptional
case in their side.
Bug: 18931038
Change-Id: I10d579b48b59fa8ada796e92d58517c6cc5f2230
This should fix contention problems for apps using USB APIs to implement MIDI support
Bug: 20949468
Bug: 21630625
Change-Id: I32b44330ca0310a4693fd56a4b01ad399f82c1c9
...services get out of app idle
Introduce a new process state to even better distinguish foreground
services from other states. Rework the INTERACTION reporting to
usage stats to do it less when the screen is off -- require that
an app sit in the foreground service or top activity state for
at least 30 minutes before we consider it an interaction.
Also eradicate a bunch of logging in package manager.
Change-Id: I94249e67f9a9c62e9a92ae104710e6747b16327e
- force hiding window for non-main display leads into stopping
rendering of windows in non-main display.
- change the logic to skip force hiding if it is not main display.
bug: 21665476
Change-Id: I2e23f3a2d6e3cbf6819ade1798360efe2986e80e
