The function returns "_a" or "_b" based on two possible values in
kernel cmdline:
- androidboot.slot = a or b OR
- androidboot.slot_suffix = _a or _b
Bug: 33254008
Bug: 36533366
Test: boot sailfish
Change-Id: Ia0a524e4145ebf61af5821f42ecad212c95ed748
(cherry picked from commit c27f12a3d396f113c5ae09d2f2c8ff7de3f8b551)
logd assumes that it is running in UTC time zone.
However, if persist.sys.timezone is set at some point later,
that affects and confuses logd behavior.
To avoid such a case, this CL sets TZ to UTC, which overrides
the property's behavior.
Test: Ran CtsOsTestCases.
Test: gTest liblog-unit-tests, logd-unit-tests and logcat-unit-tests
Bug: 33566779
Change-Id: Ib9edd4cb06f019a33aaf8d77d33bd82fdbbda480
It's possible, in the event of a platform update, for the platform
SELinux policy to change from the policy on which the vendor SELinux
policy was originally based. In this case, a different mapping file
to bridge the differences between the new policy and the old needs to
be selected.
Make init choose which mapping policy file to use based on the version
reported in /vendor/etc/selinux/plat_sepolicy_vers.txt.
Bug: 36783775
Test: Force compilation of sepolicy on-device with mapping file changed
to new location and name, using the value reported on /vendor.
Change-Id: I63c883ccb79dd31c92dabe44a55c4ab50a3735e6
By setting vendor_available, the following may become true:
* a prebuilt library from this release may be used at runtime by
in a later releasse (by vendor code compiled against this release).
so this library shouldn't depend on runtime state that may change
in the future.
* this library may be loaded twice into a single process (potentially
an old version and a newer version). The symbols will be isolated
using linker namespaces, but this may break assumptions about 1
library in 1 process (your singletons will run twice).
Background:
This means that these modules may be built and installed twice --
once for the system partition and once for the vendor partition. The
system version will build just like today, and will be used by the
framework components on /system. The vendor version will build
against a reduced set of exports and libraries -- similar to, but
separate from, the NDK. This means that all your dependencies must
also mark vendor_available.
At runtime, /system binaries will load libraries from /system/lib*,
while /vendor binaries will load libraries from /vendor/lib*. There
are some exceptions in both directions -- bionic(libc,etc) and liblog
are always loaded from /system. And SP-HALs (OpenGL, etc) may load
/vendor code into /system processes, but the dependencies of those
libraries will load from /vendor until it reaches a library that's
always on /system. In the SP-HAL case, if both framework and vendor
libraries depend on a library of the same name, both versions will be
loaded, but they will be isolated from each other.
It's possible to compile differently -- reducing your source files,
exporting different include directories, etc. For details see:
https://android-review.googlesource.com/368372
None of this is enabled unless the device opts into the system/vendor
split with BOARD_VNDK_VERSION := current.
Bug: 36426473
Bug: 36079834
Test: m -j libutils
Test: attempt to compile with BOARD_VNDK_VERSION := current
Merged-In: I6c1279a74ef071851401e38bbdd377f13827694c
Change-Id: I6c1279a74ef071851401e38bbdd377f13827694c
By setting vendor_available, the following may become true:
* a prebuilt library from this release may be used at runtime by
in a later releasse (by vendor code compiled against this release).
so this library shouldn't depend on runtime state that may change
in the future.
* this library may be loaded twice into a single process (potentially
an old version and a newer version). The symbols will be isolated
using linker namespaces, but this may break assumptions about 1
library in 1 process (your singletons will run twice).
Background:
This means that these modules may be built and installed twice --
once for the system partition and once for the vendor partition. The
system version will build just like today, and will be used by the
framework components on /system. The vendor version will build
against a reduced set of exports and libraries -- similar to, but
separate from, the NDK. This means that all your dependencies must
also mark vendor_available.
At runtime, /system binaries will load libraries from /system/lib*,
while /vendor binaries will load libraries from /vendor/lib*. There
are some exceptions in both directions -- bionic(libc,etc) and liblog
are always loaded from /system. And SP-HALs (OpenGL, etc) may load
/vendor code into /system processes, but the dependencies of those
libraries will load from /vendor until it reaches a library that's
always on /system. In the SP-HAL case, if both framework and vendor
libraries depend on a library of the same name, both versions will be
loaded, but they will be isolated from each other.
It's possible to compile differently -- reducing your source files,
exporting different include directories, etc. For details see:
https://android-review.googlesource.com/368372
None of this is enabled unless the device opts into the system/vendor
split with BOARD_VNDK_VERSION := current.
Bug: 36426473
Bug: 36079834
Test: m -j libutils
Test: attempt to compile with BOARD_VNDK_VERSION := current
Change-Id: I6c1279a74ef071851401e38bbdd377f13827694c
tasks in system-background cgroup will be shown as below:
580 580 system 12 -8 1% S 190656K 19408K unk surfaceflinger /system/bin/surfaceflinger
This patch fix this issue.
Change-Id: Ib39ff892010498548d7fbfb4021df62498acd033
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
