ro.boot.hardware.cpu.pagesize is used on some devices to
report the page size. However, we also know what value this
should be from the CPU. Rather than create a separate property
for this, standardize around this property.
This also allows us to test the value of this property on all
devices.
Bug: 358696947
Test: Vts16KPageSizeTest
Change-Id: I7f6260c68e17e7df8a789e9066a7171f3a56f4b0
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
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
Devices may predefine ro.vendor.api_level. Skip calculating the value
if the ro.vendor.api_level is already defined.
Bug: 326164316
Test: getprop ro.vendor.api_level
Change-Id: Ic9fd2a0eef6ba9345f98a5cb1eb790080e19ca19
Remove temporary 'vendor_api_level_of' function from init and replace
the function with the same in libvendorsupport.
Bug: 312403948
Test: getprop ro.vendor.api_level
Change-Id: I095353e602397220571e131431e7cbd1b8511fa6
Merged-In: I095353e602397220571e131431e7cbd1b8511fa6
In Android V, ro.vendor.api_level read ro.board.api_level only if
ro.board.first_api_level is defined. The format of the vendor api
level is YYYYMM.
Update the ro.vendor.api_level initialize funtion with this change.
As ro.product.first_api_level follows the version from the SDK, a
new function `vendor_api_level_of` translates the SDK version to the
vendor API level.
Bug: 312403948
Test: getprop ro.vendor.api_level
Change-Id: I2961ed9a6de8e9156f72c1bbfeabcac9c35f08fb
unit tests
1, Previous implementation has the staged prop application done in
property_service, which caused a number of unnecessary changes which
including exposing apis like AddPersistentProperty. In addition, it made
the property_service logic complicated. A better design is to have the
staged value application done while reading the persistent properties
from file. This way, no change to property service. In addition, unit
test is much cleaner and efficient.
2, add a unit test to lock down the behavior. Specifically, it locks down that when a prop is staged, it should be applied the next time when the persistent prop is loaded. In addition, it should lock down that other persistent props are not overwritten.
Bug: b/307752841, b/300111812, b/306062513
Change-Id: I43c603efbb803195065dda3f0bc2145716302bbc
This fixes a bug introduced by I81b6bd984aad8f7ddec93ce74f4543e4f71be508
In the original CL, setting a sysprop `next_boot.<name>` and then
rebooting the device could remove all the persistent properties stored
in /data/property/persistent_properties. It happened because the
function `WritePersistentProperty` is called with a properties set which
is initialized as an empty set and then added with the properties which
had the next_boot prefix.
As a result...
Before the boot:
* persist.a = 1
* next_boot.b = 2
* next_boot.persist.c = 3
After the reboot:
* b = 2
* persist.c = 3
persist.a gets lost.
This change fixes the issue by populating properties set from the memory
and then save it to the file.
Bug: 306062513
Bug: 300111812
Test: do the following.
$ adb root
$ adb shell setprop persist.a 1
$ adb shell setprop next_boot.b 1
$ adb shell setprop next_boot.persist.c 1
$ adb reboot
$ adb shell getprop persist.a
1 // was (none) before this change
$ adb shell getprop b
1
$ adb shell getprop persist.c
1
$ adb reboot
$ adb shell getprop persist.a
1 // was (none) before this change
$ adb shell getprop b
// (none) because b isn't persisted. WAI.
$ adb shell getprop persist.c
1
Change-Id: I85d3777f9b32523b010e49b8ca53f4319dd2ce05
Certain applications may have their system properties overlaid with the
contents overlaid for appcompat purposes. Init must initialize the
appcompat folder, same as it does the standard folder.
Bug: 291814949
Test: manual
Change-Id: I6d239e0a10a1c81a05d4121e5fc2c41da5b3dbc4
Merged-In: I0c6a0f66dc543c6e861bc86a417e4feb5ecd7789
Certain applications may have their system properties overlaid with the
contents overlaid for appcompat purposes. Init must initialize the
appcompat folder, same as it does the standard folder.
Bug: 291814949
Ignore-AOSP-First: must be merged with ag/24558703, which has an Aosp -> internal merge conflict
Test: manual
Change-Id: I0c6a0f66dc543c6e861bc86a417e4feb5ecd7789
Right now there are two bootconfig parsers that gets linked into `init`.
One is from libinit itself and the other is from libfs_mgr.
The one in libinit removes all space characters between list elements,
so `key = "val1", "val2"` gets unquoted and squeezed into:
`key=val1,val2`
The one in libfs_mgr doesn't remove spaces, it only unquotes:
`key=val1, val2`
The libinit behavior is due to existing systems (such as sysprop)
expect the config value to be in the same format as kernel cmdline.
(aosp/1757971)
THe libfs_mgr behavior is due to the `androidboot.boot_device[s]`
format explicitly allows quoted comma appear in its list value, thus
relies on space, not comma, as the list value delimeter.
This commit merges the two parsers into libfs_mgr. Since all usages in
libfs_mgr besides `boot_device[s]` do not care about how list value are
delimited, and most usages in init expects the bootconfig value format
to be the same format as cmdline. We just special case the
`boot_device` scenario.
Also harden the test cases to cover all the different config value
format and expected result.
Note:
The format of kernel bootconfig is described here
https://docs.kernel.org/admin-guide/bootconfig.html
Bug: 293695109
Test: CtsFsMgrTestCases
Change-Id: I42b9bf626e8de38a60e8e09fac0693126b7efd91
init and libfs_mgr both defines get_android_dt_dir() with subtle
differences. Merge the two implementations into libfs_mgr to reduce code
duplication (in terms of source code and code gen)
Note:
init's implementation checks the kernel cmdline first and then the
kernel bootconfig, while libfs_mgr's order is the opposite.
Realistically I don't think this order matter much though. If any, we
should prioritize bootconfig over kernel cmdline most of the time.
Bug: 293695109
Test: Presubmit
Merged-In: Ic8d2c965c62f9e873ccdaf77d67c7708f25a7b56
Change-Id: Ic8d2c965c62f9e873ccdaf77d67c7708f25a7b56
init and libfs_mgr both defines get_android_dt_dir() with subtle
differences. Merge the two implementations into libfs_mgr to reduce code
duplication (in terms of source code and code gen)
Note:
init's implementation checks the kernel cmdline first and then the
kernel bootconfig, while libfs_mgr's order is the opposite.
Realistically I don't think this order matter much though. If any, we
should prioritize bootconfig over kernel cmdline most of the time.
Bug: 293695109
Test: Presubmit
Change-Id: Ic8d2c965c62f9e873ccdaf77d67c7708f25a7b56
(cherry picked from https://android-review.googlesource.com/q/commit:d7c67b40a9b6a5e72d54adf37da22238381182f7)
Ignore-AOSP-First: Fix merge conflict
It is easy to dos the property_service socket, since it will wait for a
complete data packet from one command before moving on to the next one.
To prevent low privilege apps interfering with system and root apps,
add a second property_service socket that only they can use.
However, since writes to properties are not thread-safe, limit use of
this second socket to just sys.powerctl messages. These are the messages
that this security issue is concerned about, and they do not actually
write to the properties, rather they are acted upon immediately.
Bug: 262208935
Test: Builds, boots
Ignore-AOSP-First: Security fix
Change-Id: I32835de31bb42c91b6479051ddf4b26b5c0b163f
This reverts commit 90879edeea.
These fixes for b/262208935 introduced a race condition. We believe the
race is fixed by ag/23879563, but at this point in the release feel that
reverting the fixes and refixing in main is the better solution
Test: Builds, boots
Bug: 283202477
Bug: 288991737
Ignore-AOSP-First: Reverting CL only in internal
Change-Id: I28491e90847f6aa0c9767b27e1d99190637048b9
