- 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
When user decides to change tts engine, and if it's not system one,
then he sees dialog warning about possibility of sending all kinds of
data to the engine.
If user chooses to not changes engine, radio button still sticks to the
new position.
This change delays all operations regarding changing current engine
after user closes dialog. It also unsets the radio button if user chooses
to cancel it.
Bug: 7628362
Change-Id: I977abe71b3547f2545a971fc0d69179be6fafb44
If engine is not active, its settings icon is disabled in
Settings > Language & input > Text-to-speech output screen.
Currently, settings icons for all TTS engines are shown at
the same opacity. This fix dims settings icons of not-selected
engines.
Make sure that more than one TTS engine are installed on the
target, for e.g., Google Text-to-speech Engine and Classic
Text To Speech Engine (SVOX Classic TTS).
Additionally, since setAlpha() is used in multiple places within
Settings package, moved DISABLED_ALPHA declaration to Utils.java
in order to have single point of reference.
Change-Id: Ifa7de79814a2f4a4aa021cd8621cbfab41655680
Signed-off-by: Shuhrat Dehkanov <uzbmaster@gmail.com>
The issue is that Fragment.setVoiceDataDetails can
be called before Fragment.getView. We guard against this
issue. No thread visibility issues here because both functions
are called on the UI thread.
bug:5884355
Change-Id: Iad91b91c58b04dcb9f34f6b5ff8752f2e8295423
