This change deprecates the method akin to the previous deprecation of
ActivityManager#getRunningTasks. The documentation has been updated
to reflect the current limitations of the method.
Change-Id: I6f35309c1224fdf1f890bce3cc614be8aa343368
Fixes: 36937370
Test: documentation
- JobServiceEngine now takes a concrete Service instead of
generic Context in its constructor, since it really must be
associated with a real Service.
- Expand documentation of how dequeueWork() operates.
- Fix some job scheduler implementation to hopefully actually
match the docs: transfer remaining executing work to the new
job, and actually correctly transfer state from old and new
jobs if we are rescheduling due to a true return from onStopJob().
Test: bit CtsJobSchedulerTestCases:*
Change-Id: Ia66797049883eefb566264f930070afb69d469b1
The NotificationManager.startServiceInForeground() experiment is over,
and will not ship as API, so it's time to tidy up and get rid of it.
Bug 36130212
Test: manual
Change-Id: I834d1ce059aa464ff27f69f5e5d3625cc5e61d8a
Based on API council feedback, switch to using real UUID objects
instead of Strings. Since UUID is a general-purpose utility class
that will be passed around quite a bit, add it to Parcel and Bundle.
Define well-known namespaced UUID values for "default" and "primary
physical" storage devices, which will let us annotate a bunch of
things with @NonNull.
Define new extras for MANAGE_STORAGE intent that apps can use to
signal where and how much space they'd like the user to free up.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 37325923, 35812899, 35806020
Change-Id: I8421b126d680f69141a361c1e77223fe2bf4a325
These were previously @SystemApi. Retaining the existing SystemAPI
behavior which sends the intents to those with a private permission.
Extending to ALSO send these intents to the default dialer app as well
using an explicit intent.
Cherry-pick from aosp-master to resolve merge conflicts.
Test: Manual
Bug: 37106957
Merged-In: Ifb72870105be5ba024af196a8c3165a9afb397ab
Change-Id: Ifb72870105be5ba024af196a8c3165a9afb397ab
(cherry picked from commit d9da6ce993)
Adds a method isTheFinalCountDown that allows to correctly
determine whether it is the final countdown.
Test: None
Change-Id: I786ae3455479bac25ccf25efba1c3dce18185117
The purpose here is to provide support for selectively
enabling Runtime Resource Overlays (RROs) (specifically
those pertaining to a specific SKU, within a OEM's "single
build" covering multiple SKUs) at boot based on the value
of a pre-defined system property.
This mechanism is designed to be compatible with other,
recent changes to Runtime Resource Overlays - specifically:
- has no effect on 'isStatic'. Resource overlays must be
attributed as static in order to qualify for loading into
the system_server. The 'requiredSystemPropertyName/
requiredSystemPropertyValue' mechanism operates
independent of this and can be used on both static and
non static overlays. The effect of specifying a conditional
property on any overlay is that it will ONLY be enabled
in the event that the system reflects both the property
and the specified value (Note that in the ABSENCE of a
conditional property, overlays are assumed to be enabled).
- has no effect on OverlayManagerService (OMS) API. The
OMS provides the system with an interface through which
overlays can be enabled/disabled and even rearranged at
runtime. This provides the basis of support for various
user-level features (e.g. dynamic theme selection).
The 'requiredSystemPropertyName/requiredSystemPropertyValue'
mechanism operates independent of this -
with enablement being completely coupled to the available
system properties on the device and NOT subject to change
at runtime.
Note: as part of this change, original overlay tests have been
updated (fixed) and expanded to include tests to cover the
conditional property implementation.
Issue: http://b/35100249
Test: frameworks/base/core/tests/overlaytests/testrunner.py
Change-Id: I1990ce21a27a385db1e2f53294b69dd03988351e
(cherry picked from commit d5566c6c47)
Because listeners can see notifications on managed profiles.
Test: runtest systemui-notification and testing with a sample app
(reading and updating channels and getting change
callbacks on a managed profile)
Change-Id: I5d7af3c417e3a3d18f992cc9ad01fbd7959de398
Fixes: 36783632
An service can option to finish the session once all views that it
declared as important. Views that are important are all autofillable
views of any partition and the saveable fields of the last partition.
Test: CtsAutoFillServiceTestCases
Fixes: 35708237
Change-Id: I0ccade8ebb427e5d8928697ef0007c75d3f83df0
* changes:
[CM] Unhide the NetworkSpecifier as object API
Make the NetworkSpecifier a class instead of a string.
Add test coverage for NetworkSpecifiers.
Test: 1. Trigger the confitrmation dialog.
Ensure it looks exactly like the one from settings.
2. Call an API without associating the appa first
Ensure exception is thrown with a message mentioning the need to associate 1st
Change-Id: I94d4116e1988db869ed445ae3fd018c50590e3f4
Now it's possible to listen to changes on wallpaper colors by
registering a listener on WallpaperManager. It's also possible
to get the current wallpaper text color hints.
Bug: 36856508
Test: compilation
Change-Id: I5102cb7be9a4af60b85fc8913154a79dfe5c21a0
This value is necessary to easily look up the availability of a
recommendation (nee, scoring) provider; however it is only used by
bundled apps to monitor its availability, so hide the setting itself.
Test: make update-api; make; flashall
Bug: 34715823
Change-Id: Idf4591fd03d90207ef525f584793db65a1f6597c
When saving data filled by the user the platform provides to
an autofill provider the state of the UI allowing the provider
to interpret this state and store relevant information.
A limitation of the current design is that the fill provider
needs to interpret the screen content twice, once handling a
fill request and once handling a save request. To address this
we are introducing a id for each fill request allowing the
autofill provider to associate arbitrary state with each fill
request and store it in the client data bundle later passed
to save.
Another limitation of the current design is that if the screen
changes dynamically while the user interacts with the app the
UI state passed on save represents a static snapshot, therefore
it is not possible to the autofill provider to determine the
context in which the data in the UI was filled. We could
keep the views and have deltas for views being removed/added
/moved/changed but this is not enough as the fill provider
needs to know not only what changed but what changed for every
fill request and in one session there could be multiple fill
requests. To address this we provide a list of fill contexts
on save each of which has the id of the corresponding fill
request. This allows the fill provider to know the exact context
in which the data was popuplated and also use its custom client
state for this fill request if desired.
This change deprecates the old APIs and the new ones delegate
to the old ones. Once the clients migrate to the new APIs we
will remove the old ones.
Test: all autofill CTS tests pass
Change-Id: Idcebcc671aa3c078a305d8c358e225274fccc588
Reworking the media metrics getMetrics() calls (currently in MediaCodec,
MediaExtractor, MediaPlayer, and MediaRecorder) to fit new direction
from the API Council.
Drop the MediaMetricsSet that we had in the first round; go back
to a PersistableBundle as the return type. Moves the key definitions
from MediaMetricsSet.MediaCodec to MediaCodec.MetricsConstants
Bug: 37083862
Test: ran the corresponding CTS tests
Change-Id: I7905959ad2109887dd8fd16f0eb2831247abab2a
