In vendor process, libvndksupport must look for "default" namespace,
instead of "sphal" namespace to open hal libraries.
Bug: 63411330
Test: Boot the device.
Change-Id: I26208b6f47708f83e0679fd72ca7471ade84fff9
Merged-In: I26208b6f47708f83e0679fd72ca7471ade84fff9
If no 'sphal' namespace exist, the sphal library may be found in
current namespace.
Change the log level and message to note this.
Bug: 64162324
Test: Check log message for vndksupport tag.
Change-Id: I5ed6ba1e48f99e7d11d80a465177ac9f3a7fbd97
Merged-In: I5ed6ba1e48f99e7d11d80a465177ac9f3a7fbd97
In order to replace qtaguid module with new eBPF network monitoring
module. We firstly move the current qtaguid userspace implementation
into netd and hide the detail from other processes. The current API will
talk to netd fwmark client to pass down the qtaguid related request from
high level framework and netd will use the proper method to complete the
request.
Test: Current TrafficStats CTS tests should not fail.
Bug: 30950746
Change-Id: Ie90c28f3594ab2877746b2372a1b6944768bfb18
Partners require to access update_engine's logs on the file system with
non-root permission.
Bug: 65568605
Test: directory created with the correct permission on boot
Change-Id: I1c1fb4acb8b0f2e7352ffa9e7d05a864940b5986
The qtaguid kernel module will be deprecated on devices running 4.9
kernel or above and we need to support both old and new module in
userspace. Netd is responsible for choosing which kernel module to use
and all the current qtaguid native implementation need to be hided
behind it. So the current qtaguid native API implementation will be
moved to a isolate library under system/core and only netd can access to
it. The libcutils qtaguid API will become a wrapper to send request to
netd module. This modification will make sure the apps that currently
using this native API will not be broken.
Bug: 30950746
Test: All cts and vts test related should not fail.
Change-Id: I9de98a25ed5dc71bbf520ee0aadd16d59025699a
This test actually belongs with the adb python wrapper, since it's not
affected by changes to adb itself.
Bug: http://b/64260633
Test: python test_device.py
Change-Id: I58e5dff760f35923f8dbbdc7de6ffd75254880dc
In this case, if the .eh_frame_hdr doesn't exist, we would crash.
Bug: 68813077
Test: Pass new unit tests, verified that without the fix, the unit test
Test: would crash.
Change-Id: I4f1365a76fe5c2fb69fa106a1ef15889c14e7611
Static executables only have a .eh_frame section and no .eh_frame_hdr
section. Add support for this by rearranging the class hierarchy and
creating a DwarfEhFrameWithHdr class and a DwarfEhFrame class to handle
the different cases.
Add new unit tests for DwarfEhFrame and for the new functionality.
Bug: 68820189
Test: Passes new unit tests, unwinds static executables.
Change-Id: I63d7cb8c52a686e96579a2266e18c0d06bbb6e63
We want repeatable builds for minimal OTAs.
(cherrypick of 2e93eda69cf20d9c04d56ea6bf1e2ea62ad62eb4.)
Bug: http://b/64634017
Bug: 64709603 (presubmit balking at the line above)
Test: repeated builds after `touch daemon/main.cpp` keep same md5sum
Change-Id: Iedeb44377ea45bbf20e2212760802198a57dc14a
Fix for buffer overrun when a tag that is too big is sent to logd.
Buffer supplied is precisely the right size for max message length
however strlen will be run on the buffer, so need to ensure null
terminator, otherwise any strlen will go off the end of the buffer.
Also converted LogBuffer::Log() over to use the safer strnlen in the
case where it is measuring the buffer (and converted over to using
__android_log_is_loggable_len())
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Test: liblog.android_log_buf_print__maxtag
Change-Id: I3cb8b25af55943fb0f4658657560eb2300f52961
If an entry is found in .eh_frame_hdr, but it's not properly in .eh_frame,
then the code would crash. The assumption that the header always points
to valid fde data is not guaranteed.
Bug: 68813077
Test: Passes new unit test that crashed before the change.
Change-Id: I914d9bda0d442cd232e2a056ae490301a8850105
The parent change ran into an issue where enabling UBSan on an i686
build caused it to use __mulodi4.
https://github.com/android-ndk/ndk/issues/184 documents linking against
libclang_rt.builtins-i686.a, but that's not available from soong either.
Bug: 62378620
Bug: 29412086
Test: x86 builds work again
Change-Id: I730d59558aa4ed28f8a11b5393e037111e320f29
