The phone app needs a way to distinguish between (a) numbers that are
definitely emergency numbers, and (b) numbers that *might* result in an
emergency call being dialed, but aren't specifically emergency numbers
themselves.
(The phone app needs this distinction in order to enforce the restriction
that 3rd party apps should not be allowed to make emergency calls using
the ACTION_CALL intent, while still making sure that the in-call UI only
displays the "emergency call" state for numbers that are *definitely*
emergency numbers. See bug 5493790 for the full details;)
So this change adds a full set of "isPotentialEmergencyNumber()" methods
to go along with the "isEmergencyNumber()" methods we've had all along.
The "potential" variants behave identically to the original methods,
*except* that they ultimately use number.startsWith() rather than
number.equals() when comparing against the list of emergency numbers.
TESTED:
- Unit test 'PhoneNumberUtilsTest#testIsEmergencyNumber' passes.
(The PhoneNumberUtilsTest class doesn't pass in its entirety, but it was
broken before this change also.)
- Also see the commit description of change
Ib949fea3c0ce6b341a90e617a03ba3f22c69018b for the exact tests I ran
against the phone app.
This change should be submitted along with
Change-Id: Ib949fea3c0ce6b341a90e617a03ba3f22c69018b
in apps/Phone (but this change must go in first to avoid breaking the
build.)
Bug: 5493790
Change-Id: Ic528cfcc555734cdaf4ca8a18a50199771ba49b1
Outsiders asking for this list may cause the list to change on another thread.
Fixing general synchronization issues.
bug:5531630
Change-Id: I7a3ee0bba3db40f45bcb0159491942fa4cf38c37
Was mistakenly assuming that Parcel::writeFileDescriptor took
ownership of the fd that was passed in. It does not!
Added some comments and a default parameter to allow the caller
to specify whether it wishes the Parcel to take ownership.
Bug: 5563374
Change-Id: I5a12f51d582bf246ce90133cce7690bb9bca93f6
Also use the AlarmManager instead of messages so the delays
are consistent whether sleeping or not.
Bug: 5534004
Change-Id: I24118b30214dddf8183c1200a89555d6c528e606
Sometimes the interface is removed before we can untether leading to
errors when cleanup up various rules (iptables). Do as much as we can
and then let a re-tether result in error if needed.
bug:5536516
Change-Id: Ib1d064ecc8e9022566f9b0e4678b33144906971c
When a process changes foreground status or dies, NetworkPolicy
updates its internal state with a lock held. In cases where there
is contention, this can block the AMS handler and prevent other
events, such as broadcasts, from being dispatched.
This change moves the incoming AMS events to an existing internal
NetworkPolicy handler thread, where they can execute without
blocking AMS.
Bug: 5497544
Change-Id: Ie0c620a620fd9f0f4eb02af510bd819efa4deb6a
Lets the data traffic arrows work on LTE device on 1x,
but also lets telephony monitor for hung radios on 1X.
bug:5531630
Change-Id: I9fa25a5223afaa2e37373668c899ac28a95783fa
Previously the code ignored SIM state when lockscreen was set to "None."
It now properly accounts for the SIM state when deciding to show.
Change-Id: I272348c1a21b57ac146910850ea3db3adef0227c
BUG=5544671
This initializes the watchdog structure properly. Without this fix, it is
possible to call LOGE with a garbage string value.
Change-Id: Ie05eb65f83eca938f18ac962794407d58c3f277f
It crashed due to the fact that we're committing a fragment change
after onSaveInstanceState() is called. Instead, commit without
storing the state - as the NfcFragment is something that needs
to be setup explicitly anyway, it is not something the user
expects to be restored.
Bug: 5540962
Change-Id: I5a8cd0e47306f2bbc14b592a0182083bb79cb21a
