When the autofill service returns a null FillResponse, the session is marked
"gone" because the service cannot autofill it. But there might be cases where
the view structure change and it's now autofillable, so need to allow users
to manually request autofill again in such cases.
Fixes: 38205945
Test: CtsAutoFillServiceTestCases pass
Test: LoginActivityTest.testAutofillManuallyAfterServiceReturnedNoDatasets()
Test: LoginActivityTest.testAutofillManuallyAndSaveAfterServiceReturnedNoDatasets()
Change-Id: I9b23c255e563dd0646bf266d31ddb10dcc4f7f6d
Add registration for the camera lift trigger sensor and handling for its
events to GestureLauncherService
Test: Confirmed camera launches on lift gesture if setting is enabled
(and other pieces are in place)
Change-Id: Ibfad2040409d86af2d019e2ce97ab546bef9ba78
- Now keep track of the time a job was enqueued, and order
the pending list by that.
- Added configuration constants for rescheduling: maximum
times to reschedule, minimum backoff times.
- Fixed printing of active jobs -- the method to get the current
JobStatus was old and didn't require the caller to hold a
lock, so made a copy, which didn't contain all the data we were
interested in. Now with our simple locking, we can just make
that require the caller hold a lock and return the real
JobStatus object.
- Include oom_adj and procstate when printing information about
processes being killed.
- Expanded documentation of BroadcastReceiver.goAsync().
Test: bit CtsJobSchedulerTestCases:*
Change-Id: I2e45f181e45be9836c74cbff1b844ffdf6e93019
The return result from starting activity actually represents two
pieces of information. First, it conveys whether the activity
started. Secondly, it conveys whether there was a fatal error if
the activity did not start. Many parts of the code assume that a
value greater than or equal to the defined success means that the
activity successfully started. This is not the case as there are a
number of results greater than success where the activity does not
start.
This change addresses the issue by introducing three distinct
result ranges. The first represents results where the activity
could not start due to a fatal error. The second represents results
where the activity did not start due to a non-fatal error. The last
range represents successful activity starts. Two convenience methods
have been added to ActivityManager to return whether the result
represents a fatal error and whether the result was successful.
Change-Id: Ifaf844c353641a28b03b3c2d7b6be053fd9b8b44
Fixes: 38021882
Test: cts-tradefed run cts-dev --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_deviceOwnerUser
Hid command, JNI layer:
- Removed dependency of the hid device on libandroid_runtime
and libutils. Using ALooper from libandroid to process callbacks from
/dev/uhid file descriptor.
- Switched to using "CREATE2" and "INPUT2" constructs in uhid driver
Hid command, Java layer:
- Removed delay workarounds, user now responsible for waiting for
onInputDeviceChanged notification prior to using the hid commands.
UiAutomation:
- Added a new executeShellCommandRw function that allows bidirectional
communication to shell command
platform.xml:
- Added uhid permissions to bluetooth stack for /dev/uhid access
- CTS test now consistently passes
Bug: 34052337
Test: CTS test case invoked with the following command:
run cts -t android.hardware.input.cts.tests.GamepadTestCase
-m CtsHardwareTestCases --skip-system-status-check
com.android.compatibility.common.tradefed.targetprep.NetworkConnectivityChecker
Change-Id: Ic916c513b7e652b1e25675f0f38f0f1f3a65d214
Because we were relying on the output to go in the right direction
already, this could be wrong. We're now only following the given
lightness direction if it is even possible to satisfy contrast.
Test: runtest -x core/tests/coretests/src/android/app/NotificationTest.java
Change-Id: I06d934a6b5c328ebbf0cf707030b0d707ccb5ab4
Fixes: 38182819
