Since new files can be introduced to /metadata after the initial
restorecon, we need to skip hashing.
Bug: 150907679
Test: rollback, ls -lZ /metadata/ota
Change-Id: I1f928f519ae2c75aeedb74b70d513743e86bcf2b
Merged-In: I1f928f519ae2c75aeedb74b70d513743e86bcf2b
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
A previous version of this change was reverted and added locks around
all service operations and allowed the property thread to spawn
services directly. This was complex due to the fact that this code
was not designed to be multi-threaded. It was reverted due to
apparent issues during reboot. This change keeps a queue of processes
pending control messages, which it will then handle in the future. It
is less flexible but safer.
Bug: 146877356
Bug: 148236233
Bug: 150863651
Bug: 151251827
Test: multiple reboot tests, safely restarting hwservicemanager
Merged-In: Ice773436e85d3bf636bb0a892f3f6002bdf996b6
Change-Id: Ice773436e85d3bf636bb0a892f3f6002bdf996b6
(cherry picked from commit 802864c782)
This is apparently causing problems with reboot.
This reverts commit d2dab830d3.
Bug: 150863651
Test: build
Merged-In: Ib8a4835cdc8358a54c7acdebc5c95038963a0419
Change-Id: Ib8a4835cdc8358a54c7acdebc5c95038963a0419
create new profiles to allowing thawing and freezing back the freezer
cgroup
Bug: 151225245
Test: Manually verified that using the SetTaskProfiles method on the
profiles thaws and freezes back the freezer cgroup.
Change-Id: I7f3e193ebe79b49c1f6ac52b6138ff4ec26fc570
__ANDROID_API__ isn't defined on host, so this check will fail due to
-Wundef. The || is short circuited through, so we can check for host
first and only have the right side of the || evaluated for device
builds.
Bug: 150898477
Bug: 151255209
Test: build
Merged-In: I2e0bc055ac0c7ba8262875801cdaed9cc30d2cef
Change-Id: I2e0bc055ac0c7ba8262875801cdaed9cc30d2cef
(cherry picked from commit 227ac56454)
As requested during the API review.
Bug: 150898477
Test: liblog and libbase unit tests
Merged-In: Id67203bbfbc3e116b6b6efd40428afe48203dcfc
Change-Id: Id67203bbfbc3e116b6b6efd40428afe48203dcfc
(cherry picked from commit 6085cd5a64)
As requested during the API review.
Bug: 150898477
Test: liblog and libbase unit tests
Merged-In: I0c1dd57f7499e432bb881e1da1beb55f1ff7de05
Change-Id: I0c1dd57f7499e432bb881e1da1beb55f1ff7de05
(cherry picked from commit f1a975bece)
This steps up our garbage collection threshold over time when mounting
userdata with checkpointing=disable for f2fs. With this scheme, we step
up the percent of disk we will tolerate being unusable during
checkpointing. At 100%, the filesystem will be able to always mount.
This means we will attempt to mount at most 10 times, for a max time of
about 50 seconds.
Also logs mount time under ro.boottime.init.mount.[target]
If the device does not support checkpoint=disable:[n%], it will mount
with checkpoint=disable, which is equivalent to checkpoint=disable:0%
Test: Boot in checkpointing mode
Bug: 150506496
Change-Id: I047ff98513f4ea832e1216b91e454a57fd2e8bf6
To be submitted along with changes in apksigner tool and the framework.
Merged to AOSP after that.
Test: adb install --incremental <apk>
go/apk-v4-signature-format
Bug: b/151241461
Change-Id: I26e187f8e389e31e2759037057b96fc6c9cb1e94
libselinux is currently being copied to APEXes. This is risky because
the library is not designed to be portable; part of it is tied to the
specific version of the Android that it was developed for.
This change fixes the problem by declaring that the library supports
a stub with the list of C APIs that are included in the stub. Then there
is only one copy of libselinux in /system/lib and other APEXes use the
copy by dynamically linking to it.
Also, adbd no longer statically links to it, because doing so brings
libselinux in it.
Bug: 151053366
Test: m com.android.adbd. It doesn't include libselinux in it.
Test: m com.android.adbd-deps-info. then inspect
out/soong/com.android.adbd-deps-info.txt. The dependency to libselinux
is shown as '(external)'.
Exempt-From-Owner-Approval: cherry-pick from AOSP
Merged-In: If418cbe3abdeacb759d59052e6dca4c2067678dd
(cherry picked from commit 3ffdad0cb5)
Change-Id: If418cbe3abdeacb759d59052e6dca4c2067678dd
Refactors implementation details to allow for atom-level annotations.
This CL does not change the API surface. addBoolAnnotation and
addInt32Annotation work for both atom-level and proto field annotations.
Test: bit libstatssocket_test:*
Bug: 151158794
Change-Id: I2c340b201aeb3bcddd5cfde171b7c4df1d8d69a4
There is a longstanding bug where file-based encryption causes spurious
SELinux denials of module_request because it uses the kernel's crypto
API, and the crypto API tries to autoload kernel modules.
While this sometimes indicate missing kconfig options, it can still
happen even if all needed kconfig options are enabled. This is because
a crypto algorithm can be a composition like "hmac(sha512)", and the
crypto API will first look for the full composition before it
instantiates it using the components like "hmac" and "sha512". But
often an implementation of the full composition doesn't exist.
However, as far as I can tell, Android doesn't actually use kernel
module autoloading at all. First, Android never changes
/proc/sys/kernel/modprobe from the default of "/sbin/modprobe", yet this
isn't where modprobe is located on Android. Android's SELinux policy
contains a neverallow rule that ensures that only init (not even
vendor_init) can write to this setting, so vendors can't be changing it.
Vendors could potentially be setting CONFIG_STATIC_USERMODEHELPER_PATH,
which overrides the path of all usermode helpers including modprobe.
But this is a relatively new kconfig option, available only in
android-4.14 and later. Also, for a vendor to actually do this they'd
also need to extend the SELinux policy with a domain_auto_trans rule to
allow their usermode helper to be executed by the kernel.
Android does increasingly use kernel modules, and GKI (Generic Kernel
Image) will require them. However, the modules are actually inserted by
userspace by 'init', not autoloaded.
It's possible to disable kernel module autoloading completely by setting
/proc/sys/kernel/modprobe to an empty string. So, let's do that.
This prevents lots of spurious SELinux denials, and allows removing
unnecessary rules to allow or dontaudit the module_request permission.
Note: when the kernel doesn't have CONFIG_ANDROID_BINDERFS enabled, this
change exposes a kernel bug that causes a WARNING in get_fs_type(). To
avoid this WARNING, a kernel fix should be applied too -- currently
under discussion upstream
(https://lkml.kernel.org/r/20200310223731.126894-1-ebiggers@kernel.org).
Bug: 130424539
Bug: 132409186
Bug: 144399145
Bug: 146477240
Bug: 148005188
Bug: 149542343
Test: Tested on cuttlefish and coral:
- Checked that /proc/sys/kernel/modprobe contains /sbin/modprobe
before this change, and the empty string after.
- Checked that if all SELinux rules for module_request are removed,
there are SELinux denials for module_request before this change
but none after.
- Ran lsmod both before and after and verified that the list is the
same, i.e. checked that this change doesn't break how Android
actually loads kernel modules.
Change-Id: I4132fe1a491e7b789311afcf693c1f6493fb9dc5
Merged-In: I4132fe1a491e7b789311afcf693c1f6493fb9dc5
... so that an operation can be skipped partially. For example, if
an operation contains blocks:
563412 -> 123456
... then optimized operation is:
5612 -> 1256
Test: update_engine_unittests
Test: apply incremental OTA
Bug: 148623880
In an experiment, this reduces CoW size of an incremental update
package by 200MB (out of 700MB).
Change-Id: I86ca23fd589ddbc84c81318283b5f4e71782a759
Merged-In: I86ca23fd589ddbc84c81318283b5f4e71782a759
For currently unknown reasons, sideloading is broken with
libadbd_services as a cc_library_static.
Partial revert of commit a9b62d5452.
Bug: http://b/151056300
Test: xunchang@ tested manually
Change-Id: Iaffad9c476ba0adcffc5db512ba4a7ee0fb5cb22
(cherry picked from commit 7f8a37c8c7)
In case of GSI on DSU, /data is mounted on the following stack:
userdata -> userdata_gsi -> actual block device, and fstab returned from
ReadDefaultFstab() function will say that /data should be
mounted onto userdata_gsi. This configuration wasn't supported.
To support it, fs_mgr_get_mounted_entry_for_userdata now unwinds the
dm-device stack /data is mounted onto, and for each entry in fstab
resolves corresponding block device (in case of logical partitions by
asking DeviceMapper to resolve name -> path, and for other cases by
reading a symlink), and then checking whenever resolved block device
belongs to the unwinded stack.
Test: on both normal boot & DSU
Test: atest CtsUserspaceRebootHostSideTestCases
Test: atest CtsFsMgrTestCases
Bug: 148612148
Change-Id: I1bb3e64ae92d56de905b4f7f1997b7499b101b0f
liblog is a platform library that provides stable C API. There is no
need to include the library, especialy by statically linking to it, in
any APEX. It not only wastes the storage/ram, but also is incorrect
because the socket interface to logd which is implemented in liblog is
not guaranteed to be stable.
Fixing this issue by converting static_libs: ["liblog"] into
shared_libs: ["liblog"], in which case the dependency to the library
is satisfied via the stub variant of the library.
As a result, we could restrict the availablity of the library to
the platform and the runtime APEX.
Exempt-From-Owner-Approval: already approved when this was in internal
master (ag/10572699)
Bug: http://b/151051671
Bug: http://b/150827719
Test: m
Merged-In: I5aab863cb12b8767b6979255c247000a59355b0e
(cherry picked from commit 95b6f45b0e)
Change-Id: I5aab863cb12b8767b6979255c247000a59355b0e
In case multiple threads try to reference this variable while it is
being set, it should be atomic so that all threads always see a valid
value.
Bug: 150898477
Test: liblog, libbase unit tests
Merged-In: If6c9e291f2471b96a752dc6e76e3e63458b71391
Change-Id: If6c9e291f2471b96a752dc6e76e3e63458b71391
(cherry picked from commit bbb16022c7)
Replace the original on demand start mechanism with the new dynamic
AIDL service infrastructure to resolve a possible race condition.
Bug: 149130673
Test: gsi_tool status
Merged-In: Ia5f32579a8dcf62d700d974c7f4e3c65647f3b8b
Change-Id: Ia5f32579a8dcf62d700d974c7f4e3c65647f3b8b
Previously, we were waiting for the other end to respond after every
file sent, which results in massive slowdown when there's any amount of
latency on the transport.
This improves performance on a cuttlefish instance with ~7ms RTT from:
system/: 2037 files pushed, 0 skipped. 2.8 MB/s (762803979 bytes in 262.964s)
to:
system/: 2037 files pushed, 0 skipped. 11.9 MB/s (762803979 bytes in 61.278s)
Bug: https://issuetracker.google.com/150827486
Test: ./test_device.py
Change-Id: I3a0c893faa5d455cc6ccbc86915a17e1b5abbfbe
(cherry picked from commit 64ff82ba68)
When libbacktrace.a is statically lined to somewhere, that library had
to add libasync_safe.a to static_libs because libbacktrace.a has
references to libasync_safe.a. But libbacktace depending on
libasync_safe is an implementation detail of libbacktrace, and therefore
its client shouldn't be affected by it.
Fixing this by doing the whole static link to libasync_safe to
libbacktrace.a so that the former is included in libbacktrace.a
Bug: 149569129
Test: m
Change-Id: If7366a240bc945dda9944fe7c111e10d328165bb
libbase is a popular library that is used by many APEXes either directly
or transitively. It is being used by several Mainline modules that were
launched with Q, in which case everything in the APEX - including
libbase - shouldn't use new APIs that are added post Q, i.e. R.
libbase however is using a few new R symbols from liblog, and this is
preventing those Q-launching Mainline modules that are built in R source
tree from being installed to Q devices.
Fortunately, the dependencies to the new R symbols are guarded with a
flag; when the existence of the symbols are not guaranteed, it uses
dlsym. This change fixes the aforementioned problem by turning on the
flag also when libbase is built for an APEX.
Bug: 149569129
Test: TARGET_BUILD_APPS=com.android.media
vendor/google/build/build_mainline_modules.sh
adb install --staged out/dist/mainline_modules_arm64/com.android.media.apex
adb reboot
The APEX is installed and mediaextractor process doesn't crash
Change-Id: I44b5ec028850613cb45fc3e792f43cd8e87cfd00
This reverts commit faa49d1d00.
Reason for revert: Callstack should not be logged.
Test: none
Bug: 148818798
Change-Id: Ie5506ae0c7408e255a464b2f403d0a47d272229e
Now that update_engine is responsible for initiating the
merge, InitiateMergeAndWait function becomes useless.
Bug: 147696014
Test: libsnapshot_test
Change-Id: I5473dc543ca8ac2fd31f597720847b02d0e5e33d
Also fixes a bug in the tests where the platform version was being
checked by querying version.release instead of version.codename
(currently, version.release == 10, while version.codename == R).
Test: bit libstatspush_compat_test:* (on Q and R)
Test: libsstatssocket.so is not placed in resolv apex (on R)
1|bonito:/ $ ls apex/com.android.resolv/lib64
libclang_rt.ubsan_standalone-aarch64-android.so
libcrypto.so
libnetd_resolv.so
libssl.so
Test: NETWORK_DNS_EVENT_REPORTED atom is logged to statsd (on R)
- adb shell cmd stats print-stats (atom 116 count > 0)
Bug: 148743333
Change-Id: Ib3eaa32835905bcf6e3b003054bf0f3c4e7ec0a4
Merged-In: Ib3eaa32835905bcf6e3b003054bf0f3c4e7ec0a4
(cherry picked from commit 9848eb4f1c)
