This change adds a second timeout to the SecuritySettings page
separate from the standard display timeout.
Change-Id: I033a3578d876148bd723dee5d1a2531be5d6b51d
* Add WifiSettingsForSetupWizardXL as a new Activity
The activity has WifiSettings fragment in it. It also contains
several buttons, texts around the fragment.
* Making configuration UI part of Preference list.
In Wifi Setup for Setup Wizard XL, WifiSettings fragment lets
a UI for configuring access points shown inside a
PregerenceCategory object, while it has been shown as Dialog.
To achieve this action, WifiDialog is decomposed into two parts:
- WifiConfigUiBase (Mainly UI part)
- WifiConfigController (Mainly Wifi controller part)
All codes for wifi configuration in WifiDialog is now in
WifiConfigController, which is reused from
WifiConfigPreference.
* Misc stuff
- Remove AccessPoint#compareTo(). Instead,
AccessPoint.AccessPointComparater should be used when needed.
Change-Id: I520d690d3301837d32f91dad54a973a379ce1989
The logic calling selectFirst() is removed as
- There's no comment why it is needed.
- Actually SetupWizard gets stack as that forces users to see
WirelessSettings in SetupWizard.
The other changes:
- Move back LocalePickerFragment to LocalePicker.
- Make <activity> for LocalePicker in AndroidManifest <activity-alias>
- Add a short comment about how getComponent(), which should be a key
for understanding how top-level settings work.
- Modify LanguageSettings so that it corectly points LocalePicker as
a fragment.
Change-Id: I78d356e40af896ba1aab72fba12c90467371c7b0
- Add button bar feature toward SettingsPreferenceFragment,
which has existed in PreferenceActivity and has been used
(probably) only by Settings app.
- super.onActivityCreated() is not called at the beggining of
WifiSettings#onActivityCreated(), the parent method assumes
the child should have prepared PreferenceScreen, while
WifiSettings cannot do until the parent Activity is ready.
- Call SetHasOptionMenu() should be called AFTER the parent
Activity is ready. It is not documented, so it would be better
to file another bug.
- Add exception to proguard...
Change-Id: Iebd27f0cb0abdbee9b4b1cc9b00f4bf127f7815d
Added a base class SettingsPreferenceFragment from which the settings activities should
be derived so that they can behave like fragments. It contains some commonly called
utility methods and dialog conversion to DialogFragment.
Some of the top-level activities can be launched directly without the left pane.
Settings.java acts as a proxy activity that contains just that settings fragment without
the left pane.
There are still a lot of second and third level activities that need to be fragmentized.
This is just the first pass to test the 2-pane layout.
- Running services now keeps a single data structure to make
switching through the UI a lot faster.
- Display text when there are no apps.
- Fix deadlock.
- Add new preference entry to view manage apps for storage use.
- Etc.
Change-Id: I0f5babf407ed7e84169f59584ddcb6cd0e9d67d9
Merge commit '40686ee81f95699d7a83ccb1ef1be52c0c746d4f'
* commit '40686ee81f95699d7a83ccb1ef1be52c0c746d4f':
Allow soft AP settings config before bring up
Merge commit '15fe0e47958d248300c2f26a463172181b137aca' into gingerbread-plus-aosp
* commit '15fe0e47958d248300c2f26a463172181b137aca':
Allow soft AP settings config before bring up
Merge commit '73550d28df4b7ee2faa39cc4b1b4cc854343632a'
* commit '73550d28df4b7ee2faa39cc4b1b4cc854343632a':
Settings: Add a hook for operator or vendor specific settings.
replaced deprecated getIntent with parseURI
The Settings application now provides a hook that can be used by an
operator or a vendor specific application to add an activity of choice
in the settings menu.
Change-Id: Id55da9fd4262bbfc6a5abf863799c747b0d75b24
This introduces a simplified (thanks, dsandler!) UI for Running Services,
collapsing the groups of apps and processes into single lines. Tapping
on a line moves to a new activity showing details on that group, where the
stop functionality is now available.
This UI is now also integrated into Manage Applications, as the Running
tab. You no longer get a really confusing, misleading, scary list of
every package that appears to be laying around for some reason.
The code was also re-organized, to put everything related to Manage
Applications and Running Services under its own package.
There is still some clean-up -- some performance improvements (such as
not re-computing the world when we switch to the details view), and if
this looks good then eradicating the old running services UI.
Change-Id: I3fc059c18060600742cab5b455d11ff74bf45ae3
Merge commit '64ab5338cb0f90f8ee0787b0b98611670e6dee7e' into froyo-plus-aosp
* commit '64ab5338cb0f90f8ee0787b0b98611670e6dee7e':
Fix regression in removing settings that aren't relevant for a platform.
Bug: 2630695
The PreferenceCategories added into the hierarchy caused removePreference() to
not work, since the preferences to be removed were not immediate children of
the preference screen.
Create empty PreferenceCategory elements and pull the preferences to the same
depth as the categories.
Change-Id: I34826ea4d84cda0ecab75c66a73febe3d51e7c68
Merge commit '19340d213c4bd4428f940a12d82a494f9e7cfaa6' into froyo-plus-aosp
* commit '19340d213c4bd4428f940a12d82a494f9e7cfaa6':
Labeled categories to help clarify Sound prefs.
Under the hood there remain three axes:
1. Are we in silent mode now? | RINGER_MODE_{VIBRATE,SILENT}
2. Do we vibrate in silent mode? | VIBRATE_IN_SILENT == 1
3. Do calls vibrate: | getVibrateSetting(VIBRATE_TYPE_RINGER)
- always | == VIBRATE_SETTING_ON
- never | == VIBRATE_SETTING_OFF
- only in silent | == VIBRATE_SETTING_ONLY_SILENT
We now expose this to the user much more simply by
collapsing (2) and (3) above, and discarding states that
don't make sense:
- VIBRATE_SETTING_OFF + VIBRATE_IN_SILENT
- VIBRATE_SETTING_ONLY_SILENT + !VIBRATE_IN_SILENT
Now we offer the user four choices:
Phone vibrate:
* "Never"
--> VIBRATE_IN_SILENT=0, VIBRATE_SETTING_OFF
* "Always"
--> VIBRATE_IN_SILENT=1, VIBRATE_SETTING_ON
* "Only in silent mode"
--> VIBRATE_IN_SILENT=1, VIBRATE_SETTING_ONLY_SILENT
* "Only when not in silent mode"
--> VIBRATE_IN_SILENT=0, VIBRATE_SETTING_ON
This should make it easier to choose exactly the behavior
the user wants as well as avoid nonsensical combinations of
settings.
Bug: 2598014
Change-Id: I9244d25ec97a3e2b572b71b521049debd22fa4e0
This changes the organization of lock screen security settings
to make choosing an alternate unlock method more discoverable.
Instead of having to disable the old lock method to use a new
one, the user now just has one set/change option in lock settings,
with a list of method-specific setting below it.
In addition, we ask the user to confirm their old credentials
before prompting them to choose a new one, which eliminates one
source of confusion.
Also, ChooseLockGeneric now shows a UI if quality isn't specified.
Any unlock method less secure than minimum specified by
DevicePolicyManager (if active) is greyed out.
Change-Id: Iecc6f64d4d3368a583f06f8d5fe9655cc3d5bd3b
Making sure that the language, country, and variant defaults are always
set to something to ensure that there won't be an NPE.
Dismissing the ListPreference dialogs before a rotation to avoid list
data corruption caused by the list being displayed while its data is
being re-initialized.
Change-Id: Iecdb3b4d415542dc8a4db162c930e6a6570a55f2
Volume (of the ringer, notifications, media, and alarms) may
no longer be adjusted while the phone is in silent mode.
This was the behavior in Eclair and earlier releases.
This rolls back a small portion of change I724c43aa in the
interest of stability (see bugs listed below for weirdness
that occurs when the ringer's SeekBarVolumizer is visible
when the ringtone stream is muted).
Bug: 2552268
Bug: 2544706
Change-Id: I4858e6d85e5ec8c4bba83b649e24dd5915252eb2
This is part 3 of the fix for bug 2364220 "Accessibility improvements for
ending calls".
This change adds a checkbox under "Accessibility settings" to control the
new Settings.Secure.INCALL_POWER_BUTTON_BEHAVIOR value, which allows the
user to specify that the Power button should hang up while in-call
(instead of just turning off the screen.) The checkbox is only shown on
devices that actually have a POWER button.
Yeah, it's a little strange having this under Accessibility (since it's not
that obvious *why* this feature is accessibility-related), but there's no
obvious better place. See discussion in the bug for more info.
Bug: 2364220
Change-Id: I0fd7cf357972519b390575b9c06a4bbe46ff1c9b
All checkboxes and other settings will be available to the
user regardless of whether the device is in silent mode.
(Previously, settings such as ringtone and volume were
dimmed if the phone was silent, which was inconvenient.)
Bug: 2496164
Change-Id: I724c43aa4f5b1a12b95097381844a47c5dcf1e0d
