Only happens if you're put()ing and clear()ing the map from
different threads, and Dianne told you not to do that.
In addition to avoiding the cache poisoning that results
from concurrent access, ArrayMap now attempts to throw
ConcurrentModificationException if clear() or
ensureCapacity() or put() notices you've modified the map
elsewhere.
Bug: 32994281
Test: runtest -x frameworks/base/core/tests/coretests/src/android/util/ArrayMapTest.java
runtest -x cts/tests/tests/util/src/android/util/cts/ArrayMapTest.java
Change-Id: Ia75970aa9e2b2b65692179f51243584b9773797f
Clean-up before actual fix for b/36897968 that makes the code easier to
follow.
Test: Existing tests pass
Bug: 36897968
Change-Id: I3039548929440f922dc69d7f130169a3d60b1eef
* changes:
Fix broken CTS tests.
Draw a default focus highlight if needed.
Add a public API defaultFocusHighlightEnabled.
Detect unhandled keyboard focused state.
(cherry picked from commit 8143fa57ad)
There is no longer a name size limit to the properties, remove
illegalArgumentException if tag length is too large.
Test: build
Bug: 36696208
Change-Id: I4b4329c8c951082ed0d777cdd70ee3e773bed16c
A View uses a Drawable as its background, which changes
its appearance according to the View's state. This commit
adds an algorithm to detect undefined state_focused in
state specs for those Drawables.
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsGraphicsTestCases
-t android.graphics.drawable.cts.DefaultFocusHighlightTest
Bug: 35096940
Change-Id: I5e9f07141679881fe88f9040aa116ea2f9d537c9
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
