The carrier's vvm app's package name will be checked so that if it is
already installed, the dialer vvm will be disabled.
Bug: 2112648e#
Change-Id: I0433037f3bc5c5a380c76a03090d61c430e47e4b
We modify the XML of layouts and AndroidManifest enough
that it warrants we operate on the tree in memory.
These files are never very large so this should be fine.
Change-Id: I5d597abdb3fca2a203cf7c0b40fcd926aecb3137
Creating the thumbnail of the header for the transition was on the
critical path for starting the activity. This moves it off this path
by doing it after onPause().
Change-Id: Ic54a104d5ad4c40e88638566a3a69cc265a0a0fe
Because we created a bunch of layers, this delayed calling start
activity in the window manager. Disable these layers, as they are
not really needed.
Change-Id: I59343a92726665f72215a0699c52ead76e78a4b3
- Precache the bitmap for the window animation in the preload phase
- Remove some post's so we have a faster path from UP -> startActivity
- Don't dim the headers in the first frame drawn, because layer
creation is slow. Instead, do it in the second frame, when the window
animation is already running.
All these changes combined make going to recents about 40-50ms faster.
Change-Id: I3e4060af1ac57b3f359fe7f86f9e3814c6490323
Prebuilts open their libraries directly from apk.
Because of that abi detection is no longer as
special as it was before.
Bug: 20810492
Bug: 8076853
Change-Id: Icbd39d6062f3c1fcad2038e712b98fbdd9aa2196
Bug: 18052916
Tweaked colors, merged some categories
Reduced significance of fast frames
Increased visual weight of janky frames
Change-Id: I5b4e86164c4d51debad7de0e0f8715dda34c7a60
In order to prevent this bug from happening, we must allow vold cryptfs
commands to complete while a long running mount is underway.
While waiting for vold to be changed to a binder interface, we will simply
create two listeners, one for cryptfs and one for everything else.
Bug: 19197175
Change-Id: I8c40211dc1ef5ecec765ab587f093e757f1173d3
Changes to the AlarmClock intent API based on feedback from Alarm team:
1. s/VOICE_CANCEL_ALARM/DISMISS_ALARM/g - "Cancel" is a bit unclear, so we're
changing it to "dismiss". Also, remove "VOICE_" since we should also add
support for this in multi-modal.
2. Removed DELETE_ALARM - we will likely not complete this for Android M.
3. Removed ALARM_SEARCH_MODE_NONE = "none". Instead, if
EXTRA_ALARM_SEARCH_MODE is missing (and alarm data URI is not given), then:
* If exactly one active alarm exists, it is dismissed.
* If more than one active alarm exists, the user is prompted to choose
the alarm to dismiss.
4. Add ALARM_SEARCH_MODE_LABEL, which allows searching for alarms by a
(partially) matching label.
5. Add SNOOZE_ALARM for snoozing an alarm, with optional
extra EXTRA_ALARM_SNOOZE_DURATION.
Change-Id: I39502532e54d5f0fe51a8545a4c586615f5e5e89
Add 360dpi as a supported screen density to closer match some
hardware's physical specifications. This gives a dp multiplier of
2.25.
Bug 19529059
Change-Id: Ibf9c768fba53765ea684ff228d24caf091f27a3e
Don't refresh the state if its not different.
(This way setAllowAnimation won't get called when it shouldn't)
Bug: 21335624
Change-Id: Id6f8961b32d12141db5ac0bb847e4751b8a159b8
This CL was a can of worms. More extensive changes are
needed to decouple AdapterView state from measure/layout
passes.
This reverts commit abed07f6c0186e16e1c8e8aaceaf8cf961695c66.
Change-Id: I4e4e01692a1f660a04e9dfd16db882f13c3d0b94
If provided the extra entropy will be added to the device before calling
finish. If entropy is provided and the device does not support supplying
additional entropy then finish will fail with KM_ERROR_UNIMPLEMENTED.
(cherry-picked from commit 9ce30624a448f439e19960d0dd88103c04676e7d)
Change-Id: If26be118bf382604f6f8e96e833b76e6f9e94d58
Keep a reference on active Ringtones to avoid garbage collection
before playback is complete.
Bug: 11366759.
Change-Id: Icb04da427c20e0b4657e9e8b13b3ecab98e5a333
Previously going to the full shade and expanding notifications
where disabled when QS was expanded even though there was enough
space to allow it. This is now allowed again in order to have
a consistent experience.
Bug: 19712809
Change-Id: Ie756d9c3fbf9dc2e60a05d02f0f4cc5dd6c7ebe0
Now the preview clipper animation and our own circle drawing
are in sync again when launching an affordance!
Bug: 21440634
Change-Id: I96cda04926fb9ae62db6690ddebaf73df38e9ca9
When a notification came in dreamMode and would become a HUN
we were firing its fullscreen intent imediatelly. If that notification
got updated again a moment later, it would also show an additional
HUN even though we just launched the fullscreen intent. This is very
troublesome to handle on the app level, as the notification state
is the same. We are now introducing a cooldown for HUNs when it just
launched a fullscreen intent.
Bug: 19377091
Change-Id: Ib32341c8983f0e977354432ea8d8e98909a13829
It is possible for deadlocks to occur when sending/processing
PendingIntents due to components like AMS holding global service
locks when dispatching the broadcast without specifying an
handler and the receiver calling back into AMS.
We now set a default handler to process the broadcast on if we
are in the system process and a handler wasn't specified.
Bug: 19502993
Change-Id: Iccde32c6c1df997784155bc41ef39e52ee0f7243
This patch consists of two broad changes :
- don't "force" dex2oat when installing a new app. this should never
be necessary because we will always compare checksums.
- when staging a new install, we "inherit" (hard link) all compiled
oat files from the previous install. this will ensure that we compile
only those files that have changed, and not all of them
bug: 20889739
Change-Id: I3e14335f3bcfe76d1d24d233f53a728a6d90e8a1
Contrary to the expectations of the code, IoUtils.closeQuietly()
does not unblock system calls. So mReceiveThread.halt() was not
actually stopping the receive thread.
This wasn't actually a problem, because after "stopping" the
receive thread, either the interface would go down (interrupting
the previous receive thread with ENETDOWN), or a packet would
arrive to both the old and new receive threads, stopping the
old one. But the lack of a "stopping receive thread" message at
the expected time was confusing.
While I'm at it, also add the string for CMD_TIMEOUT.
Bug: 19704592
Change-Id: I74732429118af780453028898148519b294fa9d3
It turns out that IMMS#SettingsObserver has monitored
only main user's the secure settings. As a result, when the
secondary user changes enabled IMEs in the settigs app,
IMMS only updates internal enabled IME lists only when
the user is switched for secondary users. If a secondary
user enables or disables IMEs at the settings app, such
changes are not correctly notified to IMMS.
This CL addresses above inconsistency by explicitly
specifying the user ID when calling
ContentResolver#registerContentObserver().
This CL also allows dumpsys to contain internal state of
IMMS#mSettingsObserver in case we need to diagnose
problems only with bugreports.
Bug: 19340792
Bug: 19587437
Bug: 21612582
Change-Id: I34b437928c147e9fdbe935f725624cc97c816cb3