We did this only if connected in most places, but screen-on/off didn't
care. On no-radio devices it caused extra timers/wakeups that
didn't help anybody.
bug:6375908
Change-Id: Iba72da323de716acb0e67361b955c7381f18f67d
This refactoring sets the stage for a follow-on change that
will make use additional functions of the power HAL.
Moved functionality from android.os.Power into PowerManagerService.
None of these functions make sense being called outside of the
system server. Moving them to the PowerManagerService makes it
easier to ensure that the power HAL is initialized exactly once.
Similarly, moved ShutdownThread out of the policy package and into
the services package where it can tie into the PowerManagerService
as needed.
Bug: 6435382
Change-Id: I958241bb124fb4410d96f5d5eb00ed68d60b29e5
Correct some logging that was misleading and be more precise in our
removal of things from the waiting list.
bug:6445253
Change-Id: I97b20b851617149a24303276392de403dbde2a8f
The permission check for IccSmsInterfaceManager.sendText() was changed from
enforceCallingPermission() to enforceCallingOrSelfPermission() to enable the
Phone app to send SMS's directly for the "reply by SMS" feature. That feature
was implemented in a different way (handled by the MMS app), so the permission
check can be changed back to the original enforceCallingPermission(). Verified
that SMS can still be sent, including "reply by SMS" for an incoming call.
Bug: 4686733
Change-Id: If844a0c485de0a87857d8f82a3452e776005153e
If the FSM gets restart while waiting for one of
SPN EFs results (i.e. a SIM refresh occurs after issuing
read EF_CPHS_SPN), it will re-initialize only after
receiving and discarding the unfinished SPN EF result.
bug:5499225
Change-Id: I715fc2feabdd03435903f7dcb785c8f0154619bc
We shouldn't tell people we're not connected due to roaming if it's really because
of data-disabled.
Use the data-disabled setting to decide if we should inform people about
data-discon due to roaming. Note this doesn't effect other notifications about roaming.
Also fix the data-enable/disable code to take roaming into account and clear/set the
roaming notification as needed (if data is enabled while we can't get on due to roaming
we should put up the roaming notifcation.. if data is disabled while that notification is
up we should take it down).
bug:5805666
Change-Id: I5c925dfdca4abc27e0034b113508df5719f04fae
We used to only prefer it when connecting for default connection purposes,
but it makes sense to use the preference for all apn types it supports.
bug:6377793
Change-Id: I8b26b77fc0787121749cce9d32303ab24cc72c75
This won't be shown in usual condition since in most cases the method
will just use the block just above the logging and return true/false
there. On the other hand this might be useful if the case is truely
exceptional and thus this path is really used.
Bug: 5914560
Bug: 6383850
Change-Id: I2242f93a9b905b5a39d997aa30d9fd6f5bfbdf49
When APN is edited, if authType and username are both not
set, authType should be set to NONE before setup of
data call.
The code today checks mApn.user for NULL, but if
user has edited APN the mApn.user field will be set
to an empty string.
Change the check of mApn.user to also take care of
this case.
Change-Id: I0e49247d46e1ba93da6dd951bbb75acc63fac73f
The CellBroadcastReceiver app will allow apps with the new permission
"android.permission.READ_CELL_BROADCASTS" to read previously received
cell broadcast messages from a new ContentProvider database at URI
"content://cellbroadcasts". This will enable third parties to provide
additional information to users in the event of emergencies without
delaying or interfering with the initial system alert dialog to warn
the user when the alert is received.
Includes a new android.telephony.CellBroadcastMessage class which
can be instantiated from the Cursor retrieved from the ContentProvider.
This was previously a part of the CellBroadcastReceiver app, but can now
be used by third party apps with read permission on the ContentProvider.
Change-Id: I2c31f62b63c050c7946de2d81c28a5f4dc6f00b0
This reverts commit fe37acae729529b8bf3a3140fa397bddce42b1e0
There are two bugs that are weekend release blockers:
b/6357558
b/6357880
6357558 is easily fixed with:
https://android-git.corp.google.com/g/#/c/182228/
But there are still questions. Bug 6357880 has
unknown causes at the moment but this change is the
most likely candidate. So for today's pre-weekend
build we are reverting this change.
Users can enter arabic phone number or click arabic phone number
to send MMS. Works for generic Unicode digits (full-width, etc.).
bug:5615791
Change-Id: Ieec8c5c6c3736ee2b4ac8ddf17f8c41b2001460e
Signed-off-by: Jake Hamby <jhamby@google.com>
Modify PhoneNumberUtils to automatically convert non-ASCII digits,
such as Arabic-Indic numbers, CJK full-width digits, etc., to ASCII
in normalizeNumber(), extractNetworkPortion(), and stripSeparators().
This enables the SMS application to support sending SMS's to phone
numbers written with Arabic, or other non-ASCII digits. The number will
be converted to ASCII digits and formatted for the user according to the
country formatting rules.
Bug: 5615791
Change-Id: I42039285db5795b1dda22e4251f54af302e27f13
Signed-off-by: Jake Hamby <jhamby@google.com>
Allow some messages to be ignored and allow the subclass to
add additional information. In particular, the information
can be used to decode the msg.what to a string.
Change-Id: I4f53becc6f0cb77399f99702084efef9d8785d67
Non-system apps now require user confirmation before sending an SMS
to a short code that may potentially cost the user money. The number
is tested against regex patterns for short codes for the country
matching the user's SIM card or network. The user is warned if the
phone number is potentially or definitely a premium SMS number.
The regex patterns are loaded from core/res/res/xml/sms_short_codes.xml.
If the user's country is not found, then phone numbers of 5 digits or less
(excluding known emergency phone numbers) are considered to be potential
SMS short codes.
Command to run test cases:
$ runtest -c com.android.internal.telephony.SmsUsageMonitorShortCodeTest frameworks-telephony
Bug: 5513975
Change-Id: Ic0b483153390e974c632302f3061300bc2a2274a
Add code that updates the time zone whenever the country code
or time zone changes. In bug 6269708 the device initially
reported the mcc as 001 and then a short time later it got
the correct code, 311. This could cause the time zone to be
reported as America/Dawson instead of America/Los_Angeles.
Bug: 6269708
Change-Id: Ibfb40ea1158d3b99c121ed9960a1f0b1a45980bd
Don't trigger RuimRecords onReady so that it doesn't overwrite
mccmnc property value set by CdmaPhone in NV case.
Bug: 6153667
Change-Id: I2f25f6a69deecd085f11dbe1dbf752c2fd51cecb
Add networkId field to NetworkIdentity to identify Wi-Fi networks by
SSID. Add support for policies without usage cycles.
Only apply mobile policies when SIM state is ready, which is cleaner
than just checking for airplane mode. Also avoids creating no-op
default policies when subscriberId is null.
Bug: 3001465, 3291052
Change-Id: I1f8aaa49a5db306df022c402ea7f3f5d4bc0cfc7
To boost accurary and enhance capability of cell location api,
two new APIs, TelephonyManager.getAllCellInfo() and
TelephonyManager.listen(LISTEN_CELL_INFO), are added. Two new
Class, CellInfo and CellIdentity, are created.
This API change returns all information of one cell locaiton
at the same time. It also provides additional LTE and timestamp information.
Change-Id: I4d0f813107e625ec4ac88c8d980ffd171aa5fc30
This will dump the state of the telephony stack using:
adb shell dumpsys activity service android.phone.TelephonyDebugService
The service is located in packages/app/Phone and TelephonyDebugService
instantiates DebugService and calls its dump method when asked
via the dumpsys command above.
Change-Id: I4d34c741544cafdadce2532de8b9c117a4d435a5
- Move the class.
- Remove some TODOs mentioning this action : the class should belong to
telephony layer instead of to the Phone package
- Add private strings used in the class
Bug: 6252254
Change-Id: I0d4ca2f8e4d775004d146fe6f9c60165a94366a9
mIccCard is now be multi-thread safe but other similar
variables such as mIccRecords will be cleaned up in
the future and are no worse than before.
Change-Id: Ic2fc31af2575c2dc0bb30e7348dd9e76ec61e763
Refactor SMS Cell Broadcast support to enable receiving CMAS warning
notifications over CDMA. The CellBroadcastReceiver app must also be
updated with the corresponding change. All cell broadcasts are now
delivered as a Parcelable SmsCbMessage object in the "message" extra
of the SMS_CB_RECEIVED_ACTION or SMS_EMERGENCY_CB_RECEIVED_ACTION,
instead of as a GSM/UMTS "pdu" byte array.
Existing functionality for ETWS and CMAS alerts over GSM/UMTS continues
to be supported using the new radio-technology independent SmsCbMessage
and related objects. Test cases are added to verify that valid and
invalid broadcast data is handled appropriately.
Unit testing discovered a bug in the BitwiseOutputStream utility class
used by the added test cases. When the BitwiseOutputStream object must be
expanded (in the private possExpand() method), the mEnd field is not
updated to the new array size. This causes a new array to be allocated
on every new write, and for all data beyond the original array allocation
to be replaced with zeroes. Fixed by adding a line to possExpand() to
update mEnd. Added a test case to BitwiseStreamsTest to verify the fix.
Besides the test cases, BitwiseOutputStream is only used by BearerData in
two places, both of which allocate a sufficient initial buffer. So the
bug in BitwiseOutputStream is not critical to fix for normal operation,
but should be fixed so that the test cases using it function correctly.
Bug: 5856308
Change-Id: I201ecbf11607fd200aaae3cbb32561efabf65672
Bearer Independent Protocol (BIP) connections as defined in
ETSI TS 102 223 "Smart Cards; Card Application Toolkit (CAT) (Release 11)"
need to be able to establish data connections even when not provisioned.
This can occur when trying to provision on via and EVDO network.
Bug: 6110632
Change-Id: I85722e0ba2e2606ffcf2516b8f00be6ff5271adf
Previously, the assumption was that only a deletion or an insertion can happen
at a time; but with auto-complete, a deletion and insertion happen at the same time.
Needed for bug 5992672 in the Messaging app and is nice to have in the platform.
Change-Id: I2d80cecc486e7a1ceeaeb34866bcd834074f5ead
