It's requested by the partner engineering team to uniquely
identify a partition.
Bug: 197973981
Test: boot the device and check props
Change-Id: I0f7aa34dd0087f0698fe90b9df6c0eae06fc4f5d
Add a simple SIGCHLD handler to reap zombie processes given to init.
Bug: 197662257
Change-Id: I6e7930cfd7c311c454b361b9a541369ece2eb744
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Microdroid shares init with its host, defined under system/core/init.
This change adds MicrodroidHostTestCases to TEST_MAPPING to ensure that
Microdroid tests can verify patches to init.
Test: presubmit
Change-Id: I55f7e3ffbaf3401d145afac5f7c53d83f69e6ba7
I've actually left the two other scripts on python2, since they're not
used in the build, and I don't actually know whether anyone's still
using them manually. Leaving them on python2 should be a sign to future
maintainers (assuming they're far enough in the future) that maybe
no-one's using them and they can just be deleted instead.
Test: treehugger
Change-Id: I4d7dfdbf9f2a34ddd15cd4be077eeef2248cc596
Android uses an out-of-tree /proc/sys/vm/extra_free_kbytes kernel knob
to increase low watermark. A similar /proc/sys/vm/watermark_scale_factor
knob supported in upstream kernel can be used for the same purpose.
The script implements conversion from desired extra_free_kbytes value
to watermark_scale_factor value and sets watermark_scale_factor according
to the value for extra_free_kbytes provided as a parameter.
Note that watermark_scale_factor affects high watermark differently
from extra_free_kbytes. While extra_free_kbytes increases low and high
watermarks by the same amount, watermark_scale_factor affects high
watermark 2x times. Therefore it is expected that replacing the usage
extra_free_kbytes with watermark_scale_factor will keep the same low
watermark but high watermark will be higher than before.
Usage:
extra_free_kbytes.sh <extra_free_kbytes value>
Bug: 109664768
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Id8949be731da77be884cdeec3a765ea291dbc2f0
A lot of things had moved out of system/core/ without their TEST_MAPPING
entries having gone with them, reducing the amount of presubmit coverage
for those things.
In order to reduce the likelihood of that happening again, I've pushed
all that remained in the system/core/ TEST_MAPPING down into the
individual subdirectories.
Test: treehugger
Change-Id: Ib75d65f9200fa64ae1552471da6fbe5b7023cf94
Don't start shutdown critical service or turn off
backlight, when ro.init.shutdown_animation=true
Bug: 196511757
Test: config ro.init.shutdown_animation=true and build
shutdownanimation.zip to /system/media/
Signed-off-by: zengshuchuan <zengshuchuan@allwinnertech.com>
Change-Id: I5932b7281af630e80247048a70fe1b24f536d1d9
Also the check that linker configuration should not be updated if APEX
is in updatable state, is removed as now with refactoring of code and its
movement to apex project, that is also needed.
Resolves: https://b.corp.google.com/issues/192838499
Test: Run the AVD Device and check that it boots and run atest
ApexTestCases
Change-Id: I80a94fa0a4145d30546bb34a6d478a20a2881368
Allow mapping of raw block devices (those without a partition table)
to partition names for first stage mount and ueventd. For example, a
block device `vdb` that contains only an ext4 metadata partition could
be mapped to `metadata` such that /dev/block/by-name/metadata is
created.
The mapping is provided by the `androidboot.partition_map` bootconfig
or kernel command line parameter.
Bug: 159943320
Test: boot with raw vdb,metadata;vdc,userdata partitions
Change-Id: Ib6a939d6fb88b85c46c81d613425a127627a734b
The reason for two mount namespace (bootstrap/default) is that we have
two sets of different APEXes to activate. But in microdroid, we don't
need two separate mount namespaces because there's only one set of
non-updatable APEXes in built-in directories and payloads (passed from
host Android).
Bug: 185991357
Test: MicrodroidHostTestCases
Change-Id: I4469f3b1d90f9543ecb980a450eaaf1c20b94c58
Currently there is no socket for daemon instances launched during the
selinux phase of init. We don't create any sockets due to the complexity
of the required sepolicy.
This workaround will allow us to create the socket with very minimal
sepolicy changes. init will launch a one-off instance of snapuserd in
"proxy" mode, and then the following steps will occur:
1. The proxy daemon will be given two sockets, the "normal" socket that
snapuserd clients would connect to, and a "proxy" socket.
2. The proxy daemon will listen on the proxy socket.
3. The first-stage daemon will wake up and connect to the proxy daemon
as a client.
4. The proxy will send the normal socket via SCM_RIGHTS, then exit.
5. The first-stage daemon can now listen and accept on the normal
socket.
Ordering of these events is achieved through a snapuserd.proxy_ready
property.
Some special-casing was needed in init to make this work. The snapuserd
socket owned by snapuserd_proxy is placed into a "persist" mode so it
doesn't get deleted when snapuserd_proxy exits. There's also a special
case method to create a Service object around a previously existing pid.
Finally, first-stage init is technically on a different updateable
partition than snapuserd. Thus, we add a way to query snapuserd to see
if it supports socket handoff. If it does, we communicate this
information through an environment variable to second-stage init.
Bug: 193833730
Test: manual test
Change-Id: I1950b31028980f0138bc03578cd455eb60ea4a58
Move all the code relevant to snapuserd to a seperate
directory. Add OWNERS file.
No other code changes apart from moving files around
and fixing couple location of header paths
at few places.
Bug: 194642092
Test: Compile, Full OTA
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Ib1d852bfeda4eca5c996d6cd7b057f141cb5ddad
So that init_second_stage (core) depends on core variant tools and rc
files, and init_second_stage.recovery depends on recovery variant tools
and recovery specific rc files.
Bug: 191369319
Test: Presubmit
Test: Check the ninja graph, init_second_stage.recovery no longer depend
on core variation modules
Test: Check out/soong/Android-${PRODUCT}.mk
Change-Id: I03f0cf6af10617fe2e7de677e9dde1aecb2afc74
This reverts commit 1c51525f66 because it
accidentally made reboot_on_failure be a no-op for all services. This
is because Reap() itself calls KillProcessGroup() on devices with a
vendor level >= R, which in turn sets SVC_STOPPING. I had overlooked
this somehow, probably because I didn't consider that a service can
consist of multiple processes.
It turns out that real FDE devices don't actually need the above commit
because FDE devices aren't allowed to have updatable apexes enabled, and
without updatable apexes enabled, apexd exits automatically and
therefore doesn't have to be stopped. This can be verified by using the
aosp_cf_x86_phone_noapex build target, rather than aosp_cf_x86_phone
which I had used for testing before. So just revert it for now.
Bug: 194370048
Change-Id: I90eddf2a87397449b241e5acaaa8d4a4241d73a9
This reverts commit 4818f74888.
The previous commit might introduce a build break on legacy
devices that with a smaller /boot partition size, because it
outputs the first-stage init and the second-stage init binaries
in the following locations, respectively (when
BOARD_USES_RECOVERY_AS_BOOT is true).
* $OUT/recovery/root/first_stage_ramdisk/init
* $OUT/recovery/root/system/bin/init
The first one is not needed because there is already a symlink
under $OUT/recovery/root: init -> /system/bin/init.
Bug: 193565271
Test: `lunch aosp_flame-userdebug`, `make bootimage_debug` then
checks the output under $OUT/debug_ramdisk/.
Test: Performs the same check for `lunch aosp_bramble-userdebug`.
Change-Id: I6277a6c4c0980bd976cc35db6ca99eafc6bf3f5a
This has kept adb_debug.prop from being installed for
legacy devices with BOARD_USES_RECOVERY_AS_BOOT set to
true.
Bug: 192432810
Bug: 193291885
Test: `lunch aosp_flame-userdebug` and checks `get_build_var
BOARD_USES_RECOVERY_AS_BOOT` is true.
Test: `make bootimage_debug` then checks
$OUT/debug_ramdisk/adb_debug.prop exists
Test: build/soong/build_test.bash --dist --incremental
Change-Id: I28e2c082512791407167b610843f18731ed6d673
If a bootconfig argument has a list of values, it has a space between
them in /proc/bootconfig.
Example:
BOARD_BOOTCONFIG := parameter=value1,value2,value3
In /proc/bootconfig, it looks like:
parameter = "value1", "value2", "value3"
Before this CL, that example would end up with the value string of:
"value1, value2, value3"
To keep consistent behavior with kernel cmdline the value string should be:
"value1,value2,value3"
Test: Boot cuttlefish with test bootconfig params and verify ro.boot.*
Bug: 192257482
Change-Id: Iccdec451f53330162fa2c9ad2b7c2630f32b4168
