Currently, the emergency calls are put into an readonly property ro.ril.ecclist.
It is possible that ecclist has to be changed before and after SIM pin lock.
And ecclist can also be changed after network broadcasts the local emgergency numbers.
So add r-w property ril.ecclist to make emergency number list changable, while still
check r-o property to make old RIL work.
The current implementation does not take care of location changes in the case
the network location is not enabled. The fix will use the passive location provider
to receive any location updates (gps and network) and using the network location
provider to trigger the passive provider.
Change-Id: I851bb1ff90e9103712a0e741528a6dfa5d4353c8
Some devices will not activate the light sensor properly on boot
unless we do this.
Change-Id: Ia27b6fc2d515c31eb8597e1d52127d70e2643bd7
BUG: 2269307
Signed-off-by: Mike Lockwood <lockwood@android.com>
If scheme is unspecified let package parse continue. We will return
errors if parsing fails anyway.
If scheme is not null, restrict it to being a file uri.
Fix a bug in DataConnection state machine where the notification
of disconnection completion was sent before we actually transitioned
to the in active state. Also, change conn.reset to send a response
so the user can know when the transition to the in active state
completes for that also.
bug: 2471897
Change-Id: I5776324ac89a607925d07f4a600bc5b34c3f3ed6
All direct calls to mConnector in ExpandableListView should convert group/child flat positions
to/from absolute flat positions (that take header count into account).
Two conversion methods were added to do that.
If a search provider returns an extra in the cursor with the key
SearchManager.CURSOR_EXTRA_KEY_IN_PROGRESS, and the value true, then
the spinny in the search dialog will not stop, but the cursor
contents will still be used to update the results. This way, partial
search results can be sent while the user is informed that the search
is still in progress.
Also make the usb interface configuration more robust so retries are possible.
Makes all Tethering errors recoverable - no harm letting them try again anyway. Worst case
is they need to reboot.
