Allow optional vendor-specific initializations
within init. This can be used for runtime
initialization setup that init rc scripts do
not support.
Change-Id: I7623a0d59b18f9ec8e3623958e2f7ccd72b877bf
For visibility.
We could make this only for new API levels, but it isn't
currently exposed at build time, and visibility is good
on upgrades.
Bug: 340953047
Test: build, on device passing and failing requirements
Change-Id: I3a0ea47560c65114bc1b8685954d1fb7687cb8df
This changes user root to use the year date format
that vendor API uses.
Previously this still applied to V devices, which switched
to using API level 202404 after 35.
They recommend the year/date form, and there is no
constant for this.
Bug: 340953047
Test: service_test
Change-Id: I5ba8d1251c877a785e41f0cfcc35d7cb0776f8c7
This link will be used to change the sysfs attributes of the zoned block
device from an .rc file.
Bug: 335708738
Change-Id: I99f74c121e7d9da404c0564860c03ac1efe6c6d8
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Make all member functions private that are not called from outside
DeviceHandlermember functions.
Bug: 335708738
Change-Id: Ibe2e5f6b8b45a79b5be59665627e0a46de4e439a
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Slightly reduce the time that is required to start the init process by
changing two static std::string variables into std::string_view variables.
Change-Id: Ib683a603da5f3d8968b26453b12544fed8a6397f
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Linux 6.9+ supports 33 bits with Sv48 and Sv57. Increase the
maximum and update the comment.
Bug: https://github.com/google/android-riscv64/issues/1
Test: Treehugger
Change-Id: Ia2731143ad30c5febe2058d35a381c01b14d8c3c
We'll make it a build time check in V after this.
Due to being a runtime flog, it was hard to spot and
debug, so delaying.
Bug: 340953047
Test: boot, CtsInitTestCases
Change-Id: Ica1a1c780e230c88615dad7937404d2b0fe9c68f
When someone uses the 16kb dev option, they switch
out the kernel, but the same build is used. Make
sure this is visible in the fingerprint to help
split up any analytics or reports.
Bug: 332406754
Test: no change on normal device, on 16k dev option device:
:) adb shell getprop ro.product.build.16k_page.enabled
true
:) adb shell getconf PAGE_SIZE
16384
:) adb shell getprop ro.build.fingerprint
generic/aosp_cf_x86_64_phone_pgagnostic_16kb/vsoc_x86_64_pgagnostic:VanillaIceCream/MAIN.b7aab5e4/eng.smorel.20240514.203625:userdebug/test-keys
^^^^^^
----------------------------/
cheers
Change-Id: I9632237cef4a3b077761022eda8cf42784a41753
Turns out we didn't need the syscall because the kernel checks
for async MTE fault on exit.
Test: atest mte_upgrade_test with and without MTE
Change-Id: Iebdf181d67b4586926499c7549c72e73efc13c56
init ignored the rc file because of incorrect permissions
also replace deprecated "push" with "push-file"
Test: atest mte_upgrade_test
Bug: 335232356
Change-Id: I4c17311dbb1d001567f4cdda65036f16aec2b5c1
So far, we have used `instalable: false` to avoid collision with the
other modules that are installed to the same path. A typical example was
<foo> and <foo>.microdroid. The latter is a modified version of the
former for the inclusion of the microdroid image. They however both have
the same instalation path (ex: system/bin) and stem (ex: foo) so that we
can reference them using the same path regardless of whether we are in
Android or microdroid.
However, the use of `installable: false` for the purpose is actually
incorrect, because `installable: false` also means, obviously, "this
module shouldn't be installed". The only reason this incorrect way has
worked is simply because packaging modules (ex: android_filesystem)
didn't respect the property when gathering the modules.
As packaging modules are now fixed to respect `installable: false`, we
need a correct way of avoiding the collision. `no_full_install: true` is
it.
If a module has this property set to true, it is never installed to the
full instal path like out/target/product/<partition>/... It can be
installed only via packaging modules.
Bug: 338160898
Test: m
Change-Id: I37380c19232f2c497bdf492a83cdc16616f0ae8d
We're shutting down anyway, so the service is either dead already
or about to be killed, and callers get upset (and don't have a good
response themselves) if we reject the request.
This was seen by a partner where adbd was asked to stop during
shutdown.
Bug: https://issuetracker.google.com/336223505
Change-Id: If09feeef2e0f2d1be9ff84a88cca6ed593a35362
when introducing instrumentation for MTE stack history buffer, we cannot
use stack MTE in early init
Bug: 309446520
Change-Id: I0921ae4ffe03ed971697f8daff4215c9b3772e35
This change introduces a new mode to `subsystem.devname` in `ueventd.rc`
configuration files, which sets the file name to the contents of
`/sys/DEVNAME/name`.
The objective of this change is to help Cuttlefish distinguish between
console devices, which are only different in uevents by initialization
order. Cuttlefish currently relies on `/dev/hvc##` devices which are
created for non-multiport virtio-console devices.
https://cs.android.com/android/platform/superproject/main/+/main:device/google/cuttlefish/shared/config/ueventd.rc;l=18;drc=5204f119d859d3ae5f1a2ee1c6a05ee68d6a28ed
On Cuttlefish we're considering moving to multiport virtio-console
devices ( https://fedoraproject.org/wiki/Features/VirtioSerial ). It
would be possible to rely on device order here as well, but using names
to distinguish devices makes it possible to drop unused devices in the
future, rather than reserving indexes indefinitely.
Multiport virtio-console devices create uevents with DEVNAME=vport#p#
and DEVPATH=.../vport#p#, only exposing the name in a sysfs file.
Bug: 336663898
Test: Attach multiport console, run with `-DLOG_UEVENTS=1`
Test: Introduce ueventd policy using `devname sys_name`
Change-Id: I59632b556db4a47883eab97e90c0e6ca81a9c650
std::array<T, N> takes exactly N * sizeof(T) bytes, leaving no room for
the null terminator.
Bug: 335047945
Test: re-run the GSI test
Change-Id: Ic3aca5f409021c78a7eb965c5ed610e6a51e42cb
init_second_stage_defaults provides properties that are common to both
Android's init and Microdroid's init. Before this CL, it included
target.product.required and target.recovery.required properties. The
required dependencies were Android-specific; the dependencies included
Android-only init.rc. Microdroid has its own init.rc (microdroid_init_rc
module).
This was problematic but so far it didn't cause an issue because those
Android-only dependencies were not installed to Microdroid due to a bug
in the build system.
As we fix the build system bug, the Android-only dependencies started
get installed to Microdroid, effectively overriding the Microdroid-only
init.rc file. This made Microdroid fail to boot.
Fixing this issue by moving the Android-only dependencies out of the
defaults module and putting them on the Android's init.
In addition to that, this CL removes the recovery variant for the
Microdroid's init because it's not used.
Bug: N/A
Test: run AVF tests
Change-Id: I09748f1123125cac74ce54fd5c360c9a3ba2f996
Found out that increasing the threshold to 20 crashes pushes the file
system based rollbacks as well. So introducing a throttling behaviour
instead. Now native watchdog performs reboot with ramdump at 5 restarts.
After that packageWatchdog/ RescueParty takes over to perform other
mitigations. Ram dump + reboot will not be performed more than once
in 24hrs.
Test: manual
Bug: 291137901
Change-Id: Ia192411dad94e8e25c26f700d2fe7f94d41439b8
As of now ueventd only prints the firmware name
requested by the uevent, but in case the device
has multiple firmware going by the same name it's
more interesting to know what file ends up actually
being used for the firmware request.
Test: m, check logcat
Change-Id: Ia90d387f09789d8e8b337a1a178144fad553d37b
