am: 1668ed9a0d -s ours
am skip reason: change_id Ia3ab1eb16aeaa85336409368b4340622cec19f4c with SHA1 7f6acc05db is in history
Change-Id: I9109e300ab64d84498f1da9ab245280cb0814a75
am: 73d03e3040 -s ours
am skip reason: change_id Ia3ab1eb16aeaa85336409368b4340622cec19f4c with SHA1 7f6acc05db is in history
Change-Id: I5e2ded289222e2b3eebc5f0b0159278e5a085fa9
am: 0fac2438a8 -s ours
am skip reason: change_id Ia3ab1eb16aeaa85336409368b4340622cec19f4c with SHA1 7f6acc05db is in history
Change-Id: I8003681eb772d66d7c32a5d0b13391ff05c77f47
am: ad9384ee97 -s ours
am skip reason: change_id Ia3ab1eb16aeaa85336409368b4340622cec19f4c with SHA1 7f6acc05db is in history
Change-Id: Id1098415941f1a4a318c8bf2b5d544cce333a0b7
am: 83bb512502 -s ours
am skip reason: change_id Ia3ab1eb16aeaa85336409368b4340622cec19f4c with SHA1 7f6acc05db is in history
Change-Id: Iee32d7f21321441ff96d096c685bd120a9133f44
am: 5567fc42b7 -s ours
am skip reason: change_id I851b819030a1da6091f5d6125a228bb01a99011b with SHA1 20bc2bf3f6 is in history
Change-Id: I98bbc92a080766fe4c8987da74a764778c0d72f6
Due to the expected BECOMING_NOISY behavior associated
with a device disconnection, the disconnection is handled
asynchronously after a fixed delay. This delay caused an
inversion of commands in the processing order of the
disconnection of a device closely followed by connection
of the same device.
The fix consists in:
- overriding the equals() operator for BtDeviceConnectionInfo
so messages for a given device in the message queue
can be checked / removed.
- when AudioDeviceBroker receives a command for A2DP
connection or disconnection, remove all upcoming connection
and disconnection commands in the queue for this device
(see postBluetoothA2dpDeviceConnectionStateSuppressNoisyIntent)
- remove AudioDeviceBroker.handleSetA2dpSinkConnectionState, which
was only used in BtHelper.onA2dpProfileConnected() with
a CONNECTED state, and have this method perform a regular device
connection (just like when coming from AM->AS).
- in AudioDeviceInventory.onSetA2dpSinkConnectionState(), support
receiving a connection event for an already connected device,
to support codec changes.
This change also includes modifications to the classes involved
in the device connection to make them support mocking/spying
to reproduce the bug conditions (see AudioDeviceBrokerTest).
Bug: 134932649
Test: atest AudioDeviceBrokerTest
Change-Id: If2b3b41409c77467a181a2f9b42310db9b9de8c5
am: 66d11c2a7e -s ours
am skip reason: change_id I851b819030a1da6091f5d6125a228bb01a99011b with SHA1 20bc2bf3f6 is in history
Change-Id: Ia2032d4f125fb0ce6bbe0e6c74079e27a9447bd3
IActivityTaskManager#finishActivity() used to return 'true' even if
activity was already finishing prior to the call. The refactor in
I30ebc306637dea5e8b28ca4b4dfaab8df31d2be3 that merged
ActivityStack#requestFinishActivityLocked() and
ActivityRecord#finishActivityLocked() accidentally changed the
return value for the case when activity was already finishing.
This made the client think that the activity was not finished, so
the client state was not updated correctly.
This CL checks the finishing state of the activity instead to report
back to client.
Bug: 138265285
Test: atest WmTests:ActivityTaskManagerServiceTests
Change-Id: I9503cf6b9ceaece4ab6a5933c143d238f7fa7c4d
am: 649965cdc5 -s ours
am skip reason: change_id I851b819030a1da6091f5d6125a228bb01a99011b with SHA1 20bc2bf3f6 is in history
Change-Id: Id47bb7c3b015b0165596864217aabc76de3195de
Collecting and app running share lots of common code.
Create a new class to run app and allow callbacks to specify
preprocess and postprocess and metrics selection.
Test: pytest run_app_with_prefetch_test.py
Test: pytest app_runner_test.py
Bug: 138233615
Change-Id: I972c82fb9ff3a0f6cc7661bc3dc47b342716c26c
am: 122f77dbac -s ours
am skip reason: change_id I851b819030a1da6091f5d6125a228bb01a99011b with SHA1 20bc2bf3f6 is in history
Change-Id: Iea341166db1a792cd297c8e49b323401d45ee577
am: 25fff4828a -s ours
am skip reason: change_id I851b819030a1da6091f5d6125a228bb01a99011b with SHA1 20bc2bf3f6 is in history
Change-Id: Id32923bd0cc23787a4ca841ddfc7e6bc96351548
We were persisting jobs' battery-not-low constraints but were not
properly restoring that constraint when the job was inflated at boot.
This could result in a runtime bootloop (!) if the job had no other
constraints, requiring a factory reset to restore the device to
usability.
We now:
* properly inflate the battery-not-low constraint;
* persist & inflate the storage-not-low constraint, which previously was
being stripped entirely and could result in a similar crash-at-boot;
* ignore the job rather than crash the system if one is inflated into
a non-viable state; and
* formally test previously-untested constraint persistence
Bug: 130012063
Test: atest $ANDROID_BUILD_TOP/frameworks/base/services/tests/servicestests/src/com/android/server/job/JobStoreTest.java
Test: atest CtsJobSchedulerTestCases
Test: JobStoreTest with forced throw in JobInfo.Builder#build()
Change-Id: Ia3ab1eb16aeaa85336409368b4340622cec19f4c
Merged-In: Ia3ab1eb16aeaa85336409368b4340622cec19f4c
