When I previously tried this in https://r.android.com/1108553 , it broke on
some targets but I think that may have been fixed. I'm trying it again now
to see if this now passes treehugger and sticks.
Note: There is still an indirect dependency via libfs_mgr.
Bug: 137267623
Test: Treehugger
Change-Id: I2d8b909e451bb64a1eb0719a145dfd74da1dcbad
Before we just got "Failed to read key". After:
adb E 10-07 08:20:14 258249 258249 auth.cpp:176] Failed to read key \
from '/usr/local/google/home/enh/.android/adbkey'
94390117965240:error:0900006e:PEM routines:OPENSSL_internal:NO_START_LINE:\
external/boringssl/src/crypto/pem/pem_lib.c:622:Expecting: ANY PRIVATE KEY
Also fix the misleading "Failed to generate" message from adb_auth_init.
Bug: http://b/141715453
Test: manually corrupted key; see above
Change-Id: I6732ee6b683c8548d596d7c22eeddab8ce9a3cea
As generic ld.config.txt will be covered with linker config generator,
ld.config.txt with previous vndk build is no longer required. This
change removes this part so there will be no unnecessary build step for
multiple vndk version build. Also vndk snapshot will have vndkcore and
vndkprivate files with version number, update_and_install_ld_config.mk
has been updated temporary for vndk_lite build.
Bug: 142072719
Test: m -j passed with aosp_arm64 build
Change-Id: Ia7529c80b179dc262c6e7646a34c2a05a0d9be84
Last generic ld.config.txt deprecation caused build error from
build_test build because of invalid ld.config.txt build target. To fix
this ld.config.txt build target should be enabled until
ld.config.vndklite.txt and ld.config.legacy.txt also become deprecated.
Bug: 138920271
Test: m ld.config.txt passed
Test: build_test passed
Change-Id: I7f45ee66d3ed70a1a698261e1e801a30729f592f
libneuralnetworks.so could be preloaded. In that case, it should be
accessible from libnativeloader which runs in the runtime namespace.
Bug: 141847343
Bug: 142111172
Test: m, marlin/sailfish boots
Change-Id: I5b2f3073d0711d6049b4e1e1bd0bcc403949fe14
* changes:
Update ion_4.19.h with heap IDs
Add a test to invoke ion_is_using_modular_heaps()
Add libion API to check if modular heaps are being used
create ion_4.19.h
We disabled then re-enabled a set of tests believing that they were
stable; they were not, so we disable them again while we investigate
their stability.
A majority of tests filter the logs from logd based on pid, so running
in isolation helps them not see unexpected information from other test
runs.
Bug: 138876729
Bug: 142041379
Test: run via gtest with gtest_repeat=10 without failure
Test: run via atest 5x times without failure
Test: observe that isolated applies to both gtest and atest
Change-Id: I757d52dd3233323be9519625868b2fd2aaa41aeb
system/core/libion/original-kernel-headers/linux/ion_4.19.h was
edited manually and the following command was run to generate
system/core/libion/ion_4.19.h
bionic/libc/kernel/tools/clean_header.py
-ksystem/core/libion/original-kernel-headers/linux ion_4.19.h
> system/core/libion/ion_4.19.h
Bug: 140916230
Test: make, ion-unit-tests
Change-Id: I6b66bed7e3b11c5b7e80bb0b937d620510f0e172
bug_map data is now included on user builds.
Bug: 141695494
Test: Generated a tracked denial on a user build and verified that the
bug number shows up in the logs.
Change-Id: If2afa861acece63573973fe42d504d1d41964a4f
This property will need to be reset during userspace reboot, so it can't
be a read-only property anymore.
Test: builds
Bug: 135984674
Change-Id: I4e079b537cb5c725ac0b652804fdc801a6facfcf
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This change moves the recovery resources to vendor in libcutils/fs_config.cpp
and removes the flash_recovery service from rootdir/init.rc. This service moved
to a vendor init.rc file in bootable/recovery/applypatch.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: I492f7989ea8042912e9d0e0eadeaa351affbee13
system/core/libion/original-kernel-headers/linux/ion_4.19.h was
created manually and the following command was run to generate
system/core/libion/ion_4.19.h
bionic/libc/kernel/tools/clean_header.py
-ksystem/core/libion/original-kernel-headers/linux ion_4.19.h
> system/core/libion/ion_4.19.h
Test: make
Bug: 140916230
Change-Id: I2cd8cda903e77374cf85f38fe16a4e82156d5c67
Also, add a "name" field to SnapshotStatus, and delete
the "name" arg from CreateSnapshot / WriteSnapshotStatus.
ReadSnapshotStatus will warn if the name mismatches from
the file name, and auto-correct it.
Test: libsnapshot_test
Change-Id: I725cf39c07684b100b140a8a21ea9d23ab9d2241
These tests are flaky, but we're not seeing what the failure strings
are.
Bug: 142041379
Test: force a failure and see the right error message
Change-Id: Icd7777e5c309cac3b98ce65925980965a3cc3753
This change fixes a bug that public libs from APEXes are never
pre-loaded. This was happening because those libs are removed by
InitDefaultPublicLibraries which was originaly designed for listing up
the libs that needs to be provided to the app namespace from the default
namespace. Since the libs from APEXes are not available from the default
namespace, but from their own namespaces (e.g."runtime", etc.), the
removal was fine. But the problem happend when the same function is
parameterized (with bool for_preload) and used to get the libs for
preloading.
This change fixes the problem by not removing the libs from APEXes when
the function is called with for_preload == true.
Bug: 141847343
Test: m
Change-Id: I9edf2f94bac473ac7d0651514a2dabe976f81058
The load bias value set in ReadProgramHeaders is out of sync with the
algorithm used in the static GetLoadBias function.
Sync the two and add tests to verify that they stay in sync.
Test: Unit tests pass.
Change-Id: I20ac0104970a22a92a5314a41dcadad0c9c22e64
