When decrypting a device, a tmpfs is temporarily mounted as /data,
the size of which is usually small. When the zygote, system server
and necessary apps are brought up, they will be compiled into the
tmpfs.
If the system image contains prebuilts, they will be relocated instead
of compiled. This is unnecessary. In this special situation it is
acceptable to run out of the prebuilt oat files without relocation,
which can save space in the tmpfs.
This patch ensures that the boot image is not being relocated.
Change-Id: I42bfb7e3039574b7e4f2772e0d395f093d59ed1b
Signed-off-by: Hyangseok Chae <neo.chae@lge.com>
Let AndroidRuntime check for /system/etc/compiled-classes and push
it to the runtime for boot image creation.
Bug: 18410571
(cherry picked from commit ca775941f3b7981aabf3a6a3b84d6c94f4f76aff)
Change-Id: I2510316381f2661166af24d7e14b013f4e045556
Let AndroidRuntime check for /system/etc/compiled-classes and push
it to the runtime for boot image creation.
Bug: 18410571
Change-Id: I2510316381f2661166af24d7e14b013f4e045556
Change AndroidRuntime::startVM to give the new standalone
preloaded-classes file to the runtime for compilation of images.
Bug: 18305157
(cherry picked from commit 995c62d6abd4b7080e52a60d1bffa32ae4a798a3)
Change-Id: I32a13357893222b25fbce60bf2367c23fb36ab22
Change AndroidRuntime::startVM to give the new standalone
preloaded-classes file to the runtime for compilation of images.
Bug: 18305157
Change-Id: I32a13357893222b25fbce60bf2367c23fb36ab22
Turn on -Wall -Werror in core/jni. Fix warnings.
Clang TODO: For GCC we need to turn off Wunused-but-set-variable in
the GL bindings. However, Clang doesn't have that warning and thus
complains about an unknown pragma. It is necessary to make the
pragma #ifdef-ed on the compiler being GCC.
Change-Id: I14cab48d45c2771eef0432082356c47ed44a3d7f
This patch changes the profiler system property
"dalvik.vm.profile.max-stack-depth" to "dalvik.vm.profile.stack-depth"
so that the length of the option is less than PROP_NAME_MAX.
Bug: 17294224
(cherry picked from commit 4d033e1c44c1b94ea5311713b8cc8bfb56bdcdd2)
Change-Id: I10dd0b3bfa46b836def437a3822f6c48538167dd
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: If07fcbd78543d13bc6d75f9743f999860e8d58d7
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
When Android processes fork from Zygote, we rewrite the command line
with a new name, eg. "system_server". When we do this, we should
fill the entire block with zeros to remove corrupted argument
information that may otherwise remain in the /proc/<pid>/cmdline buffer
and be seen in tools and stack dumps.
Fixed an issue where VM options could be overwritten after setting
the nice name if the name was too long.
Bug: 17474152
Change-Id: Ie6cf9ed7752a04300a340e26cd6812bb35c59e1b
A user may request a subset of the document's pages to be printed.
In this case the expectation is that the resulting document does
not include not selected pages. While print serivices can do the
trimming themselves or the printer may do so, moving, potantually
many, redundant pages is inefficient. The real problem is when
saving to a PDF file where the saved file must not have the pages
the user did not select. This change adds shredding of undesired
pages from the PDF before saving it or passing it to a print service.
:
bug:17285994
Change-Id: I7deba535af99457bea3c118202314f0f3812e809
This patch changes the profiler system property
"dalvik.vm.profile.max-stack-depth" to "dalvik.vm.profile.stack-depth"
so that the length of the option is less than PROP_NAME_MAX.
Bug: 17294224
Change-Id: I5723883d7fa38dd5eaa276182e5d680d152cedad
ro.dalvik.vm.native.bridge is expected to be always be set. A value of
"0" means that the native bridge is disabled and that no value should be
passed to the runtime.
Bug: 17104449
(cherry picked from commit 831bd75b2bbc126f02578a967e925271b9cac6d3)
Change-Id: Ib483ac8e96bdc66af2725815807d4deb36fb36ab
ro.dalvik.vm.native.bridge is expected to be always be set. A value of
"0" means that the native bridge is disabled and that no value should be
passed to the runtime.
Bug: 17104449
Change-Id: I94e60c68e732abdab18f14f960d3b80f32048a79
We set the system_server classpath in the environment
(like we do with BOOTCLASSPATH). After the zygote forks
the system_server, we dexopt the classpath (if needed)
and then launch the system server with the correct
PathClassLoader. This needed several small / medium
refactorings :
- The logic for connecting to installd is now in a separate
class and belongs in the system_server.
- SystemService / SystemServiceManager have now moved to
classes.jar. They are only used from there, and since they
use Class.forName, we want them to be loaded by the
system_server classloader, and not the bootclassloader.
- BootReceiver now moves to frameworks.jar, because it is
used by ActivityThread and friends.
bug: 16555230
Change-Id: Ic84f0b2baf611eeedff6d123cb7191bb0259e600
