Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
Its broken and isn't worth maintaining, instead port the few things
using it over to SettingsPreferenceActivity with wrapping blank
Activities like the rest of Settings.
Change-Id: Ic82f0dcb63ed9b4078f7da6a79c0c52f0130e8d1
Fixes: 28779941
Update various places in Settings to use "admin" ueser flag
instead of checking user id "0". This should be no-op in
single user mode since the only admin user would be user 0.
In split system user mode, this will correctly ACL admin
user instead of non-interactive system user.
Bug: 19913735
Change-Id: Ida4d59c5f689ea0dc34b3b3ff0822b087fa0afd6
Default phone information is not available for a secondary
user and when accessed using service command *#*#INFO#*#*,
it causes crash in Settings. Removed the preference for a
secondary user.
To verify:
1. Add user(slide down status bar>user icon>Add user>
OK>finish the setup guide).
2. As new user launch Phone app>input “*#*#4636#*#*”>
tap Phone information>check
Causes Settings to crash with:
Caused by: java.lang.IllegalStateException: Default phones haven't been made yet!
at com.android.internal.telephony.PhoneFactory.getDefaultPhone(PhoneFactory.java:214)
at com.android.settings.RadioInfo.onCreate(RadioInfo.java:263)
at android.app.Activity.performCreate(Activity.java:5990)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1106)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2278)
Change-Id: Ie23107c5eead04183cfd8b5460a9a7a3426a99b8
- 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
