These broadcasts resulted in a terrible user experience where dozens
of apps would wake up and try deleting everything they possibly can,
meaning that we'd thrash between showing/hiding the low space
notification to users.
Instead, if apps have data that they're okay being purged when the
system is chronically low on space, we want to strongly encourage
them to rely on the much-improved getCacheDir() behaviors in OC.
Test: builds, boots
Bug: 35406598
Change-Id: I74abfba1b8d3948363b79f8b66ca0ad60faac756
There are no instances of this call in master outside of platform.
BUG: 34169232
Test: make update-api; make; fastboot flashall
Change-Id: I4555af5487291097ca3768fdf071c4db7dd21288
Exposing actions from the PIP InputConsumer to accessibility,
stripping all actions from a covered PIP app, and adding the
InputConsumer's actions on the PIP app's root view.
We were also using an "undefined" accessibility ID to mean
three different things: a root view, a host view of a virtual
view hierarchy, and a truly undefined view. I've introduced
new values for cases where the id could be defined.
Also gathering all window IDs into one place to reduce the
chance of collisions.
Bug: 34773134
Test: In progress. Current cts passes.
Change-Id: I97269741a292cf406272bf02359c76c396f84640
Until now we have been recycling only framework preference widgets since
there were no guarantees for third party preferences to support recycling.
This let to broken animations for preference widgets that are outside of
the framework.
This change makes recycling to be used always and in case the developers
need to turn it off they can explicitely use a new attribute that is
being added to the Preference called "recycleEnabled" and set it to false.
Bug: b/34334451
Test: Test are part of the same topic.
Change-Id: I324087841e1edddbf0d3eaad00b5895a196acff6
This was requested by the current users, need to state
that a font is unavailable (needs downloading) or that
the query is unsupported.
Also add tests :)
Test: runtest --path frameworks/base/core/tests/coretests/src/android/provider/FontsContractTest.java
Also CTS attached to topic
Bug: 35097775
Change-Id: Ib15bf4c70185d81a4c20426722eb44c4210771c2
Address API Councils comment on the newly added intent definitions
for Passpoint events:
- Use a Parcelable class to represent icon info
- Document all extras that are included for an action
- Document that the new intents will only be sent to registered
receivers, and not manifest receivers
- Rename extras to be more generic
While there, removed the deprecated hidden Passpoint intent
definitions.
Bug: 35857805
Test: frameworks/base/wifi/tests/runtests.sh
Change-Id: I22de2d52fce3ed1adc8d72bf1580d3337bc747c5
By supporting multiple filters per one request we should be able to cover
multiple kinds of use cases such as:
- Letting the user select from a list of devices of more then one medium
type (e.g. Bluetooth and BLE)
- Allowing to provide multiple criteria for any field (e.g. filtering by
more than one service UUID)
Bug: 30932767
Test: Provide multiple filters and ensure that devices matching either are
shown in the list to choose from.
Ensure wifi SSIDs are shown in the list if wifi filter is provided
Change-Id: I0a978787551a1ee5750ec5544b241d3bbfed5a7c
Bug: 36025103
Test: cts-tradefed run singleCommand cts-dev --module CtsGraphicsTestCases
Test: cts-tradefed run singleCommand cts-dev --module CtsUiRenderingTestCases
Test: manually inspected for leaks via SK_TRACK_SHADER_LIFETIME and forcing a GC after ComposeShaderTest
Change-Id: Ib5d33a80d2f9f468705806b05832e753508143cc
Add a priviledged permission NOTIFICATION_DURING_SETUP which together
with the existing Notification.EXTRA_ALLOW_DURING_SETUP will allow a
notification to be shown during setup.
Test: Added NotificationDataTest
Bug: 34705874
Change-Id: I7215acf4017ad897294c69abf63a7f2e5d556f31
NanoAppId should not be 32 bits as exposed in some APIs.
Adding new methods to accept a 64 bit nanoAppId and deprecating
the buggy API methods.
Test: Compile build, ensure CHRE applications (eg: geofencing) work.
Change-Id: I08b09ff1b1d23b616214282f200202c99620c300
This change will affects 2 types of apps: autofill service implementations
and apps that use autofill APIs.
Since just the former is known to be used at the moment, we're not trying
to keep backward compatibility with the latter.
Bug: 35956626
Test: CtsAutoFillServiceTestCases pass
Test: android.provider.SettingsBackupTest pass
Change-Id: Ia720083508716deae9e887f9faa7ae7c5a82f471
By supporting multiple filters per one request we should be able to cover
multiple kinds of use cases such as:
- Letting the user select from a list of devices of more then one medium
type (e.g. Bluetooth and BLE)
- Allowing to provide multiple criteria for any field (e.g. filtering by
more than one service UUID)
Bug: 30932767
Test: Provide multiple filters and ensure that devices matching either are
shown in the list to choose from.
Ensure wifi SSIDs are shown in the list if wifi filter is provided
Change-Id: I6621da388e2bf4ed97c5af2692629a321d0b63c7
Over the last month we've been moving everyone over to the new
StorageStatsManager public APIs, but we missed these users.
The ApplicationsState changes are straightforward, but we had to
completely rewrite StorageMeasurement to use the new fast-path
quota APIs.
Test: builds, boots, UI using StorageMeasurement works.
Bug: 36056120
Change-Id: If02177c95bf8c96ae4eceac4d631a168f99bef84
