Update documentation for methods areAllEffectsSupported and areAllPrimitivesSupported to explain the default behavior for empty queries. The behavior remains unchanged.
Change-Id: I23dd792af7e3ee2c70fec136fb7db4965a7195be
Fix: 237509304
Test: N/A
Migrates getDefaultVrComponents used by SettingsProvider and
adds a flag for hidden API enforcement to ApplicationInfo.
This removes any dependency on SystemConfig from core/ and
so it can be moved into services/core and exposed as a
mainline API.
This was done instead of exposing all of the methods through
SystemConfigManager, as that is designed for use across
processes, and it's more efficient to expose SystemConfig
directly for modules running in the server process.
Although VrManager is a nullable service, so getDefaultVrComponents
had to live there to simplify the logic and maintain the existing
behavior.
Bug: 236389629
Change-Id: I4c2b14e1d34aaf439ceb1a3f9c8207e5d39fa6c2
asleep.
This allows us to enter the dream directly while the device is off, instead of needing to wake the device before entering dream.
Bug: 246472225
Test: adb shell cmd dreams start-dreaming (while device asleep)
Test: atest PowerGroupTest
Change-Id: Id4634f3d5f7c3ae324f85f11a6991f0cab068a7d
Add check for state change in SystemVibrator implementation for
OnVibratorStateChangedListener callbacks on devices with more than one
vibrator. The registered listener should be notified only once for
each state when any vibrator starts or stops vibrating.
Fix: 249727855
Test: android.os.VibratorTest
Change-Id: Ied46ad70186a2df1c7aa24ccf04e5e8e05824876
Allow apps to trigger the dump of certain critical data, e.g. data stored in short
ring buffers that might get lost by the time a bugreport is requested.
Then, a bugreport request can specify whether the pre-dumped data should be used.
Fixes: 205138504
Test: atest com.android.os.bugreports.tests.BugreportManagerTest
Change-Id: I55c7b53e235ebf2baa694e6fdc4e4a321a459c8b
BatteryStats currently only stores the reason it receives from the
suspend control service. Starting with this change, batterystats will
now try to attribute these wakeups in more detail.
IRQ style wakeups where there has been an IRQ from a device get a
well structured reason string from the kernel. CpuWakeupStats will parse
it to get irq devices and then use irq_device_map xml to map the wakeup
to possible pre-defined subsystems that may have caused it.
Different parts of the system can use these subsystems to report any
associated activity (not to be confused with the class
android.app.Activity) tha could have caused a wakeup. CpuWakeupStats
will then attempt to associate this information with any wakeup that
may have occurred due to an IRQ from the relevant device.
This change defines the "Alarm" subsystem, and relies on the device
overlay to map this subsystem to the rtc device that ultimately enables
waking up the CPU when needed to process a wakeup alarm. Whenever there
is a batch of wakeup alarms that is dispatched, alarm manager notifies
batterystats (and hence cpuwakeupstats) of this "activity", which will
then try to associate it with any temporally proximal wakeups that have
happened due to the rtc device.
Currently, the information supported is only the uids that have
requested or initiated the activity from the subsystem that should be
blamed for the wakeup. But this can be extended to include more enum
style codes to represent other information.
Test: atest FrameworksServicesTests:IrqDeviceMapTest
Test: atest FrameworksServicesTests:CpuWakeupStatsTest
Bug: 249370357
Bug: 195684213
Change-Id: Idfbba82e9c007b5c9f15b9fd785b9a96cb202572
Apps are able to prevent their death by forking multiple processes
under different services and monitoring for the death of any of these.
When a child death is detected, the remaining process restarts the
terminating/terminated service before it's able to be killed itself.
This is now prevented by freezing the entire cgroup of the package to be
killed before killing the individual processes. After the kills are
completed synchronously, the cgroup can be unfrozen to allow for
restarts. Before freezing the cgroup, the binder interfaces of the
processes about to be frozen are also frozen to prevent indefinite
blocking by synchronous Binder callers.
Bug: 236708592
Bug: 148425913
Test: raven:/ $ monkey -p com.haok.nirvana 1
Test: bash arg: -p
Test: bash arg: com.haok.nirvana
Test: bash arg: 1
Test: args: [-p, com.haok.nirvana, 1]
Test: arg: "-p"
Test: arg: "com.haok.nirvana"
Test: arg: "1"
Test: data="com.haok.nirvana"
Test: Events injected: 1
Test: ## Network stats: elapsed time=14ms (0ms mobile, 0ms wifi, 14ms not connected)
Test: raven:/ $ ps -eo pid,uid,ppid,name|grep 10266
Test: 2499 10266 823 com.haok.nirvana
Test: 2577 10266 823 com.haok.nirvana:resident
Test: 2584 10266 823 android.media
Test: 2669 10266 1 app_d
Test: 2672 10266 1 app_d
Test: raven:/ $ am force-stop com.haok.nirvana
Test: raven:/ $ ps -eo pid,uid,ppid,name|grep 10266
Test: 1|raven:/ $
Test: atest PermissionControllerHostTest
Change-Id: I1718a9263a01d18da7e3d2e3771091cf8475e599
* changes:
Make the CE key always be encrypted by the synthetic password
Give all users SP-based credentials
Unlock user keys from LockSettingsService only
Merge WakeLock trace tracks into "WakeLocks" and SuspendBlocker tracks
into "SuspendBlockers" to create fewer tracks and make traces easier
to navigate.
Test: WakeLock/SuspendBlocker traces appear
Bug: 250614152
Change-Id: Ifadc31368d5ea3c5954aeef0d0d056a66ff94213
Addresses a security vulnerability where a (-8) length object would
cause dataPosition to be reset back to the statt of the value, and be
re-read again.
Bug: 240138294
Test: atest ParcelTest BundleTest AmbiguousBundlesTest
Test: manually ran PoC
Change-Id: I1ab1df6f2a802d8cdf02c89c12959b09d7b1a5c4
Merged-In: I1ab1df6f2a802d8cdf02c89c12959b09d7b1a5c4
Currently, whenever an LSKF isn't set, the CE key isn't encrypted by the
SP but rather by a non-auth-bound Keystore key. This is inconsistent,
and it's preventing us from taking advantage of the secure deletion
support of Weaver (on devices that support Weaver), with the current
scheme relying entirely on rollback resistance support in Keystore.
Therefore, make the CE key always be encrypted by the SP-derived key.
To do this, encrypt the CE key by the SP-derived key when the SP is
initially created. After the corresponding vold change, this will start
being the only time that the CE key is written to disk at all.
Also re-encrypt the CE key of existing users who don't have an LSKF, so
that we don't have to continue to support the legacy scheme.
Both operations are done via the new vold method setUserKeyProtection()
(accessed via StorageManagerService), which (re-)encrypts the CE key
using the given secret. The CE key must be either not-yet-persisted or
default-encrypted. This method replaces addUserKeyAuth(),
clearUserKeyAuth(), and fixateUserKeyAuth().
On the unlock side, make unlockUserKeyIfUnsecured() unwrap the SP and
unlock the CE key using it. As this makes
tryDeriveVendorAuthSecretForUnsecuredPrimaryUser() no longer needed,
remove that too.
Test: atest com.android.server.locksettings && \
atest com.android.server.am.UserControllerTest \
com.android.server.pm.UserManagerServiceTest \
com.android.server.pm.UserManagerTest
Test: Booted and rebooted Cuttlefish, both phone and auto builds
Test: Without the CLs in this topic, set up a Pixel 6 to have a user
with an LSKF, a user with no LSKF or SP, and a user with an SP but
no LSKF. Upgraded to the CLs in this topic. Checked log for
the expected messages from LockSettingsService. Verified that all
the users can still be unlocked. Verified that
/data/system_de/$userId/spblob exists for all users, and that
/data/misc/vold/user_keys/ce/$userId/encrypted_key exists but not
a keymaster_key_blob file alongside it. Verified that
/data/system/locksettings.db contains
migrated_all_users_to_sp_and_bound_ce=true.
Bug: 232452368
Change-Id: Ia753ea21bbaca8ef7a90c03fe73b66c896b1536e
In preparation for making the CE key of each user always be protected by
the user's synthetic password even when the user has no LSKF, make
LockSettingsService the sole caller of IStorageManager.unlockUserKey().
For the opportunistic secret-less unlock by UserController at user start
time, call a new method LSS.unlockUserKeyIfUnsecured(). For now this
method calls IStorageManager.unlockUserKey() with a null secret. Later
it will unwrap the user's synthetic password if needed.
For the unlock via credential verification that is triggered by LSS,
make LSS call IStorageManager.unlockUserKey() before calling
IActivityManager.unlockUser(), rather than passing the SP-derived secret
to IActivityManager.unlockUser() for it to do the unlockUserKey().
Since neither the secret nor the token arguments to
IActivityManager.unlockUser() are used anymore, add a new method
IActivityManager.unlockUser2() that lacks these arguments. Note that
method name overloading cannot be used because AIDL doesn't support it.
Test: atest com.android.server.locksettings && \
atest com.android.server.am.UserControllerTest \
com.android.server.pm.UserManagerServiceTest \
com.android.server.pm.UserManagerTest
Test: Boot and reboot Cuttlefish
Bug: 232452368
Change-Id: I8971b92bb5055fca8e19e0f9d14e8f0a7022b453
We have @NonNull annotations, but not everyone is watching the warning
messages related to them. Make the implementation a bit more robust
by swapping in the "(null)" literal when someone accidentally leaks
one through.
Bug: 249325721
Test: atest FrameworksCoreTests:TraceTest
Change-Id: Ic0f5a0236fbce88e086f3d68b2e5c6ed6b0aa33c
Modified remove user flow to delete the associated profiles when
deleting the user.
Test: atest UserManagerTest
Bug: 217758779
Change-Id: If0943cedd3892789f41cacbd4e0311fb9061b719
This API will get the advertised memory size from the bootloader parameter
passed to the kernel. The advertised memory size might be different from
the MemTotal value in /proc/meminfo. This could be due the original design
manufacturer (ODM) reserved part of the memory for the Trusted Execution
Environment.
Test: Run test caes
Bug: 231718727
Change-Id: I06494cb9013048d73a83f2180a9241c2259d46eb
The method parseSize() will parse the strings that match
the regular expression:
"^((\\s*[-+]?[0-9]+)\\s*(B|K|KB|M|MB|G|GB|Ki|KiB|Mi|MiB|Gi|GiB)\\s*)$"
For example: 12GB, +100MB, 23MiB.
It will return the size in bytes.
Test: atest
Bug: 231718727
Change-Id: Id4b9084d2ff8a0a8bd23ddb8a7e10dcf17391c49
Prior to this CL, WorkSources would Parcel their list of WorkChains as
-1 if null, or the size of the list followed by the list itself if
non-null. When reading it back in, on the other hand, they would check
if the size was positive, and only then read the list from the Parcel.
This works for all cases except when the WorkSource has an empty but
non-null list of WorkChains as the list would get written to the parcel,
but then never read on the other side.
If parceling a list was a no-op when empty this wouldn't be an issue,
but it must write at least its size into the parcel to know how many
elements to extract. In the empty list case, this single element is left
unread as the size is not positive which essentially corrupts any future
items read from that same parcelable.
Bug: 220302519
Test: atest android.security.cts.WorkSourceTest#testWorkChainParceling
Change-Id: I2fec40dfced420ca38e717059b0e95ee8ef9946a
Drop invalid data when writing or reading from XML. PersistableBundle
does lazy unparcelling, so checking the values during unparcelling would
remove the benefit of the lazy unparcelling. Checking the validity when
writing to or reading from XML seems like the best alternative.
Bug: 246542285
Test: install test app with invalid job config, start app to schedule job, then check logcat and jobscheduler persisted file
Change-Id: Ie817aa0993e9046cb313a750d2323cadc8c1ef15
