system-core

Fork

Allow the use of a custom Android DT directory

On platforms that use ACPI instead of Device Tree (DT), such as
Ranchu x86/x86_64, /proc/device-tree/firmware/android/ does not
exist. As a result, Android O is unable to mount /system, etc.
at the first stage of init:

init: First stage mount skipped (missing/incompatible fstab in
device tree)

Those platforms may create another directory that mimics the layout
of the standard DT directory in procfs, and store early mount
configuration there. E.g., Ranchu x86/x86_64 creates one in sysfs
using information encoded in the ACPI tables:

https://android-review.googlesource.com/442472
https://android-review.googlesource.com/443432
https://android-review.googlesource.com/442393
https://android-review.googlesource.com/442395

Therefore, instead of hardcoding the Android DT path, load it from
the kernel command line using a new Android-specific property key
("androidboot.android_dt_dir"). If no such property exists, fall
back to the standard procfs path (so no change is needed for DT-
aware platforms).

Note that init/ and fs_mgr/ each have their own copy of the Android
DT path, because they do not share any global state. A future CL
should remove the duplication by refactoring.

With this CL as well as the above ones, the said warning is gone,
but early mount fails. That is a separate bug, though, and will be
addressed by another CL.

Test: Boot patched sdk_phone_x86-userdebug system image with patched
Goldfish 3.18 x86 kernel in patched Android Emulator, verify
the "init: First stage mount skipped" warning no longer shows
in dmesg.

Signed-off-by: Yu Ning <yu.ning@intel.com>

(cherry picked from commit c08d2cb0fb7ce470e128c7571553aa12ae9b57a4)

Change-Id: Ia8d5f68e044fde0ecf5c7b14e40f040ff42bc35d

Merge cherrypicks of [2467803, 2467786, 2467717, 2467598, 2467823, 2467734, 2467671, 2467718, 2467599, 2467753, 2467672, 2467600, 2467735, 2467841, 2467638, 2467824, 2467736, 2467754, 2467737, 2467674] into oc-release

Change-Id: Iaeea349ef72436af0b5da51537514d4fc64cbce0

healthd: notify listeners using local copy of list, drop lock

Binder currently may service an incoming oneway transaction whenever
an outbound oneway call is made (if there is already a pending
incoming oneway call waiting). The unexpected nested method call
blocks forever on a recursive mutex acquire because healthd is single-
threaded. The binder behavior is considered a bug and may change in
the future. For now, work around this in healthd.

Make a local copy of the listeners list, then drop the lock and
perform the outbound calls on the local copy of the list.

Bug: 38201220
Test: Marlin with modified client calling scheduleUpdate() repeatedly
Change-Id: If35c2847556245921e2aff808ff747bb60356811
(cherry picked from commit fd68370074fab549f569d8b9a5bf3d7c535c47bc)

release-request-160c4b31-7fa0-4e2b-aabe-85380836a1ce-for-git_oc-release-4129081 snap-temp-L15300000077039010

Change-Id: I44c769e6ff6094f3027c33cfe3e1a017583d0679

Debuggerd: Extend crash_dump timeout to 5 seconds

Some processes have lots of threads and minidebug-info. Unwinding
these can take more than the original two seconds.

Bug: 62828735
Test: m
Test: debuggerd_test
Test: adb shell kill -s 6 `pid system_server`
Merged-In: I0041bd01753135ef9d86783a3c6a5cbca1c5bbad
Change-Id: I0041bd01753135ef9d86783a3c6a5cbca1c5bbad
(cherry picked from commit b02851a984391d25bfc5b3094f281432906b47ed)

ld-config: Export android.hidl.memory@1.0-impl

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 bd7503dae7008bfecbd729ba9e473c73ada17141)
(cherry picked from commit 3251e582f268b2b30a35e482e026fc9026b3956c)

release-request-767e2998-9243-43e0-b656-1acb30ac5115-for-git_oc-release-4124637 snap-temp-L74200000076595014

Change-Id: Id2ae3574c07e26d407c05bf18d9a897001684e3d

Merge "ld-config: Add HIDL memory libs to VNDK-SP" into oc-dev

Merge "Revert "ueventd: remove PlatformDeviceList"" into oc-dev

Revert "ueventd: remove PlatformDeviceList"

Bug: 62864413

This reverts commit d43b615216fb1656fb5234e8202aa3ed7b37fda7.

Change-Id: If3d9060e723d6040d3f32f253b492131a56edb9f

Revert "init: poll in first stage mount if required devices are not found"

Bug: 62864413

This reverts commit 5f4e8eac8a0db87a43ed7a930103f4241c22d479.

Change-Id: I6f35b920bb52875c8ef430d3e20b205fda5165e8

ld-config: Add HIDL memory libs to VNDK-SP

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

release-request-5bf29450-4eb0-4d71-a15a-d8858bf184d3-for-git_oc-release-4120128 snap-temp-L37600000076154351

Change-Id: Icfb38e46cb517b62b9af2c95c4bbc2afc4c56084

init: poll in first stage mount if required devices are not found

First stage mount in init currently attempts to regenerate uevents for
specific devices to create the corresponding dev nodes. However, this
is racy as first stage mount happens early in the boot process and
it's possible that some of these devices have not yet been created by
the kernel.

To fix this issue, init will poll on the uevent socket for up to 10
seconds waiting for the kernel to create the required device. It will
return false and panic if this 10 second timeout passes.

Note that the same uevent socket is used in the uevent regeneration
and the polling code, so there is no race if the device is created
after the uevent regeneration and before polling starts; the first
poll will pick up the device.

