Folks don't know how to add public native API. Point them in the right
direction.
Bug: 63905942
Test: boots
Change-Id: I5e1f04fb852348255a2f7f87aa961948c41c47fd
We have both system and vendor tests in the same directory
/data/nativetest. Since we can't distinguish system and vendor tests at
runtime, we choose to run all of them with the legacy namespace
configuration where /system/lib and /vendor/lib are both accessible
without any restriction. Furthermore, /system/lib/vndk-sp is added to
the list of accessible directories for tests since some libs (such as
libion.so) exist only in the directory but not in /system/lib.
This will change in the future when we install system and vendor tests
into different directories (vendor tests goes into ./vendor subdir).
Then, we will run the tests with [system] or [vendor] configurations
depending on their paths.
Bug: 63597267
Test: run bionic-unit-tests
Test: run linker-unit-tests
Change-Id: I810003b2da0b30335200c130f484ea7b041f9f80
Native tests under /data/nativetest[64] directory is now running with
the same linker namespace configuration as /system/bin/* processes.
This allows us to stop mimicing the linker namespace configuration of the
/system/bin/* processes using LD_LIBRARY_PATH.
Bug: 63597267
Test: run bionic-unit-tests
Test: run linker-unit-tests
Change-Id: If8e2ed0b8016e4e07bf6829735b8e02f952042d0
This commit removes libz.so from the exported libs of "vndk" linker
namespace and export libz.so from "default" linker namespace instead.
We have to remove libz.so from vndk-sp because we don't have a good
mechanism to stop "classloader" linker namespace from loading
/system/lib[64]/vndk-sp/libz.so. Other alternatives require significant
changes to dynamic linker or CTS test cases.
Let's temporarily revert the commit to fix b/62195853 for oc-dr1-dev.
The long-term solution will be discussed in b/37617391.
This reverts commit 63226400f3.
Bug: 62195853
Bug: 37617391
Test: Boot sailfish to home screen.
Change-Id: I4a97819b080f7091b633152d4a11353b24c463ee
This commit exports android.hidl.memory@1.0-impl.so from default linker
namespace to vndk (VNDK-SP) linker namespace. This fixes
libhidlmemory.so failure.
Note: Exposing android.hidl.memory@1.0-impl.so from default linker
namespace to vndk (VNDK-SP) linker namespace shall be fine because its
APIs are frozen and won't be changed in the future.
Note: android.hidl.memory@1.0-impl.so is NOT exported to sphal linker
namespace.
Bug: 35107583
Bug: 62778280
Test: Write a test SP-HAL lib which links libhidlmemory.so, load that
SP-HAL lib into system executable, and make sure mapMemory() works.
Test: sailfish boots w/o problems.
Merged-In: Ia36350dcf1f8c8dc6d7bf2c7a6ae65e0ebaef578
Merged-In: Iddb723558c3a814a905cd42797594a707bc651da
Change-Id: I69034595b2cd355e786ce7943fed7dddf1b12525
(cherry picked from commit bd7503dae7)
(cherry picked from commit 3251e582f2)
This commit exports android.hidl.memory@1.0-impl.so from default linker
namespace to vndk (VNDK-SP) linker namespace. This fixes
libhidlmemory.so failure.
Note: Exposing android.hidl.memory@1.0-impl.so from default linker
namespace to vndk (VNDK-SP) linker namespace shall be fine because its
APIs are frozen and won't be changed in the future.
Note: android.hidl.memory@1.0-impl.so is NOT exported to sphal linker
namespace.
Bug: 35107583
Bug: 62778280
Test: Write a test SP-HAL lib which links libhidlmemory.so, load that
SP-HAL lib into system executable, and make sure mapMemory() works.
Test: sailfish boots w/o problems.
Change-Id: Ia36350dcf1f8c8dc6d7bf2c7a6ae65e0ebaef578
This commit adds libhidlmemory.so and android.hidl.memory@1.0.so to the
exported libs of the `vndk` linker namespace (aka. VNDK-SP). This is
necessary because some vendors' GLES implementation uses
libhidlmemory.so. Check http://b/35107583#comment15 for the context.
Bug: 35107583
Test: sailfish boots
Merged-In: Idb5ba4ed4a89795e0e6105d55a84e7f6bbffff51
Change-Id: I1556b7499bd981af995f000519b7a314c70567d1
This commit adds libhidlmemory.so and android.hidl.memory@1.0.so to the
exported libs of the `vndk` linker namespace (aka. VNDK-SP). This is
necessary because some vendors' GLES implementation uses
libhidlmemory.so. Check http://b/35107583#comment15 for the context.
Bug: 35107583
Test: sailfish boots
Change-Id: Idb5ba4ed4a89795e0e6105d55a84e7f6bbffff51
This commit adds libhidlmemory.so and android.hidl.memory@1.0.so to the
exported libs of the `vndk` linker namespace (aka. VNDK-SP). This is
necessary because some vendors' GLES implementation uses
libhidlmemory.so. Check http://b/35107583#comment15 for the context.
Bug: 35107583
Test: sailfish boots
Merged-In: Idb5ba4ed4a89795e0e6105d55a84e7f6bbffff51
Merged-In: I1556b7499bd981af995f000519b7a314c70567d1
Change-Id: I5af7c954d432a2e8de6c6b744cedbada836bbd98
libui.so is not VNDK-SP, so it must not be allowed to RS drivers.
Bug: 37550338
Test: camerascript app works well in 2017 pixel devices
Change-Id: I34971baebdc91f11935d1eb4ddd07d89d4c38958
This commit adds libion.so to VNDK-SP so that some vendor's
gralloc.${chipset}.so can run without problems.
Bug: 62280700
Test: Boots a device from our partners
Merged-In: I2bcfe40ed9342de6d81dd310313e984a2c64964b
Change-Id: Ib745dfe52107d792296426b097e13b7c7755d88c
This commit adds libion.so to VNDK-SP so that some vendor's
gralloc.${chipset}.so can run without problems.
Bug: 62280700
Test: Boots a device from our partners
Merged-In: Ib745dfe52107d792296426b097e13b7c7755d88c
Merged-In: I2bcfe40ed9342de6d81dd310313e984a2c64964b
Change-Id: If30657b93157a2abea29fadcdb0004b37ad9eaf2
This commit adds libion.so to VNDK-SP so that some vendor's
gralloc.${chipset}.so can run without problems.
Bug: 62280700
Test: Boots a device from our partners
Change-Id: I2bcfe40ed9342de6d81dd310313e984a2c64964b
Exteded vndk-sp should go to /vendor/lib/vndk-sp.
Bug: 37940694
Test: sailfish builds and boots
Test: manually copying a lib from /system/lib/vndk-sp to
/vendor/lib/vndk-sp. Check that the copied one in /vendor partition is
loaded instead of the original one.
Change-Id: Ia5dd6f35bd31d4a20a794bec148e1fc3c6d7b72b
Test: I solemnly swear I tested this conflict resolution.
Merged-In: I137c17d55940b783eab6d0125bc4d26b96bcc2f2
Change-Id: I90c3ff7c82a9b53ce00057fd87cf227d5faf0975
This commit moves libz.so from default namespace to vndk namespace.
Accodring to b/37617391, libz.so is not as stable as we thought, thus
it should be vndk-sp instead of ll-ndk.
Bug: 37617391
Test: sailfish builds, boots, no new dynamic linker errors in log
Change-Id: I3922895a169303c33914a8a0f4b50cb993a724c9
libvndksupport.so is a new member of ll-ndk.
Bug: 37323945
Test: sailfish builds and boots
Merged-In: Ic5db48292a30a6face7f263d939f27a0760240b1
Change-Id: Ic5db48292a30a6face7f263d939f27a0760240b1
(cherry picked from commit 7000859b7c)
libbacktrace and its dependents are now VNDK-SP. Since they are in
/vendor/lib/vndk-sp directory, they are accessible directly from the
vndk namespace. Therefore, libbacktrace is removed from the exported
shared libs list of the default namespace.
Bug: 37413104
Test: sailfish builds and boots
Merged-In: I137c17d55940b783eab6d0125bc4d26b96bcc2f2
Change-Id: I137c17d55940b783eab6d0125bc4d26b96bcc2f2
(cherry picked from commit b2a4b8cd18)
libbacktrace and its dependents are now VNDK-SP. Since they are in
/vendor/lib/vndk-sp directory, they are accessible directly from the
vndk namespace. Therefore, libbacktrace is removed from the exported
shared libs list of the default namespace.
Bug: 37413104
Test: sailfish builds and boots
Change-Id: I137c17d55940b783eab6d0125bc4d26b96bcc2f2
android.hidl.base@1.0 and android.hidl.manager@1.0 are built into libhidltransport.
Test: boot internal marlin
Bug: 33276472
Change-Id: I32dc22607f2df5c71555161178865900b35fc75b
(cherry picked from commit fa5ea6a81a)
android.hidl.base@1.0 and android.hidl.manager@1.0 are built into libhidltransport.
Test: boot internal marlin
Bug: 33276472
Change-Id: I32dc22607f2df5c71555161178865900b35fc75b
VNDK-SP is relocated back to /system partition from /vendor partition,
following the original design.
In addition, the namespace for RenderScript is added. The namespace is
dedicated for loading VNDK-SP libs for RenderScript such as
libRS_internal.so. The reason for having a separate namespace is that
RenderScript requires more permitted paths (/data/*) which should not be
allowed for normal SP-HALs.
Bug: 37522144
Bug: 37550338
Test: sailfish builds and boots well
Test: lsof shows VNDK-SP libs are loaded from /system/lib/vndk-sp
Test: RenderScript app (CameraScript) runs well
Change-Id: Id139f626cafae2e43ee4eefc5a57a204e31bbbc9
Add asan counterparts.
Bug: 37579959
Test: m && m SANITIZE_TARGET=address
Merged-in: I23f05436b79fbcb3f6fa11d84c95fcd180fad3b3
Change-Id: I23f05436b79fbcb3f6fa11d84c95fcd180fad3b3
libui.so is not used by SP-HALs, so it is removed from the list of libs
exposed from the default namespace.
Also, this fixes a warning message "property value is empty" caused by
the automatically removed trailing '/' for the section 'legacy'. Since
the legacy behavior is already implemented by the linker itself, the
behavior doesn't need to specified in ld.config.txt.
Test: marlin/sailfish boots
Test: no warning message is shown
Change-Id: Ib679794d63b01c6794663dc88f1ab7e72cfb11d3
Now, framework process (any process that is executing /system/bin/* or
/system/xbin/*) are started with three namespaces; default, sphal and
vndk.
default namespace is the namespace that is responsible for loading libs
from /system/lib. It can't load libs from other places such as
/vendor/lib. (However, we temporarily open the path since we haven't
finished the system partition cleanup, but will do eventually).
sphal namespace is the namespace where SP-HAL (Same-process HAL) is
loaded. SP-HAL are the only vendor libraries that are allowed to be
loaded inside framework processes. libEGL_<chipset>.so and
android.hardware.graphics.mapper@2.0-impl.so, etc are SP-HALs. When
framework needs to load those SP-HALs, it explicitly loads it from this
namespace using android_get_exported_namespace() and
android_dlopen_ext().
vndk namespace is the namespace for loading vndk-sp (Vendor-NDK for
Same-Process) libs, which is a small set of framework libraries that
SP-HALs can link against. These libraries are compiled for the same
version of Android that the vendor partition is compiled against.
SP-HALs can not use libraries other than vndk-sp and ndk libs.
Membership to vndk-sp and ndk are strictly closed.
Note that in a system, there are two copies of vndk-sp libs. One at
/system/lib and the other at /vendor/lib/vndk-sp. As a result, there can
be two instances of a same library in a process.
Also adds ld.config.legacy.txt which is used on non-Treble devices where
PRODUCT_FULL_TREBLE is not set to true.
Note, this split can be cleaned up further after b/37139976 is solved.
Bug: 34407260
Test: git diff HEAD:rootdir/etc/ld.config.legacy.txt
HEAD^:rootdir/etc/ld.config.txt => 0
Test: sailfish boots (because BOARD_VNDK_VERSION is not set to
'current')
Change-Id: I8331d94edc38f22c4f8abc66cdf2050af9d0605b
This file describes how loader should set up
default namespace for different kind of binaries.
Note that vendor and some of system binaries are
not yet ready for this config to be enabled - they
rely on libraries they shouldn't be relying upon.
Bug: http://b/30435785
Test: m
Change-Id: I7d5853a6b55db169be1dc2c38cc682711bf7f7f5
It was dropped in the migration to the public.libraries format
NDK is the same on standard Android and Wear.
Bug: 27742249
Change-Id: I1eafbb649c0ccc5b9a93471fa387624d838bd3d0
This list contains libraries that should directly or indirectly
be accessible to apps for the platform. Note that this list is
not device specific but rather device class specific.
For now we have 2 separate lists; one for Android Phones and Tablets,
and another one for Android Wear devices.
Bug: http://b/27546414
Bug: http://b/22548808
Change-Id: I83de5e3cf67392d0e9af66f70123898bd5997146
DBUS had been needed by bluetooth bluz stack. It is not needed after
we replaced bluez stack with bluedroid stack.
bug 6872904
Change-Id: I3fa41c1dd4ac80bc679d5950b3b20c7f6d12265f
Set the security context for the init process.
Restore the security contexts of /cache and /data in case they were reset.
Specify the security context for services launched from the rootfs since
we cannot label their executables.
If on the emulator, set a policy boolean and restore the context of
/sys/qemu_trace to allow accesses not normally permitted on a device.
Change-Id: I166ffc267e8e0543732e7118eb0fd4b031efac3b
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The qemu-props program is launched at boot to read a series of
system property assignments from the emulator and apply them.
This is necessary to deal with the dynamic nature of the emulated
platform (e.g. the screen density which depends on the skin and
cannot be hard-coded in the platform image).
This patch ensures that qemu-props is started before any other
service that may read one of these properties (e.g. surface flinger).
This is done by encapsulating the program into a 'core' service.
Core services are all stared before regular ones.
Before the patch, qemu-props was started manually inside a script
that is called from a late emulator-specific boot service
(goldfish-setup).
The problem was that sometimes qemu-props was run too late.
This resulted in random flakiness, especially when running
on a low-end host machine.
Fix for bug 2161189 (and probably a few others)
Change-Id: I2933a25dcb5fecbb1fc238f157264e621b8f295b
Elliott Hughes