Should check ro.build.id instead of the ro.boot.build.id. The former
is a component of the build fingerprint.
Bug: 204507710
Test: run CtsInitTestCases
Change-Id: Iee13b30b195685c2461255f946685a288f352e06
This is required since Android 12, because
CtsNativeVerifiedBootTestCases will read property
"partition.${partition}.verified.hash_alg" to
check that sha1 is not used.
Also see https://r.android.com/1546980 for more details.
Bug: 175236047
Bug: 203720638
Test: build and boot a device
Change-Id: I300265f4af9c2781d40537f391bda9eaf62c27ba
ro.vendor.api_level must be the minimum of ro.product.first_api_level
and ro.board.(first_)api_level.
Bug: 202919753
Test: getprop ro.vendor.api_level
Change-Id: Ie70dd64b21c01ed8cd5e43b01095e1e0d8ff4444
Support an "init.#rc" versioning scheme for apex init files.
chooses highest # <= current system sdk.
".rc" (aka the old init.rc) is treated as sdk 0
Document these semantics in README.md
Bug: 198186200
Test: booting, lots of logcat output
Change-Id: I2d0405be73dae9bafa6f22535b29ed6b053ddbc4
This property will hold the major.minor part of the kernel version (e.g. "5.4"), allowing init scripts to act depending on that version, enabling and disabling certain features.
Bug: 194156700
Change-Id: Icec640b8a7150b344d9aa3bc0bdbcdae050c7c45
Test: manual on a Pixel device
Signed-off-by: Alexander Potapenko <glider@google.com>
vendor_init is a subcontext of init which is responsible for handling
the vendor-defined services and vendor-defined actions. This is mainly
to enforce the Treble architecture in which the vendor components are
provided with a less-privileged context than the system components
because they are less-trusted.
However, in case of microdroid, both the system and the vendor
partitions are from the same entity. As VMs don't have direct access to
any of the underlying hardware, the vendor partition is targeting the
virtual platform, not the real hw platform. There really is no need for
the discrimination.
This CL disables the creation of the vendor_init subcontext when init
runs in microdroid.
Bug: 201363575
Test: atest MicrodroidHostTestCases
Change-Id: Ie5e47d84e9e245565239b4f2159e8182b457699d
This test requires running test services, which causes test to crash
(and still incorrectly be reported as passing) when running on
non-rooted device.
Ignore-AOSP-First: reboot_test is not in AOSP yet
Bug: 190958734
Test: atest CtsInitTestCases
Merged-In: I3c5c9917d0a787d66272ccf4aefc57e6573841bc
Change-Id: I3c5c9917d0a787d66272ccf4aefc57e6573841bc
This test spawns several services backed by /system/bin/yes executable,
and then stops them either while SIGTERM or SIGKILL.
Ideally we want to unit test more of reboot logic, but that requires a
bigger refactoring.
Test: atest CtsInitTestCases
Bug: 170315126
Bug: 174335499
Merged-In: Ife48b1636c6ca2d0aac73f4eb6f4737343a88e7a
Change-Id: Ife48b1636c6ca2d0aac73f4eb6f4737343a88e7a
ro.vendor.api_level will have the api_level that the vendor images
are required to implement based on the various api level properties.
ro.board.api_level and ro.board.first_api_level explicitly states
the api level of the vendor images for grf.
If these properties are not provided, it reads the device's launching
api level.
The rest of the properties may show the implemented api level of the
vendor images.
Bug: 200258600
Test: getprop ro.vendor.api_level
Change-Id: Id4131b53d6db00d5bbef3b048384d33c1736d681
This change only *adds* /system_ext/etc/selinux to the debug policy
search path, and does not change any preconditions to load the debug
policy. The device still needs to be bootloader-unlocked and has the
debug ramdisk flashed to be able to use the debug policy. The only thing
changed is that now the debug policy can be loaded from /system_ext or
/debug_ramdisk when system partition is compliance testing GSI.
The debug policy in the boot ramdisk may be outdated if the system
partition is flashed with a image built from a different revision.
This happens frequently when running the compliance testing VTS, where
the device is flashed with (A) GSI and (B) device vendor image & debug
boot image, and (A) and (B) are built from different git revisions.
To address this, we install a copy of the debug policy under
/system_ext, so that the version desync between (A) & (B) wouldn't be a
problem anymore because (A) no longer relies on the debug policy file
from (B).
Bug: 188067818
Test: Flash RQ2A.201207.001 bramble-user with debug ramdisk & flash
gsi_arm64-user from master, device can boot and `adb root` works
Change-Id: Ibe17eb1ecb0e813309c9596d1f152b7455686b26
Revert "Add a copy of debug policy to GSI system image"
Revert "Add PRODUCT_INSTALL_DEBUG_POLICY_TO_SYSTEM_EXT"
Revert "Add system_ext_userdebug_plat_sepolicy.cil for GSI"
Revert submission 1824717-gsi_debug_policy
Reason for revert: Breaks the build (see b/200933187).
Reverted Changes:
I37ef02628:Add a copy of debug policy to GSI system image
I9c3dad8bb:Add PRODUCT_INSTALL_DEBUG_POLICY_TO_SYSTEM_EXT
I43adc6ada:Add system_ext_userdebug_plat_sepolicy.cil for GSI...
I4d6235c73:Add /system_ext/etc/selinux/ to the debug policy s...
Change-Id: I2eb3b00abb981c25514b75b2e7b4b7b203653390
This change only *adds* /system_ext/etc/selinux to the debug policy
search path, and does not change any preconditions to load the debug
policy. The device still needs to be bootloader-unlocked and has the
debug ramdisk flashed to be able to use the debug policy. The only thing
changed is that now the debug policy can be loaded from /system_ext or
/debug_ramdisk when system partition is compliance testing GSI.
The debug policy in the boot ramdisk may be outdated if the system
partition is flashed with a image built from a different revision.
This happens frequently when running the compliance testing VTS, where
the device is flashed with (A) GSI and (B) device vendor image & debug
boot image, and (A) and (B) are built from different git revisions.
To address this, we install a copy of the debug policy under
/system_ext, so that the version desync between (A) & (B) wouldn't be a
problem anymore because (A) no longer relies on the debug policy file
from (B).
Bug: 188067818
Test: Flash RQ2A.201207.001 bramble-user with debug ramdisk & flash
gsi_arm64-user from master, device can boot and `adb root` works
Change-Id: I4d6235c73472e4d97619b2230292e6a0bc4b3e05
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
