getLockTaskPackages is currently hidden, and can only be
called by a device or profile owner, which doesn't make
much sense. Unhidding it to be consistent with the rest
of the DevicePolicyManager APIs that have a getter for
each setter.
Bug: 34614754
Test: cts-tradefed run cts-dev --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_affiliatedSecondaryUser
Test: cts-tradefed run cts-dev --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_unaffiliatedUser
Test: Test: cts-tradefed run cts-dev --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_deviceOwnerUser
Change-Id: I6e03c2f47c0f9e7a635e798a1bf7f131a8e37c65
This is yet another big refactoring:
- AutoFillManager keeps track of its current AutoFillSession.
- Views call AFM.startSession(View) when they can trigger autofill.
(virtual views can call it as well). At this point, the manager
sets an AutoFillSession, gets the activity token, and passes it to
the service.
- Subsequent calls to AFM.start() will be ignored since the session
is set.
- When the Activity is gone, it calls AFM.finishSession().
- Simlilarly, virtual views could call it as well.
- Added getAutoFillValue() to View.
- Removed AFM.updateAutoFillInput(childId): virtual views should now
call startSession(childId) to start a session, and use the
VirtualViewListener callbacks for updates.
- Change AutoFillValue to use String (which is immutable) instead of
CharSequence for text values.
- Check if view is enabled before auto-filling.
- Removed 'cmd autofill fill' since it would require the appCallback
- Automatically dismiss the snack bar after 30s
- Moved the "don't change autofill value when autofilling" Inception
logic into the service side.
- Etc...
BUG: 34819567
BUG: 33269702
BUG: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: I5fad928d4d666701302049d142026a1efa7291cd
Programs and RecordedPrograms have a lot in common. This change
introduces BaseProgramColumns which removes the duplicates.
This will be also helpful for the further clean-up.
Test: build & passes CtsTvTestCases without modification
Bug: 34853064
Change-Id: I4ad352a9a904e7fef57c56acec5583df92b4226c
This allows an AccessibilityService to set a flag in its
AccessibilityServiceInfo that triggers the navigation bar to show an
Accessibility Button and observe callbacks when the button is clicked
or there are changes in the visibility of the navigation bar.
Test: Manual (Created a sample AccessibilityService) + CTS
Bug:29231271
Change-Id: I03d653d85bc37df28ed71d8bba94b7c75fe56e43
This introduces an API for apps that support companion devices to provide a
more streamlined flow for pairing and setting up the device
Bug: 30932767
Test: Using a toy app, invoke the newly introduced API (CompanionDeviceManager),
and go through the flow. Ensure filtering works, and device is returned to
the calling app. Ensure the calling app can pair to the selected device.
Change-Id: I0aeb653afd65e4adead13ea9c7248ec20971b04a
The names of specific Vulkan API features can't be documented yet,
because they won't be ratified by Khronos before the documentation
becomes public in a developer preview.
Bug: 34745152
Test: android.graphics.cts.VulkanFeaturesTest
Change-Id: I9af673bcb5b0c74bde72ab7a579573894170a55d
1. Move management of the remote fill service in a dedicated
class that abstracts away the async and ephemeral nature
of the binding.
2. Update auth to move fingerprint out of the platform and
allow response and dataset auth.
3. Cleaned up the fill and save callback classes.
4. The UI is now shared among all sessions and cleaned up.
5. Reshuffled the remote callbacks to have cleaner separation.
6. Cleaned up and tightened the reponse and dataset classes.
7. Added API to support communicationn with intent based auth.
Test: CTS + manually
bug:31001899
Change-Id: Idc924a01d1aea82807e0397ff7293d2b8470d4d6
Stream types are deprecated to describe an audio playback use case.
But they are used for volume control. This API helps the developer
go from an AudioAttributes instance used for playback, to a
stream type used to describe which volume stream type should be
used when the user presses on the volume keys.
Test: see AudioAttributes cts test
Bug 21267880
Change-Id: I2b9da5b282e8ed2342c61c14a7f59b874d0ce979
New android:targetProcess attribute on <instrumentation> allows you to
specify the processes the instrumentation will run in.
This reworks how instrumentation is run in the activity manager to better
formalize its state and semantics, allowing us to keep track of it across
multiple processes. This also clearly defines what happens when multiple
instrumentations are running at the same time, which is useful for writing
CTS tests that test the instrumentation APIs themselves.
Adds a couple new APIs to Instrumentation that helps with the new
situation where instrumentation can run concurrently in multiple processes.
Test: new CTS tests added (textXxxProcessInstrumentation in
ActivityManagerTest.java in cts/tests/app/src)
Change-Id: I2811e6c75bc98d4856045b2f0a45fb24af5d366f
This reverts commit 06c2fffdaa81544522de751846754f781a9970a9.
Reason for revert: Java 8 doesn't support this magic.
Change-Id: Iaa41f4e4d0072b9a97cff9cd3788403d4ab79d13
* changes:
hotspot2: expose Passpoint APIs as public
hotspot2: fix class/function/variable names to comply with API guideline
hotspot2: rename classes to comply with API guideline
Use package name instead of uid.
Check calling package name in getAccounts methods.
Bug: 34841115, 34841115
Test: cts tests, manual tests.
Change-Id: I8a9e6aea5e2b6677be4bc414836b842239c5b6ac
- Introduced TYPE_APPLICATION_OVERLAY window type. Can be used by apps
to display windows on top of other app windows, but below critical
system windows.
- Deprecate alert window types TYPE_PHONE, TYPE_SYSTEM_ALERT,
TYPE_SYSTEM_OVERLAY, TYPE_PRIORITY_PHONE, and TYPE_SYSTEM_ERROR.
Apps should now use TYPE_APP_OVERLAY for this.
- Apps targetting O or greater are not allowed to add the old alert
window types.
Apps targetting less than O can still add the old types.
Apps with permission INTERNAL_SYSTEM_WINDOW (system signature apps) can
still add the old types.
- Z-order old alert windows types below TYPE_APPLICATION_OVERLAY if
they are added by an app without the INTERNAL_SYSTEM_WINDOW permission.
Test: android.server.cts.AlertWindowsTests
Bug: 33256752
Change-Id: I12170955a7a333151d3387c169b51c53c32164fc
