Initially set to 3 minutes this raised the standby current
by 12.5% so changing to 6 minutes.
Bug: 5534004
Change-Id: I602f5fe4de35d0db2dbacf0c615c300c57dd2d0d
1. Fix the ClassCastException while handling spec out 'Setup menu'
-Ghana MTN simcard and JDI simcard sends abnormal 'setup menu'cmd.
-Those 'setup menu' is spec out.
-At the end of the proactive cmd,extra bytes '0x00 0x00 0x00 0x00' is
followed.
- That cause ClassCastException and phone crash.
Bug: 5574160
Change-Id: Ieafb6c4efd94bb4e2a39a04612a6761c958654bb
Signed-off-by: dujin.cha <dujin.cha@samsung.com>
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
- Precondition: config_sms_enabled_single_shift_tables is configured as
1 (Turkish) in frameworks/base/core/res/res/values/config.xml
- Cause: There is no consideration for National Language Shift Tables in
SmsMessage::fragmentText function.
- Solution: The header length is calculated properly according to
National Language Shift Table
- modified to add test cases and fix calculation bug (jhamby@google.com)
Bug: 5553544
Change-Id: I9eaefbbd6b3d75f8c41cbf9d0cb03a701cfa1cb3
Outsiders asking for this list may cause the list to change on another thread.
Fixing general synchronization issues.
bug:5531630
Change-Id: I7a3ee0bba3db40f45bcb0159491942fa4cf38c37
Sometimes the lockscreen view is recreated even though it has already
been created (and therefore Face Unlock is already running). One
example of this is when the lockscreen momentarily displays in
landscape mode and then corrects itself into portrait mode.
When lockscreen recreates itself, it removes the view and then later
re-adds the view. During that time the window token is null and may
be passed to Face Unlock when it tries to restart. The reason this
doesn't happen *every* time the view is recreated is because the
onServiceConnected() callback starts Face Unlock, and usually it
runs after the view is re-added, but sometimes it runs before the view
is re-added, resulting in this bug.
An earlier fix put null-token checking inside of the Face Unlock
service, which prevented crashing but Face Unlock was still unable
to run. This fix makes the null token case not happen so Face Unlock
can run every time. It accomplishes this by simply not restarting
Face Unlock until the view has been re-added.
This fix also replaces checking two flags everywhere to see if
Face Unlock is being used and instead uses a single function call.
Change-Id: Ib46f25f2a58ab2e70470337861c25ee81a858873
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
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
