In KeySetManagerService, use ArraySet more explicitly. Avoid for-each
loops.
Collections API methods on ArraySet are not very efficient. Iterators
incur two object allocations: a helper and the actual iterator object.
During boot, about 4.5K such calls are made. Using the ArraySet more
explicitly like an ArrayList/array avoids the overhead.
Bug: 19617481
Change-Id: I25df334fa1d4be3210667fb1404e3c43f2585049
Symptom:
Report broadcast ANR on a dead process.
Detail and sample:
http://code.google.com/p/android/issues/detail?id=158329
Root cause:
app.curReceiver can only remember the last running.
If an application is both receiving FG and BG broadcast,
only one of queue can discard, the remain one will still
count as timeout.
Solution:
Select the skip-tartget-receiver by comparing the skipping app
to the first record of mOrderedBroadcasts of each broadcast queues.
Change-Id: Ic68d56f21b417a34f2d30d64ecfbed09c5e1764d
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
The current SELinuxPolicyInstallReceiver logic can yield a partial
or mixed (old and new) set of policy files under /data/security/current
if there is an error or a crash at certain points before completing
the installation of the update.
Rewrite the logic to avoid the possibility of such partial or mixed
policy updates by using rename on the entire directory of policy
files rather than operating on a per-file basis. Also separate
the extraction of the policy files from the bundle into their own
temporary directory. Make sure we delete any previous temporary directory
or backup directory before using them for this update. Drop the
use of a symlink for /data/security/current altogether; it provides
no benefit.
Change-Id: I564af01c2c3ca1531c216013b8724c7511f32de8
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
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
This change refactors ScreenMagnifier to use resources for its triple-tap
adjustment and scale threshold values. New values more appropriate for
wearable form factors are supplied. This also fixes a bug in the triple-
tap detection logic where the incorrect ViewConfiguration value for the
tap threshold was used, prematurely disqualifying some touch events as
potential taps.
Change-Id: If47e556aadb5beb1bad24644122560c6fbe33bad
A security leak was discovered whereby a malicious app could get the
IActivityContainer object from one app and use it to inject events
into another app. This fix removes the availability of the
IActivityContainer and replaces its one use with a method for
returning the information the IActivityContainer was used for.
Fixes bug 19394591.
Change-Id: Ib3cec25b25130cd8e098892c057742cfd575cfdd
AM would set the exiting app to be invisible twice by calling
setAppVisibility(). If the screen is turned off during these calls,
the window surfaces of this exiting app won't be destroyed.
The flow:
1. Screen is on
2. App A is finished
3. AM calls setAppVisibility() token=App A, visible=false
4. WM sets a dummy animation to App A
5. WM marks App A's wtoken.inPendingTransaction=true
6. Screen is turned off
7. AM calls setAppVisibility() token=App A, visible=false
8. WM calls setTokenVisibilityLocked() directly (screen is off)
9. WM sends app visibility to App A's client (ViewRootImpl)
10. WM clears the dummy animation from App A
11. App A's client calls WMS.relayoutWindow() to be not visible
12. WM sets App A's window mExiting=true but not destroy its surface
13. App A's window surface leaks...
Note:
a. The call in 3. is from ActivityStack.finishActivityLocked
b. The call in 7. is from ActivityStack.resumeTopActivityInnerLocked
c. In 10., App A won't get the real animation while screen is off
d. In 12., App A's inPendingTransaction=true; WM takes it's animating
e. mExiting won't be cleared because App A has no animation to
trigger WindowStateAnimator.finishExit()
After applying this patch, WM would destroy the surface in 12. of the
above flow.
Change-Id: I18b79ba96695ec80d57a85dc15cf92a9e7d3a6ef
This has been disallowed by the SELinux for several years now,
so can safely be removed. Given that saveLocaleLocked is
simplified quite a bit, we can now inline into its only caller.
bug: 18910417
Change-Id: I18251f77e4a25a0e7ecda8e85a9b3fcdc2dc7b05
The magnification viewport expects its boundary to be a rectangular region,
and always draws it as such. This change causes the indicator to draw as a
circle on devices with circular displays. This also refactors the width of
the indicator's frame to use a proper dimension resource and updates the
width to 4dip.
Bug:18242438
Change-Id: I1d86647b6d1ef84f5dd506f4141223ec050a79b5
Addresses a couple of TODOs now that all usages have been
removed and fixes a doc that specifies how the emulator locale
can be set.
bug: 17691569
Change-Id: I802ea1e12448a5442840cad1fdc0956d3e2c7a8c
