1. Listen to calling package binder death stopping the scanning on that.
2. Don't restart scanning when a request with the same values was made.
Bug: 30932767
Test: 1.:
- Using a test app start scanning and kill the app.
- In debug mode ensure that DeviceDiscoveryService#stopScan gets triggered
2.:
- Start scanning and rotate the device while device chooser is visible
- Ensure no visible loss of state is happening
Change-Id: If126a2c963da90172a956fbd88e6b3dcd7ac8b01
The method was confusing and not used by anyone. Same functionality can
be implemented trivially in the client code.
Test: N/A
Bug: 35765468
Change-Id: Ia019088cd023c62d83760d9ebe883f7559a43375
Example: If we got a batch with timestamps [1, 4, 8] and an event
with timestamp 7 was delayed and was added to the buffer later,
if we request the next batch starting from timestamp 8 or 9 that
event will be lost.
The last 3 seconds of events are kept and checked against the next
batch.
Test: afw-test-tradefed-ci run afw-do-security-logging
Change-Id: I55727cfc6143c172edc7dabfd995776f9a0f7eab
Bug: 35373582
Bug: 35026180
Bug: 35648675
There is some flakiness in View#onConfigurationChanged callback -
if ViewRootImpl receives config update earlier than ActivityThread,
it may not detect the configuration change and skip inner updates.
Also now ViewRootImpl assumes that it receives the global config as
a param, but instead it gets merged config from WM. This means that
ViewRootImpl#sConfigCallbacks was sending incorrect values to the
recipients.
This CL switches to sending global and override configuration to the
client separately. Also in case if there is a corresponding activity,
it first updates it and waits for update callback to ViewRootImpl.
This way global config and override config for activity will always
be set first and resources will be updated before inner state of
ViewRootImpl is updated.
Bug: 35870157
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: testOnMovedToDisplayCallback
Change-Id: Ic9e7541cf25ecfac6ec90e48f7efb0ece91f657e
b/36088922
Test: Settings app
This utility class can be used to bake shadow in drawable level in
system ui surfaces such as Settings, Overview and ShareSheet.
Change-Id: Iaec867d9ce5b949380c1e5004b68269d1bbeacd4
This is unsafe because the random will be seeded in the zygote, which
means all processes on the system generate the same sequence of random
numbers. Fortunately, this code is only used in tests, so get rid of it.
Note that the Random that backs Math.random() is reseeded after every
fork to avoid a similar issue.
Bug: 35918685
Test: HwAccelerationTest
Change-Id: Ice79aa25bb9017f7a0b91659afe04112850cb74b
Prior to this CL, MapCollections such as ArrayMap's entrySet,
keySet and values, exhibited unusual Iterator behavior:
- instead of throwing NoSuchElementException once the end of
the Collection was reached, Iterator.next() instead returned
a null key / a null value / an entry with a null key and value.
- however, remove() removed the last actual element of the
Collection; successive calls of next(), remove() would
result in successive elements being removed, in reverse
iteration order.
- Once the Collection had been cleared through calls to remove(),
ArrayIndexOutOfBoundsException was thrown from iterator.next()
(for keySet and values) or from iterator.remove (for entrySet).
This CL fixes those Collections' Iterators to let next() throw
NoSuchElementException when hasNext() would have returned false.
Since the new behavior was already guaranteed by the Iterator
documentation, any app compatibility effect from this CL is both
unlikely, and unlikely to be negative.
Bug: 19853326
Test: make cts && cts-tradefed run cts -m CtsUtilTestCases
Change-Id: Ie3f0594f434dd5625799791829bd94fbaef94906
Bug: 30932767
Test: Ensure file not exists -> query associations -> ensure result is empty list
Associate device -> cat xml file -> ensure record appears as extected
Disassociate device -> cat xml file -> ensure record is no longer present
Change-Id: Ibe456a6d9292e05e2391f5138e43fdaa37f87e1b
Do not use Pattern.toString to construct complex patterns. Instead,
make the string literals explicit so they can be compile-time
allocated, thus ending up as clean memory in the image heap.
Bug: 34956610
Test: m
Test: Device boots
Change-Id: I20d45c31243af00168553c218f75fb0795b55149
AutoFillService can now require user authentication, both at
FillResponse and Dataset levels;
- FillResponse authentication is typically used when the user data
need to be unlocked before the first use.
- Dataset authentication is typically used to unlock sensitive data
such as credit card info.
The authentication can be handled by the service itself (for example,
when it uses the credit card CVV to unlock it) or by the Android
system (when the service asks for fingerprint authentication).
Bug: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: If62f42f697ab5ef0d14d991ff1077d1c38808e61
Activity manager now has constants, starting with two: bg check
and process limit.
Power manager now has constants, starting with one: controlling
disabling of wake locks from cached processes.
Test: manual
Change-Id: I05db42e2104e9d31584f85251412df2d5efb34b6
- Use 32 byte key instead of 16 byte.
- Use HMAC-SHA256 instead of SHA256 for ssaid generation.
- Update HMAC with all package signatures.
- Use delimiter in between digest arguments.
This change will cause the ssaid of non-legacy installed apps (apps installed
post Android ID migration OTA) to change after an uninstall and reinstall sequence.
Bug: 34395671
Test: Unit tests, CTS tests, Manual tests
Change-Id: I19dec57947368ee5000c2c630b1e4030d46a4ab3
SSAID is currently shared across all applications for each
user on the device, giving developers the ability to track
users across multiple applications. Using SSAID for tracking
is an abuse of the original intention of the SSAID and has
inherent privacy concerns.
This change will make the SSAID unique per application, per
user on a device. To not affect applications installed prior
to this change they will retain the legacy SSAID value until
uninstalled and reinstalled again.
Across subsequent installations the application will receive
the same SSAID as long as the package name and signature remain
consistent.
Tested manually the following cases:
- App retains the legacy sssaid after OTA.
- App gets a new ssaid upon post-OTA installation.
- App retrieves same ssaid across post-OTA unistall/reinstalls.
- Different Apps receive different ssaids.
- Factory reset removes ssaid data and generates a different
ssaid after App install.
- System retains legacy ssaid.
Bug: 34395671
Test: CTS tests passed, Manual testing passed
This reverts commit be43257005.
Change-Id: Ibf20e7949304c30d65bb8aa24cdbbe6e104b1002
If an Exception thrown by a Binder call implements the Parcelable
interface, then parcel it and rethrow back at the caller. There is
strict requirement that these Parcelable exceptions must be defined
by the system (as determined by checking the ClassLoader). We prefix
the Parcelable contents with a length so that native code can skip
over the blobs.
Define a new ParcelableException class that can be used to transport
exceptions that cannot be modified to add Parcelable behavior, and
switch ExceptionUtils to use this new class for sending IOExceptions.
Test: builds, boots, wrapped exceptions work
Bug: 33749182
Change-Id: I1352ea1566ddf01120d9d0e819ba6f70fc407e11
SSAID is currently shared across all applications for each
user on the device, giving developers the ability to track
users across multiple applications. Using SSAID for tracking
is an abuse of the original intention of the SSAID and has
inherent privacy concerns.
This change will make the SSAID unique per application, per
user on a device. To not affect applications installed prior
to this change they will retain the legacy SSAID value until
uninstalled and reinstalled again.
Across subsequent installations the application will receive
the same SSAID as long as the package name and signature remain
consistent.
Tested manually the following cases:
- App retains the legacy sssaid after OTA.
- App gets a new ssaid upon post-OTA installation.
- App retrieves same ssaid across post-OTA unistall/reinstalls.
- Different Apps receive different ssaids.
- Factory reset removes ssaid data and generates a different
ssaid after App install.
- System retains legacy ssaid.
Bug: 30979321
Test: CTS tests passed, Manual testing passed
Change-Id: I4acc190c14ec249e6365e05e7943148ed6f17f71
This fixes two cosmetic issues in APK Signature Scheme v2 signature
verifier in Android Package Manager:
* Accept APKs with ZIP End of Central Directory comment of length
65535. Previously, only comments of length 65534 were accepted due
to a off by one bug.
* Accept APKs with empty ZIP Central Directory.
These issues should not affect actual APKs because they cannot have an
empty ZIP Central Directory (they must contain at least the
AndroidManifest.xml entry) and shouldn't contain any comments in ZIP
End of Central Directory.
Test: cts-tradefed run singleCommand cts --skip-device-info --skip-preconditions --skip-connectivity-check --abi arm64-v8a --module CtsAppSecurityHostTestCases -t android.appsecurity.cts.PkgInstallSignatureVerificationTest
Change-Id: I461c43472fa97c04e7579d129a6053e44233adb7
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ibf56827209a9b791aa83ae679219baf829ffc2ac
