GitLab

Change-Id: I170f4347b73055ce204d75cfa1bef5cc22b928b1

Change-Id: Iff09dd159fc2aecef68ce8b3cf26e6832865f7e5

Change-Id: I927a602963d383fbfe12d4b897a2e86bf1783f34

Change-Id: Ib63294fbc8fedc0517f38bbffd4c0fe536866bdc

Change-Id: Icfc39bd1dd0bc38ac5fde300aeb1e8822825d57a

Change-Id: Ifb4497e4ea1453b1afbdd08ed08fddb9055b7251

Bug: 2734813
Change-Id: Iaf4455577be888f6c78f490b2cc046adef41403e

Added some extra checks to ensure that the activity exits from
onCreate, onResume and processMoveMsg promptly when the app
info cannot be refreshed.

Bug: b/2711730
Change-Id: Ied22fadce09326dd33cf201e5e9281990bf3abbd

Putting quotes for password in soft AP is not useful.
It simplifies processing in framework.

Bug: 2708960
Change-Id: If44aeb336732aa8089d3e401b546ebf9b3cbd25a

*poof*

Change-Id: I386473bc6a6cd0d68d1b0a1b4871caef75f1ade8

Multiple quotes cause havoc with netd interaction right now.
The solution is to revert the changes for WifiConfiguration on
Access Point side done in Change I0f1e508b and remove all quotes
in the SSID.

Essentially a low risk one line change on top of the revert.

We dont expose API for WifiConfiguration on AP side. This solution
essentially means we treat SSID in WifiConfiguration on AP side
differently. When we do expose things, we should make things consistent.

Change-Id: I0a7e5074b83ace743fc843ee61c1ff86cde8267f

Change-Id: I6f0e1a9dbaa3b3e81b24de207c3731249d160a59

Bug id http://b/issue?id=2684571

Change-Id: I0f1e508b9a3d0fefcef28235380392368a51e42a

bug:2664412
Change-Id: I6ca955e7fcc299ae1d69892c93c9250229610b19

Change-Id: I8f8a939ba3f383aae36091986cea4e8a6eae13fb

The unpair command was stuck in the queue.

Change-Id: I803cb10adcfaedbe6fd202e0db463593880e4280

Change-Id: If5691d275bf86c94038a53beed65a93dad65b450

For AlertActivity, the dialog needs to display at onCreate() time.
Otherwise, the decor view would be made. Trying to display the
dialog afterward would crash. Changed to AlertDialog instead.

Change-Id: I2ea8463b4c475b9b54746d0a722fa80eea3d4529

Change-Id: I91401f661d61a86d166baac1cad14b8897d0a467

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 "b/2608693 Fix the problem where BT was automatically reconnecting ... after the user unpaired while docked." into froyo

... after the user unpaired while docked.

Change-Id: I65642f440109968387401fc3c103da0f2b15f49f

Change-Id: Iad26aae3d99447eddb6997e66c84080cdce727da

Change-Id: If081ad949cb2aed6b3555275c582e951e579ffc9

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

Bug: 2598014
Change-Id: Ia846367fc479345bfd02c10fe1860373719334eb

It worked with language+country resources but for some resources it's just language.
Added a check to see if we had lanugage+country before deciding which to use.

bug:2605981
Change-Id: Icb667a51f0c376f5188e3a43f264e236cd265468

When scan fails for 3 times, we show a
failure toast and continue to scan.
In one case this caused infinite toasts,
until the user stopped wifi.

Its not clear what can cause this kind of
a state since wifi disable broadcast should
stop the scans. This fix will stop scans
after 3 continuous failures. Any wifi state
change will restart scan.

Bug: 2601937
Change-Id: I68733394cb3c9b76ffb15f7579e7af6c1f54d39c

Change-Id: Ia6989e94efc93e359b4035a1e0a99ab9262b7424

Change-Id: Ia29e5c15fbd147579185c31d03844ccc5a11032e

When airplane mode is enabled, wifi tethering
should be disabled since there is no real
use case for it.

This also addresses the issue
of trying to restore Wifi (with tethering on)
when airplane mode is disabled.

Bug: 2594720
Change-Id: I7379ebed74a58b148ae82ed589d09aa2b9ca767d