am: dc0ac4fa83 -s ours
am skip reason: change_id I3f47a8ac07813ea9e326c7d76123352708bfeea2 with SHA1 04c28872d1 is in history
Change-Id: I46448919190fa47873183d33924f0b283234ddee
am: 8f1a1f83dc -s ours
am skip reason: change_id Iabb0e7cadae52d8ebe922f61a878298ad4dd04b0 with SHA1 1a952dd940 is in history
Change-Id: I6fcd207d3eae1ece992978edfbbd1264135b5cb3
am: d21b676dee -s ours
am skip reason: change_id Ib70dd739d8067ca2e37f0dbc6c48a2d625935a4b with SHA1 cd0d609f75 is in history
Change-Id: If6a2b3eceb2e24727b74a7d36dddca11c9a247b2
Previously, we were loading the GlobalActionsPanelPlugin in the
constructor for GlobalActionsDialog, which is instantiated on demand
the first time that Global Actions is launched. Because the plugin is
loaded in the background, a race condition exists where the
GlobalActions Dialog is displayed before the plugin has finished
loading, and so the Plugin will not appear, despite being enabled.
In this change, the GlobalActionsPanelPlugin is loaded in
GlobalActionsImpl, which is scoped to the SystemUI Applcation lifetime
(it will always be available). Therefore, the plugin will start
loading as soon as it is enabled by the user.
The race condition still exists, but is greatly mitigated and should
not pose a significant issue.
Test: manual
Change-Id: I624f7b0b9133e044fa486ad6a74944aba0511a70
Give clients a way to know which providers have changed state, useful
since LOCATION_PROVIDERS_ALLOWED will be removed in the future.
Bug: 127372321
Test: manual
Change-Id: I16c0acbaad97930bea23084b50193582cc918fa2
This CL introduces a new @hide bind flag BIND_SCHEDULE_LIKE_TOP_APP so
that visible IMEs can have the same thread scheduling policy as the
actual top app, like SCHED_FIFO for UI and RenderThread when it's
available [1] and TOP_APP_PRIORITY_BOOST otherwise [2].
Hopefully this would provide more consistent UI performance and
responsiveness between the actual top app and IME.
[1]: I7b8a31830ad80f7efa00236928d5476998ed4e00
33eb07f575
[2]: Iced88269f7e2d378d5870ded1a5ccf9f259fda57
b783e7b44bf174075f6860d295808ee462b38451
Fix: 117274342
Test: Manually verified as follows.
1. Build aosp_blueline-userdebug and flash it.
2. make -j EditTextVariations
3. adb install -r \
$ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
4. adb shell am start \
-n com.android.inputmethod.tools.edittextvariations/.EditTextVariations
5. Tap the first edit text field to bring up the AOSP Keyboard.
6. Make sure that top app (EditTextVariations) and the IME (AOSP
Keyboard) have the same thread priority / scheduler policy for
their main UI threads and RenderThreads.
adb shell ps -p \
`adb shell pidof com.android.inputmethod.tools.edittextvariations` \
-T -o PID,TID,PRI,SCH,CMD
adb shell ps -p `adb shell pidof com.android.inputmethod.latin` \
-T -o PID,TID,PRI,SCH,CMD
For both UI threads and RenderThreads, Thread Priority should be 29 and
Scheduler Policy should be 0.
7. Tap the back button to dismiss AOSP Keyboard.
8. Make sure that Thread Priority of AOSP Keyboard is no longer boosted.
adb shell ps -p `adb shell pidof com.android.inputmethod.latin` \
-T -o PID,TID,PRI,SCH,CMD
For both UI threads and RenderThreads, Thread Priority should be 19 and
Scheduler Policy should be 0.
Change-Id: I143fb39cec55351b097e835cf8bbf9668e02d86d
