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
Re-checkin of 7f8be9d89b7f294bf5e5d377908a5c74d2f4968f.
ORIGINAL CHANGES:
Per API review, move TelephonyManager.notifyCarrierNetworkChange() to
CarrierService.notifyCarrierNetworkChange(). Underlying telephony
implementation remains unchanged.
Also minor tweaks to CarrierService:
* Remove some unnecessary @hide
* Remove final qualifier from onBind() so that subclasses can handle
new internal callers that want to bind to it.
ADDITIONAL CHANGES:
- Fixes stack so that a SecurityException is thrown when caller
does not have MODIFY_PHONE_STATE or carrier privileges.
Bug: 21572049
Bug: 21630803
Bug: 21721768
Change-Id: Ie952651d2f15c370de713ed8abb6d9f6f07dd2b4
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
Currently lock task modes started by the activity flag
android:lockTaskMode behave differently from those started using
startLockTask(). With those changes lock tasks initiated by non-priv
apps cannot finish without calling into stopLockTask. Revoking the
whitelisting on a locked task will also kill that task, independently
of the way the lock task mode was started.
Bug: 21608206
Change-Id: I841abf1103855e2d7218a4a8ca9b43c105630dc9
This reverts commit 0b3d573e46b8be0f0cf170802214320859c94905.
Unfortunately, we need more than just that.
Change-Id: I42ac79cb396812b91cec67ba681144592c0e2e01
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 86920fe630911cbbc0839b341dc694c2b905ef9e)
- 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
