When the enableOnBackInvokedCallback is set to false (or not set),
registering an OnBackInvokedCallback should be a no-op to avoid
overriding the default compat callback.
Test: Manual testing registering a callback on an app with the flag
disabled and doing a back gesture. Currently we don't have test
executing a back gesture so automated tests are not possible
Bug: 235206960
Change-Id: I54d843f11130a78ed5a68cbe4722e601a2086ee1
Merged-In: I54d843f11130a78ed5a68cbe4722e601a2086ee1
(cherry picked from commit aa48dc3c2d)
switch.
This can happen when one navigates from an activity showing IME
to another activity requesting to show IME. The following sequence would
happen:
- IMM of the current activity receives an UNBIND message with reason CLIENT_SWITCH
- A new IMM is created for the new activity requesting input and
requests to bind.
- The new IMM requests to start input, triggering
IMS#dispatchStartInputWithToken with a *new* ImeOnBackInvokedDispatcher instance than the one previously kept by IMS.
Previously, the ime dispatcher instance was updated before the existing
back callback was unregistered and caused the unregister call to fail.
The fix is to update the dispatcher after the other logic in
IMS#dispatcherStartInputWithToken (specifically, to after startInput(),
which calls doFinishInput() if input is already started).
Bug: 234416098
Test: atest CtsInputMethodTestCases
Change-Id: Ic7a5daab8709b808343388b095b5b6ad40adc777
There exists a configuration value to determine if the nav bar should
be shown when the keyboard is open. The InsetsPolicy should respect this
value. This value is currently used on automotive devices but doesn't
necessarily need to be restricted to a particular device type.
Bug: 229256359
Test: manual
Change-Id: I57ea71193476cb88bba8d406d039fe08e05a6b1c
We currently close the IME by having the target application forward KEYCODE_BACK to the IME process through InputMethodManager#dispatchInputEvent and having the IME handle the keycode in InputMethodService#onKeyDown. When apps opt in to OnBackInvokedDispatcher API, we will not dispatch KEYCODE_BACK to apps anymore. Thus we need to migrate IME to the new API for it to close on back invocation.
This implementation forwards OnBackInvokedCallbacks from the IME process
to the app process. This is necessary because all callbacks need to
exist in the app process for them to be considered by hardware back keys. While back gestures go through WM to resolve callbacks from the focused window, hw keys are directly sent to the focused window's ViewRootImpl, bypassing server side back nav logic.
Bug: 228358882
Test: atest CtsInputMethodTestCases:KeyboardVisibilityControlTest
Test: atest CtsInputMethodTestCases:InputMethodServiceTest
Test: atest CtsInputMethodTestCases
Change-Id: Ie207b63b11a56c9b2173f26b734a27b13ebccc60
Shorten IME surface caching so that we can avoid showing cached IME
surface when IME insets have changed from the last time it was shown.
Fix: 221458652
Bug: 230762351
Test: Manually using steps:
1. Go to gboard settings and enable Emoji bar
2. Open a chat in messages app
3. tap editor and make sure Insets dont change after show
animation completes.
Change-Id: I4c2a9c272ef0e7be7128ca64abebd3a3b7d2d7a4
As ViewTreeObserver.InternelInsetsInfo.touchableRegion with setting
TOUCHABLE_INSETS_REGION requires setting the region that relative
the window position, but CL[1] uses the global screen position to
calculate the touch region, which will affect the end result,
To fix this, we should use getLocationInWindow to get the relative
position of the window.
[1]: I0fe54efac80dd0d55f4ba37cfa7d7188b642abb0
Fix: 229562319
Test: manually verified with the IME mentioned in the bug.
Test: ensure Bug 226566506 is verified.
Change-Id: I9e3fe45dccb263445d378b5ac17b0e450bdb1c24
Currently, IMMS will be notified asynchronously when an IME hide
animation finishes, via message dispatching through IMS
(IMM#notifyImeHidden -> IMS#notifyImeHidden -> IMMS#hideMySoftInput).
This creates a race condition when IMM#showSoftInput or WIC#show is
called around the end of hide animation.
This CL fixes the race condition by synchronously and directly
calling IMMS#hideSoftInput from IMM#notifyImeHidden.
Note that there is still another race condition for IMM#showSoftInput
(not WIC#show) if it's called during an IME hide animation;
IMM#showSoftInput ended up calling WIC#show asynchronously, but at that
time the running IME hide animation may have already been finished
successfully and WIC#show may fail to cancel the hide animation
(then the cleanup IMM#notifyImeHidden hides the IME again disruptively).
I will fix the latter issue in a separate CL.
Bug: 221483132
Bug: 225674038
Test: atest InputMethodStressTest
Test: atest CtsInputMethodTestCases
Test: atest WindowInsetsAnimationControllerTests
Change-Id: I7c71dc5a1d6b61aa79d1666f0e257e6401e4adb2
(cherry picked from commit 9065310f81)
Merged-In: I7c71dc5a1d6b61aa79d1666f0e257e6401e4adb2
This reverts commit 38be9e32f1.
Reason for revert: Caused b/229642813 and b/229355440
Bug:229642813
Bug:229636388
Change-Id: I65e4f66ec2156d4e0812753d71ac82afd965fe3b
This is a follow up CL to our previuos CL [1], which enabled
AccessibilityService to use a subset of InputConnection APIs.
In that CL we have reused existing AIDL interfaces that were designed
and maintained for IMEs for simplicity, where a non trivial amount of
unnecessary IPC endpoints were included.
From the security and maintainability viewpoints, however, exposing
unnecessary IPC endpoints is discouraged in general. To address such
concerns this CL introduces a set of dedicated IPC definitions for
A11yIME so that we do not need to reuse IPCs for IMEs.
This CL also stops passing InputBinding object to A11yIME process as
it contains IInputContext Binder Proxy, which can still be used to
directly invoke fallback InputConnection. This is doable now because
A11yIME no longer relies on fallback InputConnection [2].
This CL is should not have any observable changes in the semantics.
End-to-end CTS tests guarantee that everything is still working as
intended now and in the future.
[1]: Ia651a811093a939d00c081be1961e24ed3ad0356
fb17e5ae7a
[2]: I2af3cd50444d8ddf25aa0f6479238156914e6fff
dc635efb68
Fix: 215633021
Fix: 215636776
Test: atest CtsInputMethodTestCases:AccessibilityInputMethodTest
Test: atest CtsAccessibilityServiceTestCases:AccessibilityInputConnectionTest
Test: atest CtsAccessibilityServiceTestCases:AccessibilityImeTest
Change-Id: I5ff2e804cbcf90828370a0612ff54111130bdff4
We currently close the IME by having the target application forward
KEYCODE_BACK to the IME process through InputMethodManager#dispatchInputEvent and having the IME handle the keycode in InputMethodService#onKeyDown. When apps opt in to OnBackInvokedDispatcher API, we will not dispatch KEYCODE_BACK to apps anymore. Thus we need to migrate IME to the new API for it to close on back invocation.
This CL migrates the client side IME code to register and unregister callbacks, and also updates the WM side logic to make sure IME callback priority works correctly with other application callbacks.
Test: In BackTestApp home activity, Show IME -> try swipe back. Open WidgetTestActivity, show IME by clicking on EditText -> try swipe back.
Test: Install Micrsoft SwiftKey. Set as primary IME. Repeat the above
steps in BackTestApp and make sure IME behaves correctly.
Bug: 228358882
Change-Id: Idb246cf1858a7515f6fc34a5ccde33f25f56d404
This is a follow up CL to my previous CL [1], which aimed to
automatically adjust InputMethodService.Insets so that the tap events
on the navigation bar region can be sent to the IME.
What I forgot was that View#get{Left,Top,Right,Bottom}() returns
values in the window local coordinates, not in the screen coordinates.
As a result, in some cases the keyboard area could become untouchable
unless the IME specified
ViewTreeObserver.InternalInsetsInfo.TOUCHABLE_INSETS_REGION
to
InputMethodService.Insets#touchableInsets.
With this CL, touchable region should be correctly calculated.
[1]: I3e7e1f83554444131e2765dc159617bb9e2337c7
ff7b453ca8
Fix: 226566506
Test: manually verified with the IME mentioned in the bug.
Change-Id: I0fe54efac80dd0d55f4ba37cfa7d7188b642abb0
This is a preparation to fix Bug 226566506.
There should be no behavior change in this CL.
Bug: 226566506
Test: presubmit
Change-Id: Ib4b8b1ce66bb64c0a710750af4ca95b5b2c9e9e8
Given the current schedule, it might be a bit unrealistic to clean up
all the remaining TODO(b/217397817) in Android T time frame.
Let's merge them into TODO(b/215443343), which is already punted to
Android U.
This CL is only about TODO comments. There should be no observable
behavior change.
Bug: 215443343
Fix: 217397817
Test: presubmit
Change-Id: Ia9d4277d44e43a31f91d791a23ec894c33cc9d29
Finish stylus handwriting session when user swipes to recent.
Bug: 223748964
Test: Manually:
1. Open an app with editor
2. swipe on editor with stylus [or emulated stylus]
3. Observe ink trail drawn on screen
4. quickly sipe to recents, ink should go away.
5. repeat steps 1-3 for swipe to home
Change-Id: Id750ff55cb447247c3eca75daf37cb5aeb1d0cfa
As of today we show the InkWindow and dispatch Stylus events without
waiting. At the time of dispatch, InkWindow is not added and first stylus gesture
is skipped. In order to deliver the first gesture to IME, we should wait until
InkWindow is added and IME's Inking View is attached.
However, waiting for it will introduce latency in the system. To counter
that, we introduce a new API method to listen for Stylus MotionEvent.
IME can override the API method to listen to MotionEvents sooner.
By default, the stylus MotionEvents are buffered until Ink view is visible.
Change-Id: I3a18067da45fd15bf0f6e377da0a82cdd6df1d41
Fix: 222081673
Test: atest StylusHandwriting
It is expected the onIntialize() is called before onBindInput(), however
it's not precisely known why onBindInput() is being called prior to onIntialize().
Once possibility is it could be that onDestory() is being called
and init was skipped and call made it to onBindInput().
Replacing precondition with an early return should be safe here.
Fix: 223083664
Bug: 223443508
Test: atest CtsInputMethodTestCases
Change-Id: I8312d98b0349fbc661b6eb0f4c47bea25ffbb2a9
This is a mechanical cleanup CL. There should be no behavior change.
Bug: 215443343
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/navigationbar/ \
| grep ".java:"
Change-Id: Ib9dcddc675bdd540ae93a1eb5b1db00d1dccecb1
This is a mechanical cleanup CL. There should be no behavior change.
Bug: 215443343
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/navigationbar/ \
| grep "camel-case"
Change-Id: I05b25b11c6b571407bc4a707161fb993960603f9
This is a mechanical cleanup CL. There should be no behavior change.
Bug: 215443343
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/navigationbar/ \
| grep "whitespace"
Change-Id: I342af73d675f6432b16acd2604d2e43a5055b701
This is a mechanical cleanup CL. There should be no behavior change.
Bug: 215443343
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/navigationbar/ \
| grep "modifier"
Change-Id: Idf3c8d13c63770397e895bc05ba2374c10fb3bd1
This is a mechanical cleanup CL. There should be no behavior change.
Bug: 215443343
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/navigationbar/ \
| grep "Missing a Javadoc comment"
Change-Id: I5cb365b69864a145e7eaf7ff4454c261324ab845
This is the third attempt to enable
IMS#canImeRenderGesturalNavButtons()
by default. The first attempt [1] was reverted due to Bug 217668258.
The second attempt [2] was reverted due to Bug 219604375 and
Bug 218322263.
With this CL, the back button and IME switcher button on the
navigation bar are rendered by the IME when gestural navigation mode
is enabled.
The new behavior can still be manually disabled as follows
adb root
adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons false
adb reboot
The only observable behavior change we are aware of is that now those
buttons are included in the task screenshot in Recents.
Other than that, there should be no observable behavior change.
[1]: I45e511f5cfec93cdd002d23c091b4fe735b28227
793e152713
[2]: I39f454a2d41d7d5255b8cc4f7d9a3f7a7642b2f3
f21d211559
Fix: 215545985
Test: Manually tested with ThemedNavBarKeyboard sample
1. Build aosp_coral-userdebug and flash it
2. Enable gesture navigation mode.
3. make -j ThemedNavBarKeyboard
4. adb install -r \
$OUT/system/app/ThemedNavBarKeyboard/ThemedNavBarKeyboard.apk
5. adb shell ime enable \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
6. adb shell ime set \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
7. Open the Dialer app
8. Tap "EXTENDED LIGHT NAVIGARION BAR" mode
9. Make sure that the navigation button color is optimized for light
navigation bar.
10. Tap "STANDARD LIGHT NAVIGARION BAR" mode
11. Make sure that the navigation button color is optimized for light
navigation bar.
12. Tap "FLOATING MODE" mode
13. Make sure that the navigation buttons are visible.
Test: Manually verified as follows.
1. Build coral-userdebug and flash it
2. Make sure that the back button is shown on the setup wizard
no matter whether the IME is shown or not.
Test: Manually verified as follows.
1. Build aosp_coral-userdebug then flash it.
2. adb root
3. adb shell setprop persist.sys.ime.can_render_gestural_nav_buttons true
4. adb reboot
5. adb install -r TestDPC-normalv8001.apk
6. adb shell am start -n com.afwsamples.testdpc/.SetupManagementLaunchActivity
7. Set up work-profile
8. make -j EditTextVariations
9. adb install -r \
$ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/arm64/EditTextVariations.apk
10. adb shell am start --user 0 -n \
com.android.inputmethod.tools.edittextvariations/.EditTextVariations
11. adb shell dumpsys input_method | grep mNavigation
-> "mNavigationBarController={mImeDrawsImeNavBar=false, ..."
12. Enable gesture navigation
13. adb shell dumpsys input_method | grep mNavigation
-> "mNavigationBarController={mImeDrawsImeNavBar=true, ..."
14. adb shell am start --user 10 -n \
com.android.inputmethod.tools.edittextvariations/.EditTextVariations
15. adb shell dumpsys input_method | grep mNavigation
-> "mNavigationBarController={mImeDrawsImeNavBar=true, ..."
Change-Id: Iec55ce12e8198e243cdd716ab7c52d0f3939c279
This CL rewrites my previous CLs [1][2], which were written with an
incorrect assumption that config_imeDrawsImeNavBar was overlaid for
the entire profile group.
While SysUI's navigation mode is dynamically configurable with Runtime
Resource Overlay (RRO), it turns out that we currently configure RRO
only for the profile parent user. This means that processes run under
other profile users continue seeing the base resource value regardless
of how RRO is configured for the profile parent user. This is the
root cause of Bug 219604375.
To work around this limitation, this CL uses InputMethodManagerService
to monitor the value of config_imeDrawsImeNavBar for the profile
parent user then to propagate it to the IME process. Luckily we have
already been doing a similar thing for the IME switcher visibility.
What this CL does is 1) adding a new flag to InputMethodNavButtonFlags
then 2) just using the flag sent from IMMS instead of directly reading
config_imeDrawsImeNavBar
NavigationBarController.
Alternative solutions considered:
* Set RRO for profile users
One of straightforward ways to address this problem is letting the
Setting app apply the same RRO for other profile users. However,
this could be tricky when 1) the user changes navigation mode then
2) sets up a new profile, because the Settings app is not an
always-running process. While we might be able to rely on
com.android.settings.SettingsInitialize#onReceive()
to do so, the profile user's state could be left in a broken state
if that method was somehow interrupted. To minimize the risk, we
decided to not take this approach for T.
* Make OverlayManager be aware of profile groups
Given how RRO is used in SysUI, it's make more sense if
OverlayManager natively supports resource overlay for the entire
profile group. However, introducing such a new concept is too late
for Android T. We have filed Bug 221443458 to see if we can do this
in a future version of Android.
[1]: I3e7e1f83554444131e2765dc159617bb9e2337c7
ff7b453ca8
[2]: Id0cfa44cce5de515dc5d28254e1d41bdfc01e201
177e4aafdb
Fix: 219820813
Test: Manually verified as follows
1. Build aosp_coral-userdebug then flash it.
2. adb root
3. adb shell setprop persist.sys.ime.can_render_gestural_nav_buttons true
4. adb reboot
5. adb install -r TestDPC-normalv8001.apk
6. adb shell am start -n com.afwsamples.testdpc/.SetupManagementLaunchActivity
7. Set up work-profile
8. make -j EditTextVariations
9. adb install -r \
$ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/arm64/EditTextVariations.apk
10. adb shell am start --user 0 -n \
com.android.inputmethod.tools.edittextvariations/.EditTextVariations
11. adb shell dumpsys input_method | grep mNavigation
-> "mNavigationBarController={mImeDrawsImeNavBar=false, ..."
12. Enable gesture navigation
13. adb shell dumpsys input_method | grep mNavigation
-> "mNavigationBarController={mImeDrawsImeNavBar=true, ..."
14. adb shell am start --user 10 -n \
com.android.inputmethod.tools.edittextvariations/.EditTextVariations
15. adb shell dumpsys input_method | grep mNavigation
-> "mNavigationBarController={mImeDrawsImeNavBar=true, ..."
Change-Id: Id3d6a71d8ba1bfa49131350b68aa8d3424eca381
This CL reworks my previous CL [1], which let
InputMethodManagerService report whether the IME switcher icon needs
to be shown or not to the IME process by using IInputMethod IPCs.
It turns out that we need to propagate one more boolean value in order
to address Bug 219820813. It'd be much clearer if we use bit flags
rather than adding a new boolean parameter to each IPC method. Thus
this CL rewrites my previous CL by using a bit flag defined in a newly
introduced InputMethodNavButtonFlags.
This is a purely mechanical refactroing. There should be no behavior
change.
[1]: I5de9ac0dc8670842edf66306bb4c281c77cea376
75b935a12b
Bug: 215551357
Bug: 219820813
Test: Manually verified with for the following scenarios:
* Enabling/disabling multiple IMEs
* Attaching/detaching a hardware keyboard
* Showing/hinding the IME switcher
* Showing an IME on the lock screen
Change-Id: I81cb062a08d484ec8ce5d7b2fea64ce19028f82e
When starting a handwriting session, update the handwriting input window
so that it is configured with the IME's pid and uid. This means any ANRs
that occur due to the handwriting input window will be directed to the
IME process.
Since oneway binder calls do not have pid information, we cannot use
Binder.getCallingPid() to get the pid of the IME. Instead, we report the
pid from IMS when starting handwriting.
Bug: 210978621
Test: manual with custom IME, verify ANR is directed to IME.
Change-Id: Ia6963eb02cad22c7f604896e6c78ed31c84e32f6
Merged-In: Ia6963eb02cad22c7f604896e6c78ed31c84e32f6
(cherry picked from commit 58df52232a)
This reverts commit f21d211559 [1].
Reason for revert:
IME Nav buttons are unexpectedly invisible in the following cases.
* work profile apps (Bug 219604375)
* setup wizard (Bug 218322263)
[1]: I39f454a2d41d7d5255b8cc4f7d9a3f7a7642b2f3
Bug: 215545985
Fix: 219604375
Test: Manually verified as follows.
1. Build aosp_coral-userdebug and flash it.
2. adb install -r TestDPC-normalv8001.apk
3. Set up work-profile
4. Enable gestural navigation mode
5. adb shell am start --user 10 -n \
com.android.documentsui/com.android.documentsui.files.FilesActivity
6. Tap the magnifier icon to show the AOSP Keyboard
7. Confirm that the back button is shown on the nav bar
8. adb shell dumpsys input_method | grep mNavigationBarController
-> "No-op implementation"
Change-Id: If3da8dbad0b8bd204cc4ec04f882e9248439c456
This is a clean up CL to our previous CL [1], which introduced an
unused @hide method
InputMethod#setCurrentShowInputToken().
Since that method has never been called, there should be no behavior
change in this CL.
[1]: Ia49e23dd077d264a58d28a7b8acffde54b7db187
bb0e2f753b
Bug: 111084606
Bug: 192412909
Test: presubmit
Change-Id: Idd607ef62c91a92006da4bf26a86338ea7224ce8
This is a clean up CL to our previous CL [1], which introduced an
unused @hide method
InputMethod#setCurrentHideInputToken().
Since that method has never been called, there should be no behavior
change in this CL.
[1]: Ia596a392eb73ae46debd097151c8c9a7edd59833
44e2ae4afc30b6a873e1536e31619db258f6cf00
Bug: 133381284
Bug: 149870112
Bug: 192412909
Test: presubmit
Change-Id: I8906360dc51ad3468b9ce4c97d477ae9bcdb2e91
Ensure onPrepareStylusHandwriting() is always called before
onStartStylusHandwriting().
Test: manually using HandwritingIme
Bug: 217957587
Change-Id: I6f1b8a93a76dbb34d3323439253a3394c05d98a8
With this CL, IME and SysUI start checking
config_imeDrawsImeNavBar [1]
instead of
config_navBarInteractionMode
when determining whether the IME should render the back and IME
switcher buttons or not.
There should be no observable behavior change as long as
config_navBarInteractionMode
is set to true when the gestural navigation is enabled.
[1]: I0651a99b6007a84be63b85b579a85af0f24bb6ec
Fix: 216118048
Test: manual
Change-Id: Ifdfd23612f6cb2bfe6ddf302e3caac1e342a8a1e
InputMethodService is the primary and a11y is the secondary.
InputMethodService is not
affected by a11y status. When the session from input method is
established, app can start input (pass input context to input method).
When an a11y session comes back, it will be passed to the app. When
InputMethodManagerService binds to/start input with
InputMethodService, it does the same to a11y services which
requested IME functionalities.
It is possible that input method can edit text before ally sessios are
established. So the EditorInfo passed to a11y could be stale.
So when an a11y session is passed to client, client will send
a notification (input method doesn't have this extra notification) for
the current selection. I think since the time for a11y session establish
shouldn't be long, and we get the current state later, it should be fine
for a11y services.
When input method is disconnected from app (client) (even for input
method switching), we cleared a11y and sessions too. When
input method request sessions, we must rerequest sessions for a11y. This
is mainly because when we unbindCurrentClientLocked(SWITCH_IME), we set
active to false for the current client. Suppose we don't want to
change the current structure of input method, an inactive client
probably should clear accessibility sessions too.
When we switch to a client which already has a session with input
method, there might be some a11y sessions with this client, and
some a11y services might be disabled or enabled while the client was
switched out. We pass unchanged a11y
sessions to client, and request sessions for newly enabled a11y services.
When an a11y service is disabled, it removes its session
from all clients in InputMethodManagerService.
Test: type word through modified "switchToInputMethod". Tested session
notification through logs. Tested client switching, input method
switching, a11y service enabled/disable, multiple a11y services,
a11y service enabled before device reboot.
Also tested work profile.
Bug: 187453053
Change-Id: Ia651a811093a939d00c081be1961e24ed3ad0356
This may not exist at this point (or at all depending on the device
configuration)
Change-Id: Ida9b5f4eadfd2620d7b74171268cf266f77f7b3d
Test: manual - bring up the keyboard on a TV
Fix: 218228687
This is the second attempt to enable
IMS#canImeRenderGesturalNavButtons()
by default. The first attempt [1] was reverted due to Bug 217668258.
With this CL, the back button and IME switcher button on the
navigation bar are rendered by the IME when gestural navigation mode
is enabled.
The new behavior can still be manually disabled as follows
adb root
adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons false
adb reboot
The only observable behavior change we are aware of is that now those
buttons are included in the task screenshot in Recents.
Other than that, there should be no observable behavior change.
[1]: I45e511f5cfec93cdd002d23c091b4fe735b28227
793e152713
Fix: 215545985
Test: Manually tested with ThemedNavBarKeyboard sample
1. Build aosp_coral-userdebug and flash it
2. Enable gesture navigation mode.
3. make -j ThemedNavBarKeyboard
4. adb install -r \
$OUT/system/app/ThemedNavBarKeyboard/ThemedNavBarKeyboard.apk
5. adb shell ime enable \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
6. adb shell ime set \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
7. Open the Dialer app
8. Tap "EXTENDED LIGHT NAVIGARION BAR" mode
9. Make sure that the navigation button color is optimized for light
navigation bar.
10. Tap "STANDARD LIGHT NAVIGARION BAR" mode
11. Make sure that the navigation button color is optimized for light
navigation bar.
12. Tap "FLOATING MODE" mode
13. Make sure that the navigation buttons are visible.
Test: Manually verified as follows.
1. Build coral-userdebug and flash it
2. Make sure that the back button is shown on the setup wizard.
Change-Id: I39f454a2d41d7d5255b8cc4f7d9a3f7a7642b2f3
