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.
Test: Manual
Bug: 37106957
Merged-In: Ifb72870105be5ba024af196a8c3165a9afb397ab
Change-Id: Ifb72870105be5ba024af196a8c3165a9afb397ab
* 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
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
This allows apps to listen for beacons, etc., without having to
run a foreground service and register a callback. They can instead
register a PendingIntent which will be fired when scan results
are available or when an error occurs.
Bug: 37254611
Test: WIP
Change-Id: I1793eee67ff0211370ed6fc38be4d95a4c5853f5
This allows any service to interact with JobScheduler, which
should give us a lot more opportunity to do interesting stuff
in the support lib.
Test: bit CtsJobSchedulerTestCases
Change-Id: I0843e8b212a0a63a17558b837b899b90cac22805
This api will return the timestamp at which this activity start was last
initiated by the system. Implementation is wip.
Bug: 9058261
Test: cts-tradefed run singleCommand cts-dev -m CtsAppTestCases -t \
android.app.cts.ActivityStartTimeTest
Change-Id: I396458ecefbb09108f414b95f9c0beb6d609a4e1
Change setNextOutputFile to accept File instead of String. Also add new version
of setOutputFile to accept File.
Bug: 36791064
Test: CTS test.
Change-Id: I1a3d574e7cf36acbf181407131bc9dbf114d30de
This allows applications to load bitmap in a preferred
target color space, similar to inPreferredConfig for
configurations.
This change also applies recent changes made to BitmapFactory
to BitmapRegionDecoder: support for outColorSpace, inColorSpace
and outConfig.
Bug: 32984164, 36905374
Test: CtsGraphicsTestCase (BitmapColorSpaceTest/BitmapRegionDecoderTest)
Change-Id: I4eded9190d1aa9c7f3033f9bb78a6854cc48a3ef
