On modern versions of Android running in AOT mode
FloatMath is slower than Math. Calls to Math.sqrt(),
etc. are replaced by intrinsics which can be as small
as a single CPU opcode.
When running in interpreted mode the new
implementation is unfortunately slower, but I'm
judging this acceptable and likely to be improved
over time. This change saves a small amount of native
code.
Example timings:
Mako AOSP AOT:
Method: Original / New / Direct call to Math
ceil: 596ns / 146.ns / 111ns
sqrt: 694ns / 56ns / 25ns
Mako AOSP interpreted:
Method: Original / New / Direct call to Math
ceil: 1900ns / 2307ns / 1485ns
sqrt: 1998ns / 2603ns / 1788ns
Other calls Mako AOT:
Method: Original / New
cos: 635ns / 270ns
exp: 566ns / 324ns
floor: 604ns / 150ns
hypot: 631ns / 232ns
pow: 936ns / 643ns
sin: 641ns / 299ns
The advice to use Math directly, in preference to
FloatMath, is still good. FloatMath will be deprecated
separately.
Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: I8d1947d88b3c576643138b1df589fb9da7c1ab88
We used to set this from LoadedApk.getClassLoader. This had
the unfortunate side effect of clobbering the threads default
classloader when Context.createPackageContext().getClassLoader()
was called. This happens, for example, to every app that uses
a updatable webview.
bug: 17986934
Change-Id: If2b5938a19f836ea5fe60c94ea53a7125c2098c0
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
Requests coming in while the service is still being brought up
were discarded. Changed to queue them so that they can be started
after the initialization is completed.
Bug: 17985588
Change-Id: Ic9d9cd2094b830c80dec54dd5ef6a18159a74dc7
Conflicts:
services/core/java/com/android/server/hdmi/HdmiCecLocalDevicePlayback.java
It is possible that the device does not have an owner. If there
is no owner we get a NPE when asking the device policy manager
for cross-profile widget providers.
bug:17989189
Change-Id: I5759f2dec160ed8076ab47fdf09134f78c57458d
This is a squashed commit of the following changes:
1. Order apps by priority when performing boot dexopt.
(cherry picked from commit 65cde7d42d741c7d9aa2714a397b7333f688ab55)
2. Improve priority ordering of apps when performing boot dexopt.
Added core apps and updated system apps.
(cherry picked from commit 272bf3a274daff62995caf05da338c1f2a73dae3)
3. Stop boot dexopt when low on memory.
(cherry picked from commit 1d892dcb6b0ff3a50cc63e387667dc29baf1014f)
Bug: 17641843
Change-Id: Ie32f1c21047d3462aaf728f7633fecf647ba2b47
When saving to PDF we bring up the file picker UI which covers
the print UI. In this case the printing app may get killed as
it is not in the forground (the system is bound to the print
spooler so it cannot get killed). If that happens we are ending
up with an empty file. However, if the file chooser UI is up
we already have everything from the app we need and it dying
does not matter. This change takes care if ignoring printing
app death while saving to PDF.
bug:17922948
Change-Id: I10d808e3c3e93e850dbc2a948f2482381a887928
...handler for its Intents
Fix bug when a third party app is installed as an additional but
worse match for the intent.
Also raise up the limit for when we start printing logs about
overly large strict mode data.
And turn off the logs about services being created and destroyed,
since with the way things are using services these days these have
become way too spammy.
Change-Id: I8fe301dfd80fb4b70213cb7783b7c5426245278d
