Previously, the BluetoothCodecStatus.equals() implementation
was incorrect when comparing arrays of capabilities.
In the new implementation, the arrays are compared correctly,
and also the ordering of the capabilities in each array is ignored.
Also, added unit tests for class BluetoothCodecConfig and class
BluetoothCodecStatus.
Bug: 73404858
Bug: 73379307
Test: Unit tests (in frameworks/base)
runtest --path core/tests/bluetoothtests/src/android/bluetooth/BluetoothCodecConfigTest.java
runtest --path core/tests/bluetoothtests/src/android/bluetooth/BluetoothCodecStatusTest.java
Change-Id: If22087465397b7c4175c33f7d1909a15d957fb24
Merged-In: If22087465397b7c4175c33f7d1909a15d957fb24
(cherry picked from commit 9d36e6babc)
Save has many limitations on compat mode, so we better not change the SaveInfo
behavior but rather document then.
This reverts commit 4f74a018c8.
Test: atest CtsAutoFillServiceTestCases:VirtualContainerActivityTest \
CtsAutoFillServiceTestCases:VirtualContainerActivityCompatModeTest
Bug: 77655074
Change-Id: I36bd28ca546dcedefe75de7815b76b8b5827aee3
APIs that return package usage data (such as the new ArtManager)
must ensure that callers hold both the PACKAGE_USAGE_STATS permission
and the OP_GET_USAGE_STATS app-op.
Bug: 77662908
Test: atest vendor/xts/gts-tests/hostsidetests/dexapis/host/
Change-Id: I7a85d959f1682d2bd5cf3684415e368fece88101
- It is possible for the call from SystemUI to cancel the recents animation
to be processed and handled after the virtual key has been processed in
PhoneWindowManager. This causes a misordering in which the canceling of
the Recents animation clears the pending start activity remote animation
(which is waiting for app transition ready).
Instead, move the canceling of the Recents animation to PhoneWindowManager
where the nav button is handled, to ensure that we cancel the animation
on the same thread before we start the activity.
Bug: 73188263
Test: Only able to reproduce so far artificially, which points to this
misordering
Change-Id: I1f3477acdf988953a5b3cef2e3b2b402af2d9909
Signed-off-by: Winson Chung <winsonc@google.com>
As per the referenced bug, we're running into issues where apps are
being fired with stale intents. The reason is because we need intents we
fire to be unique by Intent.filterEquals. Some of the intents we
generate put unique data in the intent extra which is not considered by
filterEquals. The solution here is to create PendingIntents with unique
request codes (using classifiedText.hashCode()).
See more info about this in
https://developer.android.com/reference/android/app/PendingIntent.html
Bug: 77930684
Test: manually tested broken scenarios. See referenced bug
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Change-Id: Ib7275f94ca5ada51e4ba191742d4b614df12e1ea
The warning dedupe logic in the runtime meant that only the first usage of
each API was detected. Disable this logic when DETECT_VM_NON_SDK_API_USAGE
is enabled.
Test: m
Test: $ atest android.os.cts.StrictModeTest#testNonSdkApiUsage
Bug: 78268765
Change-Id: Iba1127b84180b9a5e5eb68abc4691ccad082b80e
If we send a bad API whitelist to the Zygote, it causes it to close the
socket. If we take no further action in AMS, it results in the same list
of exceptions being sent when we re-open the socket, resulting in it again
being closed. This results in no longer fork/start any new processes.
Since the list is persisted, this would result in the device entering a
boot loop upon reboot. Since no apps could be started, we cannot recover.
So in the case that the exemptions list causes problems, clear out the
list so we don't try to send it again next time. This means we will see
a single failure, but future attempts will succeed (obviously without
any whitelist). The device should not enter a boot loop.
Note, the test below relies on the fact that we can send at most 1024
arguments in a command to the Zygote (MAX_ZYGOTE_ARGC), and that each
item on the list is a separate argument.
Test: adb shell settings put global hidden_api_blacklist_exemptions \
Test: $(for i in {1..1025}; do echo -n $i,; done)
Bug: 64382372
Change-Id: Ie47095d516c247ff6a8d667a2ac9b7be45f1acda
RemoteViews end up passing around Uris, so we need to extend Uri
permission grants for them to ensure the recipient of a Notification
object is able to render its contents.
Bug: 9069730
Test: atest frameworks/base/services/tests/uiservicestests/src/com/android/server/notification
Change-Id: Id31b5adaf2ee66113a1b503e32126aeddbf97b28
Clarify that the caller has to wait for onServiceAdded callback before
calling BluetoothGattServer::addService again.
Bug: 72717069
Test: Compile
Change-Id: I20b031c724ba64bfd71cf10e58e587f69e4a2555
(cherry picked from commit 4b5cf48560)
Added explanation that callers can use a format string which takes a
single argument which is the name of the suspended app that the user
tried to launch.
Test: make docs
Bug: 77507744
Change-Id: I0a5259048332030385265ceab9c7d76766abac7d
Add method to allow dynamic adjustment of cpuset of media.codec
process. Only accept requests coming from mediaserver.
Bug: 72841545
Change-Id: Idb09d9a5162691503ecf6d811a528d9160326358
Replace checkSignatures() calls in AccountManager with a new,
rotation-aware call to PackageManagerInternal. Also add a new
AUTH cert capability to reflect the distinction between these
permissions and others.
Bug: 77651077
Test: Builds. CtsAccountManagerTestCases
Change-Id: Idd412cd984acf7d37555deb5879f2d6a0a10c2b6
dischargeScreenOffCount already includes dischargeScreenDozeCount.
Original code deducted dischargeScreenDozeCount twice. This only affects
text dump in bugreport. Proto and checkin dump are not affected.
Test: manual
Fixes: 78187276
Change-Id: Id93465ca75a4a1078e8f280a38b74b696ec62dd2
Also extend the timeout to 60 seconds.
- Because each provider / service dump may time out, the total time should relatively be large.
Bug: 78017892
Fix: 78017892
Test: Manual test with the following dumpsys commands:
dumpsys activity provider all
dumpsys activity provider all-platform
dumpsys activity provider all-non-platform
dumpsys activity provider com.android.providers.contacts/com.android.providers.contacts.VoicemailContentProvider
dumpsys activity provider com.android.providers.contacts/.VoicemailContentProvider
dumpsys activity provider contacts
dumpsys activity provider voicemail
dumpsys activity provider 4d45a78
dumpsys activity service all
dumpsys activity service all-platform
dumpsys activity service all-non-platform
dumpsys activity service bluetooth
Test: atest /android/pi-dev/frameworks/base/core/tests/coretests/src/com/android/internal/util/DumpTest.java
Test: atest /android/pi-dev/frameworks/base/core/tests/coretests/src/com/android/internal/util/ParseUtilsTest.java
Test: Manual test with "adb bugreport" with adding sleep(10s) to ProviderMap.dumpProvider()
Change-Id: I00bce0090b8dbb947d7f8b1e5d01bb8a70d84bd8
