Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
This CL only changed AlertDialog imports.
So, reviewer can review it easily.
Change-Id: I097bc44394195b14287f4f920c570ac8653f356a
Fixes: 111413092
Test: This CL can't pass Robo test.
This patch focused on fixing compile errors and some runtime errors.
Test: We can't test it now. But we will have an integration test later.
Bug: 110259478
Change-Id: I16c471ddcd0fa1460c665b7f74d86fcace5ee67b
This is logical revert of a CL [1] that was recently re-introduced as
part of my recent CL [2].
Reason for revert:
Directly showing the layout selection screen when there is no hardware
keyboard is selected yet is not something people had been familiar
with.
That behavior had been enabled only in a short period during Android N
development cycle and was never enabled in most of production builds.
To avoid confusions, let's revert back to the true Android M behavior
by logically reverting that change.
[1]: I4483dfc89afc8d148b2cfa7c6a5f66d2a02f712a
17b6319884
[2]: I7a2ed6dd39dcd8207d3d94e12cd01d5d67ba4bb5
7129b374bb
Change-Id: If0529e20cbff432d38d9b2dd74eeb3af0da5baf1
Bug: 66498367
Fix: 75318417
Test: Manually verified
Implements selection of keyboard layouts using the new InputManager
methods that associate keyboard layouts to
device/InputMethodInfo/InputMethodSubtype
See: Ie88ce1ab77dbfe03ab51d89c1dc9e0a7ddbb3216
Bug: 25752812
Change-Id: Ib76880d66391ca37978054de80f4b3b5147cecc3
1. Introduces new UI components as per the new flow
2. Temporarily disables components in the old flow that are to be
replaced by the new flow. This is done so we can neatly revert
to the old flow if there are issues with the new flow
3. AvailableVirtualKeyboardActivity now responds to
android.settings.INPUT_METHOD_SETTINGS intents instead of
InputMethodAndLanguageSettingsActivity
Bug: 25752812
Change-Id: I728d7ee185827ed328c16cb7abce244557a26518
When a user clicks on the physical keyboard in order to select a
layout, rather than showing them a dialog with an empty list of
layouts, send them straight to the screen where they can pick which
layouts to enable.
Also, only request keyboard layouts that are appropriate for the
input device we're in the process of configuring.
Bug: 25062009
Change-Id: I4483dfc89afc8d148b2cfa7c6a5f66d2a02f712a
- get rid of PreferenceActivity as much as we can and use fragments instead
- add Drawer widget
- add Dashboard high level entry into the Drawer (but this is work in progress and would be done in another CL)
- add bypass of fragment's Header validation when launched from the Drawer but *force* validation if external
call thru an Intent
Be aware that WifiPickerActivity should remain for now a PreferenceActivity. It is used by SetupWizard and should
not trigger running the SettingsActivity's header building code. SetupWizard is a Home during the provisionnig process
and then deactivate itself as a Home but would make the Home header to appear in the Drawer (because momentarily we
would have two Home).
Also, verified that:
- the WiFi settings still work when called from SetupWizard
- when you have multiple Launchers, the Home header will appear in the list of Headers in the Drawer
Change-Id: I407a5e0fdd843ad7615d3d511c416a44e3d97c90
This is part of work on making key layouts get saved per vendor/product
instead of per device. The corresponding change in fw is
https://googleplex-android-review.git.corp.google.com/#/c/399886/
This changes all uses of InputDevice descriptor to InputDeviceIdentifier.
Change-Id: I3eeebc0223820aeab62c2b8aa822f4d91adaf2d1
