Using a static Pattern in UriMatcher prevents compile-time
initialization.
It is also not efficient, as String.split has a fast path for simple
splits.
Bug: 19542228
Change-Id: Ie9e5bfe6da04c6d05ec10b1426d0cd136ef46ef2
Using a static Pattern in ActivityThread prevents compile-time
initialization of ActivityThread and GestureDetector, which depends
on the former.
It is also not efficient, as String.split has a fast path for simple
splits.
Bug: 19542228
Change-Id: I5bb843c08c81e0d259bb8afafa87a8467bb1730e
Add a simple ArraySet.removeAll(ArraySet) method. This avoids two
allocations, a MapCollections helper and an Iterator object, over
the removeAll(Collection) code.
KeySetManagerService heavily calls removeAll during boot (about 9K
times in AOSP). This reduces GC stress and optimizes the removal
(about half the time the removed collection has only one element).
The removal method in KeySetManagerService is also done under a lock,
so that it gates parallelization efforts in PackageManagerService.
Bug: 19498314
Change-Id: Ib0e483adfd09831cd66ab19a820ebf6544a2b66f
Problems arise if an activity is started in an ActivityView when the
parent activity is not resumed. In particular the ActivityView can
be brought to the front in front of other activities that have been
started by the parent.
This change checks the state of the parent when the ActivityView is
starting and if it is not resumed, throws an Exception.
This change also removes the queueing up of Intents if the surface
does not exist when startActivity is called. Now, the owner of the
ActivityView is notified when the surface becomes available. If
startActivity is called before that notification an Exception will be
thrown.
Fixes bug 19147472.
Change-Id: I6712cf1929fe65c4238ce7f3feb4e8511ed97244
Due to a bug caught late in the release, this API is broken
and should be removed from API 22 because it's too late for
a fix and there's no workaround.
Bug 19461292
Change-Id: Ib0757a4484b14afe7f83ae9527bb3f5f4834ee62
This adds the classes for creating and serializing arguments and results
from keymaster as well as the enum values from
hardware/libhardware/include/hardware/keymaster_defs.h which will be
needed for argument creation as well as converting keymaster error
codes into Java exceptions.
Change-Id: I61046756361d43d9f02eea370c2cbd07c3638ea3
This commit removes a couple of apostrophes from the word "UEvents" as
the apostrophes would only be needed if something that belongs to the
UEvent was being talked about. Instead, the UEvents are being talked
about themselves - as a bunch.
Change-Id: I6a7908c6b73c0739102b632d2499e0f1e3c2d47f
When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.
This patch is somewhat approximate but should be good enough for
most devices today.
Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock. There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing. However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).
Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.
Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