Bug: 62681642
Bug: 62682821
Test: Boot bullhead
Test: Boot sailfish
Test: Boot hikey + hotplug/unplug sdcard
Merged-In: I4a6ff043eb7115b729ca4954ebc6c9e000132993
Change-Id: I4a6ff043eb7115b729ca4954ebc6c9e000132993

ueventd: remove PlatformDeviceList

In order to create symlinks for USB and block devices, the path for
their parent platform device must be known.

Previously, ueventd would save each platform device that it encounters
to a list and query this list when creating the symlinks. That,
however, is racy because the uevent socket does not differentiate
uevents from device_init() and uevents sent by the kernel when
probing a device first the first time. The below scenario is the
faulty case:

1) Kernel probes parent platform device for a block device
2) ueventd calls device_init() and starts processing uevents
3) Kernel probes block device and sends its uevents
4) ueventd picks up the block device uevent during its uevent processing,
without yet regenerating the platform device uevent, causing improper
symlinks to be created.

This change stops storing the platform devices in a list, and instead
traverses up the directory structure for each USB or block device
until it reaches a platform device, defined as one whose subsystem is
the platform bus. This fixes the race and simplifies the ueventd
code.

Bug: 62436493
Bug: 62681642
Test: Boot bullhead
Test: Boot sailfish
Test: Boot hikey + hotplug/unplug sdcard
Merged-In: I21636355d8e434f30e0cba568598a6cf139e67f9
Change-Id: I21636355d8e434f30e0cba568598a6cf139e67f9

release-request-0b3ce0b0-0f38-494b-a590-b594ba11c2d2-for-git_oc-release-4098933 snap-temp-L41500000074000728

Change-Id: I65f09867239188cfcb2addfcec52eadb4e7b837a

Merge changes from topic 'move-default-prop-v2' into oc-dev

* changes:
Load /prop.default in recovery mode
Revert "Revert "Load default prop from /system/etc/prop.default""

Load /prop.default in recovery mode

Bug: 37815285
Bug: 62525809
Test: Tested with ag/2398663 and ag/2400523. Booted pixel phones,
checked the location of prop.default, verified the symlink,
checked a few properties via adb shell and manually tested
a few apps.
Booted to recovery and ran 'adb sideload' successfully.
Change-Id: I034b700fcd60b0104873131e94864b16ef4bd9f6

Revert "Revert "Load default prop from /system/etc/prop.default""

This reverts commit 98a73a2ce10df46bc8d095413b415e284206836b.

Bug: 37815285
Bug: 62525809
Test: Tested with ag/2398663 and ag/2400524. Booted pixel phones,
checked the location of pro.default, verified the symlink
at /default.prop, checked a few properties via adb shell and
manually tested a few apps.
Booted to recovery mode and ran 'adb sideload' successfully.
Change-Id: I407412a7002b898ffb352cb5f331cab9c15be39a

release-request-7d12f16b-b4a7-4324-8b59-be2d4e07dcb3-for-git_oc-release-4094438 snap-temp-L80000000073561277

Change-Id: If4c878000ac88314a5d0c9b394fee0504c2c8f77

Merge "tombstoned: log where we're writing the tombstone." into oc-dev

tombstoned: log where we're writing the tombstone.

Make it easy to find out where a specific crash's tombstone was written
to by adding a log.

Bug: http://b/62268830
Test: crasher
Merged-In: I1961dfb19f76a42a8448ebafd4be153b73cb6800
Change-Id: I1961dfb19f76a42a8448ebafd4be153b73cb6800
(cherry picked from commit cb68a0317d1d3f8a32a5fc87e93c1e7fc98a7d24)

Merge cherrypicks of [2396133, 2396035, 2395977, 2395978] into oc-release

Change-Id: I68ba69d7159ebcc55bc66ff5fad9764c190448b1

Revert "Load default prop from /system/etc/prop.default"

This reverts commit 810d71b0050bb94fe9bbcd02368dafd52cebdeb7.

init fails to read default.prop under recovery:
init: Couldn't load properties from /default.prop: Too many symbolic links encountered

Bug: 62525809
Change-Id: I1f84a18e545e1307dcb230be51606cca731667f9
(cherry picked from commit 98a73a2ce10df46bc8d095413b415e284206836b)

Merge "Revert "Load default prop from /system/etc/prop.default"" into oc-dev

Revert "Load default prop from /system/etc/prop.default"

This reverts commit 810d71b0050bb94fe9bbcd02368dafd52cebdeb7.

init fails to read default.prop under recovery:
init: Couldn't load properties from /default.prop: Too many symbolic links encountered

Bug: 62525809
Change-Id: I1f84a18e545e1307dcb230be51606cca731667f9

release-request-276f9f52-87fd-4915-bd79-9a2f0ee77433-for-git_oc-release-4090213 snap-temp-L31600000073091223

Change-Id: If83017b48c4e832c9b67121b052ec422effaa8dd

Merge "Load default prop from /system/etc/prop.default" into oc-dev

Load default prop from /system/etc/prop.default

/default.prop is moved to /system/etc/prop.default for full Treblized
devices. Modifies property_service to load it from there first.

Bug: 37815285
Test: Tested with ag/2371424. Booted pixel phones, checked the location
of pro.default, verified the symlink at /default.prop, checked a
few properties via adb shell and manually tested a few apps.

Change-Id: I485231f21fc86b0aec58edf867e229a31e77d85e

release-request-011e6329-d82e-4e46-980f-68776b0cd6b9-for-git_oc-release-4080367 snap-temp-L79900000072116775

Change-Id: I2d59ed7e882717d139b43f343713cda8d1542bc9