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
This change forces the start of the RIL daemon used to provide
3G connectivity to the system. It should normally be started
automatically by init.rc but there is a bug within
system/core/init/builtins.c that prevents this to happen.
Fixes the "No network connectivity" bug while the network
interface and route were properly setup.
Change-Id: Ieec0f513aabf92b8a59f0a86f64a16e97057c3c3
The net.eth0.gw system property is used by the ConnectivityService
to set the default route when it detects that 3G connectivity is
established. Because the property was undefined, the route was
unset which broke networking.
+ Format / document init.goldfish.sh
Change-Id: I1133cf6c093609300315cd0ea363c9e139b42521
This fixes the goldfish-specific config scripts used by init and ueventd
to properly setup the system under emulation. This fixes a lot of broken-ess
introduced by recent permission changes in the system.
Note that there are still several problems after this patch is applied, but
at least it becomes possible to get an adb connection to the emulated system,
Change-Id: Iff47bbf0fe5cb759fa93089284bb0f71e32405a2
This fixes both a typo and the fact that sh seems not to have
test or [.
(see also sh/builtins.def: ##testcmd commented out)
The handling of these properties was broken, having the effect
that the Modem in ... internal/telephony/test/Simulated*.java
was never run, even if it would have been the users/developers
intention.
See also issue #1380http://code.google.com/p/android/issues/detail?id=1380
Signed-off-by: Simon.Braunschmidt@gmail.com>