This directory is no longer used. OBB content is
placed in /data/media/$user/Android.
Test: make
Test: manually verify the path doesn't exist.
Bug: 129167772
Change-Id: I8549826586b9a68c8cfa3fe2e51295363f9b4e11
Executable in /data/ runs in default linker namespace, not
classloader namespace.
In Q, we moved libicuuc.so and libicui18n into the runtime
namespace, and allow linking from runtime namespace and classloader
namespace.
This change further allows linking from default namespace, and tries
to fix the regression temporarily.
Bug: 130788466
Test: The app issue is fixed after this CL
Merged-In: Ifae52b554124514e433cfe78875643a7450fbabd
Change-Id: Ifae52b554124514e433cfe78875643a7450fbabd
(cherry picked from commit 0c7edece94)
Permitted paths were empty for ASAN builds with the media namespace.
Bug: 131625115
Test: no dlopen failure on libflacextractor.so in aosp_cf_x86_pasan
Change-Id: I90050fc54820ba68d64931412572f3b0954e6616
Executable in /data/ runs in default linker namespace, not
classloader namespace.
In Q, we moved libicuuc.so and libicui18n into the runtime
namespace, and allow linking from runtime namespace and classloader
namespace.
This change further allows linking from default namespace, and tries
to fix the regression temporarily.
Bug: 130788466
Test: The app issue is fixed after this CL
Change-Id: Ifae52b554124514e433cfe78875643a7450fbabd
The canonical location of the HWASAN runtime, an LL-NDK library, is being moved
to the runtime APEX. It is apparently the first LL-NDK library in the runtime
APEX that does not require a legacy symlink in /system/${LIB}. Therefore we
need to link the HWASAN runtime in the runtime namespace to various namespaces
so that the library can be loaded from outside of the namespace.
Also, add $SANITIZER_RUNTIME_LIBRARIES to
namespace.default.link.system.shared_libs. This is necessary because in
the accompanying Soong change, we cause the HWASAN runtime to be removed
from $LLNDK_LIBRARIES. In most cases, except for this one, this was a no-op
because we were already including both sets of libraries in shared_libs.
Change-Id: I67d64788855d28f3a156a1b9cf8a897617277730
This relands http://r.android.com/951440:
This affected binaries in the Runtime APEX, where the platform namespace is
"platform" rather than "default".
Also extend ANDROID_ADDITIONAL_PUBLIC_LIBRARIES to create links to both to
platform and runtime namespaces, so that it can be used to open up access to
internal libraries in the Runtime APEX as well, which is used by ART gtests
and run tests.
Also update some comments in the ld.config*.txt files to accurately explain
why some namespaces need to be visible, and some other minor changes for
consistency. There are no semantically significant changes in those files.
Test: Flash and boot
Test: Run an ART run test with the internal libarttest.so library
Test: lunch aosp_cf_x86_phone-eng;
atest android.compilation.cts.AdbRootDependentCompilationTest#testCompile_curProfile \
com.android.cts.dexmetadata.InstallDexMetadataHostTest#testProfileSnapshotAfterInstall \
installd_dexopt_test
Bug: 130293232
Bug: 121117762
Change-Id: I3d9f2102a03e83843e15bc78b5ad347220c52769
Follow up to http://r.android.com/943476. This library is only available in
debug builds of the Runtime APEX.
Test: Flash and boot with eng build
Change-Id: I260f9b838f44ba3f8976c117d9e42fc456239e88
This reverts commit 4ca0ca67bf.
Reason for revert: Breaks android.compilation.cts.AdbRootDependentCompilationTest#testCompile_curProfile and others: http://g/art-team/R2nEDA1Ka_s
Change-Id: Ia6285648133d21e61040efafc73cac97d702a7c4
This affected binaries in the Runtime APEX, where the platform namespace is
"platform" rather than "default".
Also extend ANDROID_ADDITIONAL_PUBLIC_LIBRARIES to create links to both to
platform and runtime namespaces, so that it can be used to open up access to
internal libraries in the Runtime APEX as well, which is used by ART gtests
and run tests.
Also update some comments in the ld.config*.txt files to accurately explain
why some namespaces need to be visible, and some other minor changes for
consistency. There are no semantically significant changes in those files.
Test: Flash and boot
Test: Run an ART run test with the internal libarttest.so library
Bug: 130293232
Bug: 121117762
Change-Id: I7ebaf5370dd0f533b1bb5f0e67e7c3c1df48e512
On devices that use FDE and APEX at the same time, we need to bring up a
minimal framework to be able to mount the /data partition. During this
period, a tmpfs /data filesystem is created, which doesn't contain any
of the updated APEXEs. As a consequence, all those processes will be
using the APEXes from the /system partition.
This is obviously not desired, as APEXes in /system may be old and/or
contain security issues. Additionally, it would create a difference
between FBE and FDE devices at runtime.
Ideally, we restart all processes that have started after we created the
tmpfs /data. We can't (re)start based on class names alone, because some
classes (eg 'hal') contain services that are required to start apexd
itself and that shouldn't be killed (eg the graphics HAL).
To address this, keep track of which processes are started after /data
is mounted, with a new 'mark_post_data' keyword. Additionally, create
'class_reset_post_data', which resets all services in the class that
were created after the initial /data mount, and 'class_start_post_data',
which starts all services in the class that were started after /data was
mounted.
On a device with FBE, these keywords wouldn't be used; on a device with
FDE, we'd use them to bring down the right processes after the user has
entered the correct secret, and restart them.
Bug: 118485723
Test: manually verified process list
Change-Id: I16adb776dacf1dd1feeaff9e60639b99899905eb
On devices that use FDE and APEX at the same time, we need to bring up a
minimal framework to be able to mount the /data partition. During this
period, a tmpfs /data filesystem is created, which doesn't contain any
of the updated APEXEs. As a consequence, all those processes will be
using the APEXes from the /system partition.
This is obviously not desired, as APEXes in /system may be old and/or
contain security issues. Additionally, it would create a difference
between FBE and FDE devices at runtime.
Ideally, we restart all processes that have started after we created the
tmpfs /data. We can't (re)start based on class names alone, because some
classes (eg 'hal') contain services that are required to start apexd
itself and that shouldn't be killed (eg the graphics HAL).
To address this, keep track of which processes are started after /data
is mounted, with a new 'mark_post_data' keyword. Additionally, create
'class_reset_post_data', which resets all services in the class that
were created after the initial /data mount, and 'class_start_post_data',
which starts all services in the class that were started after /data was
mounted.
On a device with FBE, these keywords wouldn't be used; on a device with
FDE, we'd use them to bring down the right processes after the user has
entered the correct secret, and restart them.
Bug: 118485723
Test: manually verified process list
Change-Id: I16adb776dacf1dd1feeaff9e60639b99899905eb
The debug ramdisk can only be used if the device is unlocked.
When it's used, init will load adb_debug.prop and the userdebug
sepolicy from the debug ramdisk, to allow adb root on a user build.
Bug: 126493225
Test: 'make' and checks the file is installed
Change-Id: Id6962414197fc8f47f7c07818e8fb16107dc17a3
Merged-In: Id6962414197fc8f47f7c07818e8fb16107dc17a3
(cherry picked from commit 05f07d89a6)
The debug ramdisk can only be used if the device is unlocked.
When it's used, init will load adb_debug.prop and the userdebug
sepolicy from the debug ramdisk, to allow adb root on a user build.
Bug: 126493225
Test: 'make' and checks the file is installed
Change-Id: Id6962414197fc8f47f7c07818e8fb16107dc17a3
In previous implementation, userdebug sepoilcy and property files are
loaded from the system.img. This CL changes this to:
- first-stage init copies userdebug files from ramdisk to /debug_ramisk/*
- second-stage init loads files from /debug_ramdisk/*.
Note: same as before, the above can only be triggered, if the device
is UNLOCKED
With this, we don't have to put userdebug related files into the USER
system.img.
Bug: 126493225
Test: boot device with a ramdisk with /force_debuggable, checks related
files are loaded
Change-Id: I63f5f846e82ba78427062bf7615c26173878d8f3
Merged-In: I63f5f846e82ba78427062bf7615c26173878d8f3
(cherry picked from commit 30afda71c0)
