The system should always be using new startActivityAsCaller() when
starting activities on behalf of someone else, to ensure that
security checks are enforced as the original caller.
Bug: 17983737
Change-Id: Ic40816a797cfdb13c0adb48b86ed4ed7d6aae8eb
Inside ResolverActivity: when getting the ResolveInfo for EXTRA_INITIAL_INTENTS:
The ResolveInfo is created directly inside ResolverActivity, not by PackageManagerService.
So, noResourceId had not been set to true for this ResolveInfo.
So setting it inside ResolverActivity.
This is needed since inside a managed profile, the icons are not associated with resource ids.
BUG:17577733
Change-Id: Ic4f0439128f95482167103b783344e2baa0aed52
- Add docs to Binder, Messenger, ResultReceier to explain their
relation (or lack there-of) to process lifecycle.
- Clarify some aspects of process lifecycle for services.
- Fix help text of am command.
- Fix per-package dumping of battery stats to not include history.
- Fix per-package dumping of proc stats to only include aggregated
and current stats and fix some formatting.
- Fix per-process dumping of meminfo to have an option to interpret
the input as a package, so including all processes that are
running code of that package.
- Fix top-level per-package debug output to correctly include all
of these improvements and give them a little more time (10s) to
complete for timing out.
Change-Id: I2a04c0f862bd47b08329443d722345a13ad9b6e2
When performing a restore during initial device setup, we could be
installing hundreds of packages. Currently, we're writing all
metadata (including heavy icons) for every session mutation! Because
we're holding the mSessions lock while writing all this heavy data,
we end up causing ANRs when apps call other PackageInstaller APIs.
This patch mitigates by moving the heavy icon data into separate
per-session PNG files, which we only persist when changed.
Bug: 17881962, 17567794
Change-Id: I4dee15d4a65a8eb65c381e6bb7477728b6cc30d2
The motivation is an API change: FloatMath is going to be
deprecated and/or removed. Performance is not the goal of
this change.
That said...
Math is faster than FloatMath with AOT compilation.
While making the change, occurances of:
{Float}Math.sqrt(x * x + y * y) and
{Float}Math.sqrt({Float}Math.pow(x, 2) + {Float}Math.pow(y, 2))
have been replaced with:
{(float)} Math.hypot(x, y)
Right now there is no runtime intrinsic for hypot so is not faster
in all cases for AOT compilation:
Math.sqrt(x * x + y * y) is faster than Math.hypot(x, y) with
AOT, but all other combinations of FloatMath, use of pow() etc.
are slower than hypot().
hypot() has the advantage of being self documenting and
could be optimized in future. None of the behavior differences
around NaN and rounding appear to be important for the cases
looked at: they all assume results and arguments are in range
and usually the results are cast to float.
Different implementations measured on hammerhead / L:
AOT compiled:
[FloatMath.hypot(x, y)]
benchmark=Hypot_FloatMathHypot} 633.85 ns; σ=0.32 ns @ 3 trials
[FloatMath.sqrt(x*x + y*y)]
benchmark=Hypot_FloatMathSqrtMult} 684.17 ns; σ=4.83 ns @ 3 trials
[FloatMath.sqrt(FloatMath.pow(x, 2) + FloatMath.pow(y, 2))]
benchmark=Hypot_FloatMathSqrtPow} 1270.65 ns; σ=12.20 ns @ 6 trials
[(float) Math.hypot(x, y)]
benchmark=Hypot_MathHypot} 96.80 ns; σ=0.05 ns @ 3 trials
[(float) Math.sqrt(x*x + y*y)]
benchmark=Hypot_MathSqrtMult} 23.97 ns; σ=0.01 ns @ 3 trials
[(float) Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2))]
benchmark=Hypot_MathSqrtPow} 156.19 ns; σ=0.12 ns @ 3 trials
Interpreter:
benchmark=Hypot_FloatMathHypot} 1180.54 ns; σ=5.13 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtMult} 1121.05 ns; σ=3.80 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtPow} 3327.14 ns; σ=7.33 ns @ 3 trials
benchmark=Hypot_MathHypot} 856.57 ns; σ=1.41 ns @ 3 trials
benchmark=Hypot_MathSqrtMult} 1028.92 ns; σ=9.11 ns @ 3 trials
benchmark=Hypot_MathSqrtPow} 2539.47 ns; σ=24.44 ns @ 3 trials
Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: I06c91f682095e627cb547d60d936ef87941be692
When device is encrypted the user has to authenticate in order to decrypt
the data partition which is required for running accessibility services
and Text-To-Speech. In order to address this issue we are falling back
to use the default password if there is an enabled accessibility service
and the user has secure lock. This will enable the user to authenticate
when accessibility layer is completely functional.
bug:17671790
Change-Id: Iafffe7bcd234008cf91ffb5011b21b803dca227a
Revert back to (mostly) KK behavior, fix a problem where we were
collecting some data in an inconsistent state.
Change-Id: Ida3ca3fb734a9d7d61a90fd5044152e927c59e02
Remove the checks for large parcel sizes. Those were triggering,
and identifyng the area of the problem, but also cause a lot of
trouble by making the unsafe deadlocky code there much more likely
to deadlock.
Add logging for strict mode IPCs, since those seem to be the
problem. Only log when things look bad.
Also add a log when battery stats are reset, to diagnose why they
are getting reset when they shouldn't be.
Change-Id: I588c858fb8d8c45f3c9c164ae2de9ae01547b304
Add the app directory to the arguments for starting a process.
Add a check for NeedsNativeBridge and a call to PreInitializeBridge
in the native fork code.
(cherry picked from commit 2eacd06bfb)
Bug: 17671501
Change-Id: I970db5b284b0c12e2d8a45df3950c1fff2927a4e
..."uid 2000 does not have android.permission.UPDATE_DEVICE_STATS"
Make sure to clear calling identity before getting into the guts
of the activity manager. Also fix the places the activity manager
calls in to battery stats to not require a permission check, anyway.
Change-Id: Ifd90937875b9fe0c36aa3f5cf1ec173746914e6b
