Specifically, --ei (int extras) and --eia (int[] extras) now
use Integer.decode(), which means they accept negative
integers, base-16 integers formatted as #NNN and 0xNNN, and
base-8 integers formatted as 0NNN.
Additionally, --ez (boolean extras) can now be specified as
"true", "false", "t", "f", or an integer (any nonzero
treated as true). The previous behavior, based on
Boolean.valueOf(), would silently assign false if you
managed to get the spelling of "true" wrong.
Change-Id: I058254e907308006d403b5b7866c86bcaa03d8d3
Use LOCAL_WHOLE_STATIC_LIBRARIES to instruct static linker
to export symbols from the static library.
Change-Id: I465806dcffc777a682523f74ae6f7ab61aaa6962
Also export necessary symbols to preempt calls from
libart.so
Bug: 15345057
Bug: 15426766
(cherry picked from commit 96e0cfa721925550b1cc39cdfd6084a878e6ffe2)
Change-Id: I0930d96edde7dc0636e8d50d7c778f099237f748
- 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
The bootanimation daemon will play 16 bit WAV files contained in bootanimation.zip
For this to work, the bootanimation.zip must contain an audio_conf.txt file,
which contains parameters to be used for the tinyalsa pcm_open call
as well as mixer parameters to set before attempting to play the sound.
If the bootanimation finds an audio_conf.txt file, then it will look for a file named
"audio.wav" in each of the part subdirectories. If audio.wav is found, it will play that
WAV file starting at the beginning of that part.
The code for this is based on the tinyplay utility in tinyalsa.
The audio_conf.txt and must begin with the following header:
card=<ALSA card number>
device=<ALSA device number>
period_size=<period size>
period_count=<period count>
This header is followed by zero or more mixer settings, each with the format:
mixer "<name>" = <value list>
Since mixer names can contain spaces, the name must be enclosed in double quotes.
The values in the value list can be integers, booleans (represented by 0 or 1)
or strings for enum values.
Finally I should mention that this change is not the right approach.
Instead of going straight to ALSA we should be using the mediaserver instead.
But mediaserver isn't ready in time due to interactions with the system server, and there
isn't time to fix this for the current release. We need to fix that for the next one.
Bug: 17674304
Change-Id: Ic391ade61c941d0a24f4d64fe005ac9375a23fa9
Some OEMs want to have a bootanimation (or parts of it) displayed on a
color other than black. They currently just use full-screen frames for
that, which wastes lots of memory and bandwidth. This change allows
each part of the animation to specify a background color that will be
applied outside of the frame images; if unspecified the background
will be black as it is now.
Bug: 16635599
Change-Id: Ibf008fc75c5aad891c86ba9e4ec0879b7a61b8bd
Added 'Success' at the beginning of the command output every time
it didn't fail, so that we can easily check the output in tests.
The command is brand new, only used by us on CTS tests, so this
shouldn't break anybody.
Bug: 17312478
Change-Id: Ie67bf5b2f44e658e7009e5bd87f8cb81be515584
...give time in some cases
This switch to multiple stacks broke the check to determine if it
should actually wait for a new activity to be shown. The new check
now also requires that the top activity be resumed, which means
we may get some false positives where we decide to wait and shouldn't,
but that is better than consistently not deciding to wait in some
cases when we should. (And we will always finish waiting then next
time something becomes visible).
Also add another time, which is how long it took from the startActivity
call to return with the result. And fix when we decide to report that
we are done so that, in the case where we are bringing an existing
activity to the foreground, we don't wait until its animation is complete.
Change-Id: Id38ca0070f04e7bf8c73e131fb055808553a0e2f
Required for GTS tests. Needed to relax the restriction that
only root user can run 'pm create-user' as GTS tests can't
get root permissions.
Bug: 17312478
Change-Id: I1841286ddf51756c73018c087a5f29afeb5b9f15
poll() returns immediately; we want to take() to wait for the result
to actually arrive.
Bug: 17510699
Change-Id: I87669e79e9941480fed33e4cc8a38de793d59e90
