Bug: 63907873
Test: manually tested that the app op is being logged for TalkBack and a 3rd party accessibility service. Ran UIAutomator-based tests to check that they work as expected.
Change-Id: I1a40d4ead52ba2258cc7ddc8be594a13895d8340
Enable the BluetoothHidDevice API in framework.
Bug: 63384609
Test: SL4A HID test; test with apps using BluetoothHidDevice
Change-Id: I52ca4674f11179f865bdff22e0289dfe893c40f5
Things can be flaky, because window focus changes are
dispatched to the window on a separate path from input events,
and the window will drop events if it gets them before it sees
the focus change. I am trying to mitigate this some by noting
ASAP what the next upcoming focus state will be, so we can check
that and dispatch it before dispatching a key event if needed.
This definitely makes things better, but not perfect. ctate
suggested that maybe we should be dispatching window focus events
through the input system, which at a glance sounds like a really
really good idea to me... so maybe we can look at that later.
Also changed the wm command to just be a shell wrapper around
all of the implementation that is now in WindowManagerShellCommand.
And fixed a few places where we write debug info to streams that
would trigger strict mode violations that we really don't care
about.
Test: manual
Change-Id: I5235653bcec5522ab84c7f2e1de96d86f2f59326
ag/3340390 changed untrusted value to systemDir while going through
code review, flipping the meaning of the variable, but this was not
reflected in the call site. As a result, systemDir apps are the
only ones being fully verified, which is the opposite of what we want.
Test: Builds, eventually CTS.
Change-Id: I585ac65c957f0d8db6c73f003d3a3eb2b79c8883
These APIs allow apps to know when they should be sending updates
to any given slice uri.
Test: update-api
Bug: 68378571
Change-Id: I4fa218c8d376692fa843f21777c87d592169a377
When DISALLOW_UNIFIED_PASSWORD is enforced by managed profile
owner, the user is disallowed to user single lock for both primary
user and the profile.
DMP.isUsingUnifiedPassword() can be called by DPC to check if
this restriction is obeyed.
Test: make cts-verifier
Test: cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
com.android.cts.devicepolicy.ManagedProfileTest#testIsUsingUnifiedPassword
Test: cts-tradefed run cts -m CtsAdminTestCases -t
android.admin.cts.DevicePolicyManagerTest#testIsUsingUnifiedPassword_failIfNotProfileOwner
Bug: 63909482
Change-Id: Ib758e32d4bf4012d805185bce874f481e17576ba
Includes parcelables for
1) KeyDerivation
2) User Secret together with its type.
3) Application key entry
4) KeystoreRecoveryData block with all data necessary to recover
keys later.
Test: none
Bug: 65979689
Change-Id: If59842a92ebbc0e77f95d6a2e5503943e2835062
Added Settings.Global.SQLITE_COMPATIBILITY_WAL_FLAGS -
configuration flags for SQLite Compatibility WAL. Encoded as a key-value
list, separated by commas. E.g.:
compatibility_wal_supported=true, wal_syncmode=OFF
SQLiteCompatibilityWalFlags caches the value of
SQLITE_COMPATIBILITY_WAL_FLAGS on first access and keeps it through
the lifetime of the process for consistent behavior across all
connections.
Test: SQLiteCompatibilityWalFlagsTest
Test: setting put global ... + verify that dumpsys dbinfo has the new flag
Bug: 70226732
Bug: 70517616
Change-Id: Ifacbf5908c83351ebe5dea676eeb716af039fb14
Bug: 67734082
Test: Run a test app to issue an disable request, verify HAL code is
executed via logs and client receives an error response.
Change-Id: I5a26c85372bd10a0224bf2a696982dccbca0c275
Bug: 67734082
Test: Run a test app to issue an enable request, verify HAL code is
executed via logs and client receives an error response.
Change-Id: Ie4ec660a094082887eaefbdfc2e1fd8d1ee7c0e3
If the KeyGenParameterSpec passed into
DevicePolicyManager.generateKeyPair contains an attestation challenge,
request an attestation record for the newly-generated key with the
challenge provided.
This particular implementation was chosen, rather than letting the
attestation record be generated at the same time as key generation, to
avoid having the attestation chain stored in Keystore and associated
with the generated alias.
The rationale is that this is a key that is potentially accessible by
multiple applications and the attestation chain may end up being sent
as a TLS client certificate chain, for example.
As the attestation challenge should be unique per device, to avoid
the potential of sending / sharing unique device information, by
explicitly requesting an attestation record after key generation, the
attestation record is only returned to the generateKeyPair client and
not persistend in Keystore.
Bug: 63388672
Test: New CTS test to be run with: 'cts-tradefed run commandAndExit cts-dev -a armeabi-v7a -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.DeviceOwnerTest#testKeyManagement -l DEBUG'
Change-Id: I95a9aef179173b571b533301ac438c675e8fe702
- Rename varaibles holding LoadedApk to make the code easier to read.
- Move resource creation into LoadedApk, consolidating the logic.
Test: manual
Change-Id: I6bdc70482fbbb346ff694ada528ded18d3a63ef7
