Disable app standby features if app_standby_enabled
is set to 0. This allows for UI and experiments to
control the feature.
Bug: 70655630
Test: adb shell settings put global app_standby_enabled 0
adb shell dumpsys usagestats
adb shell am get-standby-bucket <packagename>
Change-Id: Id6c62b078e52040767100f2997832cc586bb0806
CTS tests are now throwing security exceptions for accessibility actions.
This reverts commit 19eb58959b.
Change-Id: I2027ee4cca0fcc2b38bb615a58d992ef309e2d70
This CL is a generalized version of my previous CL [1], which addresed
Bug 31056744 where InputMethodManager (IMM) fails to recover from
failure mode when IMMS#startInputOrWindowGainedFocus() failes because
the app's window is no longer eligible to be the IME target.
This CL finally addressed one TODO in that CL. InputBindResult now has
the error code, which allows us to force restart input upon the next
window-focus-in event. This should make IMM much more robust for
that kind of failure modes. For instance, Bug 70629102 is fixed as
demonstrated in a newly added CTS test case [2]. Hopefully this may
also fix Bug 31056744, which we still do not know how to reproduce.
[1]: I60adb38013b063918b074c7b947649eada77b2c8
8e9214b4bd
[2]: I4ea24c87cbbd05e4e68ad7dfafb774c8520188e2
Bug: 31056744
Fixes: 70629102
Test: Added a test case for Bug 70629102
atest CtsInputMethodTestCases
Test: Manually made sure that Bug 28281870 is still fixed:
1. Open app that has EditText.
2. Start Input.
3. Long press the task switch button to start multi-window mode.
4. Tap the EditText that is used in step 2.
5. Make sure that the IME still works as expected
Test: atest CtsViewTestCates
Change-Id: I7572d4b9d678f3669ca54d55718877b145015777
We've tried our best to protect against malicious storage devices
with limited SELinux domains, but let's be even more paranoid and
refuse to look at disks inserted while a secure keyguard is
showing. We'll gladly scan them right away once the user confirms
their credentials.
Test: builds, boots, manual testing
Bug: 68054513
Change-Id: I19b7446e855176921ed477ef6d07bc9a2cc0ef9a
Currently, process start is initiated in ActivityManagerService
holding the main lock and this takes ~40ms to complete. As seen
in some of the issues in previous releases, this is one of the
contributors of the lock contention in system_server. This change
tries to address this issue by moving the process start outside
the locked section.
When a process start is required, instead of doing it synchronously,
this request will be posted on a handler thread. On the handler thread,
this process start request will be completed without holding a lock.
If for some reason, we decide the process is not needed anymore before
it is actually started or being started, then AMS does everything as
usual removing the references to the process from internal state except
actually killing the process which will be handled on the handler
thread.
Bug: 68775202
Test: Ran app startup perf tests using forrest, will update the bug with results.
Test: https://docs.google.com/spreadsheets/d/1cW81guRALZXKsN-WZsKyQiCSY-RgkJ2m_M9IfqIquz8
Test: cts-tradefed run singleCommand cts-dev -m CtsActivityManagerDeviceTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWindowManagerDeviceTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsAppTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsMultiUserHostTestCases
Test: adb shell am instrument -e package com.android.server.am -w \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Test: adb shell am instrument -e class com.android.server.pm.UserManagerTest -w \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Test: adb shell am instrument -e package android.content -w \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Test: cts-tradefed run singleCommand cts-dev -m CtsProviderTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsContentTestCases -t \
android.content.cts.ContentResolverTest
Test: cts-tradefed run singleCommand cts-dev -m CtsContentTestCases -t \
android.content.cts.ContentProviderTest
Test: cts-tradefed run singleCommand cts-dev -m CtsWebkitTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsHostsideWebViewTests
Test: cts-tradefed run singleCommand cts-dev -m CtsAssistTestCases
Test: make WebViewLoadingTests && make tradefed-all && tradefed.sh \
run template/local_min --template:map test=WebViewLoadingTests
Test: adb shell setprop wrap.com.google.android.apps.maps \
'"LIBC_DEBUG_MALLOC_OPTIONS=backtrace logwrapper"'
&& adb shell dumpsys meminfo --unreachable <PID_OF_APP>
&& check ppid of <APP> is logwrapper's pid.
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapNoDebugTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapDebugTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapNoWrapTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapDebugMallocDebugTestCases
Test: manual
Change-Id: I1fe7ce48cd5a4aadccaf6b3d6fdb5cad3304f1d3
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
This API allows app to construct custom metrics based on labels
chosen by the app developers. Also added some buttons to manually
test this functionality in the dogfood app.
Test: Verified that Android can be built and tested with custom app.
Bug: 69522276
Change-Id: Ifb7abea4c1d62fb435a9cb6f32df12bc2234d82f
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
