Use proto for disk usage.
Bug: 79932027
Test: Ran through the following scenarios-
- RebootActivity parses previous boot parameters; sets next as expected.
- Push old parameters to device and ensured bootanimations reads it and
saves new format (serialized proto) that can be read in userspace
(RebootActivity).
- Unit tests pass.
Change-Id: I98aefb7a832c985d5061ee80ab85a4523f067641
* Update JSON blob that BootParameters reads from.
* Change JSON reader to allow custom keys.
Bug: 78524407
Test: Builds. Unit tests pass. End to end flow with RebootActivity
passes values as expected.
Change-Id: I2966f560de4aaf045125946c7fbe1becd47354be
Bug: 78577334
Test: Builds on master (aosp_x86-userdebug),
unit tests pass on oc-mr1 (on iot target).
Change-Id: I3584a285f1be914cc3e940469d7dea142d4a4231
We want to provide a sane default for the bootaction library name so
that the developer isn't required to mess with read-only properties to
get this working.
Also small cleanup to remove duplicate and unused libs from Android.mk.
Bug: 67644323
Test: builds (master)
Test: properly loads default lib (nyc-iot-dev)
Test: logs and exits when lib doesn't exist (nyc-iot-dev)
Change-Id: I865a45f43b3594c99419e7e27c9798ee944d0db2
Currently the boot parameters are tied pretty tightly to the bootaction
functionality, but volume and brightness need to be set on the
bootanimation regardless of whether there's a bootaction or not.
Extract boot parameters into a separate class to make it easier to apply
volume/brightness in a future CL.
Bug: 65462981
Test: Manual test, can succesfully read params on boot.
Change-Id: I32daad64cb8aab39fcd0ca17503218e0605ccd27
(cherry picked from commit f78561e7bbe580d0f0dbca7a615c575973ef6ce4)
We now provide some parameters that can be set on reboot and passed into
the bootaction library. This becomes part of the public libandroidthings
native API, so we need to use the public type.
Bug: 65462981
Test: `mma` builds successfully
Test: Test bootaction.so can receive boot params (tested on nyc-iot-dev)
Change-Id: Ibf6548730e0bac023f6a0a3aef925b0938418a10
Bug: http://b/65462981
Test: Parameters in next_boot.json are passed to
boot action; next_boot.json is moved to
last_boot.json to allow reading by
DeviceManagementService.
Change-Id: Ie290711ea48a3a221cfad2e9266215b76631ecbd
This is a multiproject change as we need to both the libraries
themselves as well as those that had dependencies on libskia.so
Bug: 31971097
Test: compile only
Change-Id: Ie6ff1f4682d03289205f4d6048cde9f95c61a90f
NOTE: this is only compiled into products with PRODUCT_IOT=true.
Introduce BootActions that a developer can provide to manipulate IO
before the android framework comes up on boot.
We will look for a configuration file at /oem/app/etc/boot_action.conf and
expect it to tell us the name of a shared library. We will then fetch
this library from /oem/app/lib/${arch}/ and load it. We expect it to export
boot_action_init(), boot_action_shutdown(), and optionally
boot_action_start_part(int partNumber, int playNumber).
We will then call boot_action_init() during boot after PeripheralManager
is up and call boot_action_shutdown() when the android framework is up
and we are going to start loading APKs.
We will also call boot_action_start_part(*) when each part of the boot
animation is started, use this if you want to synchronize the boot
action and the boot animation.
Boot actions run in a restricted environment and in general can only
make calls to PeripheralManager.
Bug: 37992717
Test: Pushed to local imx7d to test boot actions, pushed to bullhead test that animation+sound still works.
Change-Id: I9e53a17567f8028ea84486d637e1d231ee1125e1
We would like to reuse the animation parts of it in Android things.
This refactors the audio part into the _main and gets callbacks from
the BootAnimation class at interesting times. This will be the same
approach we take to integrate with it.
BUG: 37992717
Test: Built locally and pushed to a bullhead, works with sound.
Change-Id: I5eaca07c25eeb5edeab07d7ae7a29945e0e2cd37
- init will set sys.powerctl property and run bootanim.
- Use /oem/media/shutdownanimation.zip or
/system/media/shutdownanimation.zip for animation file.
If none of them exist, android animation will be used.
- Disable audio playing for shutdown animation.
- Disable TimeCheckThread for shutdown animation. It
accesses /data partition and can block umount.
bug: 36526187
Test: many reboots
Change-Id: If02c73cda2015317d88d056cd45201208da49946
audioplay is initialized with an example of the type of clip it
will play.
Also remove asserts and debug compile settings from BootAnimation.
BUG:24800792
Change-Id: Icb78489417aee0549c340c746b25e57ccdb3427e
Respects dnd settings for sound playback.
Basic implementation uses in-memory wavs as buffers.
audioplay::playClip should not be called before previous clip ends.
Updated FORMAT.md to reflect no more audio_conf.txt
Bug: 29055299
Change-Id: Ifc358d7c85f11b8b54ae6446c40643b87bc567f2
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
this is the first step in unifying surfacetexture and surface.
for this reason the header files were not moved, as most of them
will eventually go away.
NOTE: currently we keep libsurfaceflinger_client.so as an empty
library to workaround prebuilt binaries wrongly linking against
it.
Change-Id: I130f0de2428e8579033dc41394d093f4e1431a00
executables have calls to some shared libraries without explicitly linking
them. Currently it works as linker links these libraries via dependencies of
other libraries. This is fragile and not the right thing to do.
