Userspace may want to load a different firmware than the one that the
kernel requests in some cases, therefore this change adds the ability
to ueventd to run an external handler that will determine the name of
the file that should actually be loaded.
Bug: 138352500
Test: unit tests
Change-Id: Ic5da37268fd78109f83ae52d1b903bf7322a5ee5
The accidental trailing ':' appears to stop the line
triggering.
Bug: 137267623
Test: Checked the /system/bin/boringssl_self_test32
now runs on aosp_cf_x86_phone-userdebug
Change-Id: I7b4b1d6b838d8d1a7a0db7f104a94b34962df030
Make sure system heap is present on devices, its id is '0',
and that we can allocate and free buffers from the system heap
Bug: 140507100
Fixes: 140507100
Tests: ion-unit-tests --gtest_fiter=SystemHeap.*
Change-Id: Ief502c9fce1e54f54b4e6d60f288954e4bf42e04
Signed-off-by: Sandeep Patil <sspatil@google.com>
Previously, the device path for the -inner device is used, which
may not be present. Use the major:minor instead.
Test: libsnapshot (not flaky)
Change-Id: I8b8cbe8af27a49a50876385bb0c0353ecf7ed1de
This makes it easier to add or remove the Trusty keymaster service from
a device by providing a manifest fragment to add whenever it is enabled.
Test: Keymaster VTS, Keystore CTS (sans attestation)
Change-Id: Ib0f5fd7c016c0c18d77c9d2623c89f3b35ba7ad7
The reference keymaster at system/keymaster still expects to receive its
auth tokens in the tags, rather than as a separate parameter. This
change injects the separate parameter passed to the KM4 HAL as a legacy
tag in the request.
Longer term, system/keymaster should support a separate authToken
parameter, and it should be serialized and sent to Trusty separately.
Test: Keymaster VTS + Keystore CTS (sans attestation)
Change-Id: Ie69cbd358504bb7612f7d55158509043cdad4e4e
Allow canceling an update if the update has been applied
but not rebooted into it.
Test: libsnapshot_test
Change-Id: I694d74e200908ec622855074ab811e3029328f43
* warning: overloaded 'operator{++,--}' returns a reference instead of a constant object type [cert-dcl21-cpp]
Change-Id: I8a904622b30dc70d17483b87748c2ea541e50c46
5aa6197d5f added the ability to
parallelize restorecon to speed up boot for devices that have not
completely moved to genfscon. This parallel restorecon happens after
the parallel ueventd handling.
This causes a performance regression for devices that have moved to
genfscon, since previously, the restorecon() was done in the main
ueventd thread in parallel with the uevent handlers.
I also tried to run the fully parallelized restorecon in parallel with
the uevent handlers, but that did not make any change to the cold boot
time, likely due to the additional overhead of parallelizing the work.
Bug: 140458170
Test: blueline coldboot time returns to pre-regression time.
Change-Id: I3cd6a869cc9b62792466813d94ad6c69834e854e
vold is already started during early-fs which happens before
post-fs-data.
Trying to start it again in post-fs-data is a little bit confusing.
Test: device boots
Change-Id: I5faefe6d1f1bb7472ea3d032b1f157c69da565f1
Linux doesn't seem to actually support emitting them, so we can't check
that they're actually there, but commit the code to read them so that
if and when Linux gets support, it's easier to check.
This also adds some error checking for ill-formed binary object store
entries.
Test: check_ms_os_desc
Change-Id: I4baf6a16f0f96acbec468b843db65d4ab3a589fe
When we run MapPartitionWithSnapshot, intermediate devices aren't
cleaned up if the call fails. Hence, record these intermediate devices
we have created along the way using the new AutoDevices class. Upon
failure, the AutoDevices object will be destroyed, and all the
intermediate devices will be deleted from device mapper or image
manager. Upon success, AutoDevices::Release() makes sure the
intermediate devices aren't deleted.
Test: libsnapshot_test
Change-Id: Iff4c1297528288a27765c0224b67254b68c89776
Create / Deleting the COW image / snapshot changes states, so it makes
sense to require an exclusive lock before doing so. If caller doesn't hold
an exclusive lock, parallel calls to MapCowImage / MapSnapshot / UnmapCowImage /
UnmapSnapshot may have weird results.
Test: libsnapshot_test
Change-Id: I4be660df1059ec24144f8baf43a1c8c05d9e372b
Move operations on image manager in *Snapshot functions to their own
functions for finer granularity in control. *Snapshot functions only
changes snapshot state and snapshot devices, but not the supporting
devices.
Now, MapSnapshot can take a customized COW device path. We will have
a more complicated stack for the COW device in upcomming CLs.
Also, Change SnapshotManager::CreateSnapshot's signature to
accept a SnapshotStatus struct that includes all sizes, so that
cow_partition_size and cow_file_size can also be written to the snapshot
status file.
Test: libsnapshot_test
Change-Id: I388ecd4bcfbfcc3f379ecb6993615234f4fbcb4e
The installed file name of modules may not match the module name.
Use module-installed-files to get the installed file name.
Bug: 117607748
Test: m checkbuild
Test: only libprotobuf-cpp-*-3.9.1.so changed in ld.config.R.txt
Change-Id: I83b7519f344b65b6cd98c4cabcf9bce0e753ba92
Merged-In: I83b7519f344b65b6cd98c4cabcf9bce0e753ba92
Protobuf 3.9.1 redefines google::protobuf::int64 from long long to
int64_t, which is sometimes long and sometimes long long. Use PRId64
to print it.
Bug: 117607748
Test: m checkbuild
Change-Id: I6699cfdb0f0424aa3e1c98b59d941beb9f133055
Merged-In: I6699cfdb0f0424aa3e1c98b59d941beb9f133055
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command. This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.
This change has init run property service in a thread, which
eliminates the above issue.
This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.
Reland: during reboot, init stops processing property_changed messages
from property service, since it will not act on these anyway. This
had an unexpected effect of causing future property_set calls to block
indefinitely, since the buffer between init and property_service was
filling up and the send() call from property_service would then
block. This change has init tell property_service to stop sending it
property_changed messages once reboot begins.
Test: CF boots, walleye boots, properties are set appropriately
Change-Id: I26902708e8be788caa6dbcf4b6d2968d90962785
