ee60f3fb1b4e61ac8027293a658ba710e36d36b6 |
|
11-May-2011 |
Jake Hamby <jhamby@google.com> |
resolved conflicts for merge of 18cc814c to honeycomb-plus-aosp Change-Id: I2b569ada3baec2dc486296623063bc2b504c5e96
|
b49a73dfc4c9817bba1f227e9330555acdf9b56f |
|
16-Mar-2011 |
Jake Hamby <jhamby@google.com> |
Enable support for SMS national language shift tables. Add support for encoding and decoding SMS 7 bit user data using the national language shift tables defined in 3GPP TS 23.038 (GSM/UMTS only), including the new tables added in Release 9 for Indic languages. Decoding is always supported, but encoding is only enabled for the specific language tables added to the new integer array resources "config_sms_enabled_single_shift_tables" and "config_sms_enabled_locking_shift_tables" defined in frameworks/base/core/res/res/values/config.xml. The default empty arrays should be overridden in an OEM overlay for the specific nationalities where SMS national language shift table encoding is allowed/mandated (e.g. Turkey). GsmAlphabet.countGsmSeptets() will try to find the most efficient encoding among all combinations of enabled locking shift and single shift tables. If no 7 bit encoding is possible, 16 bit UCS-2 encoding will be used. This change also fixes a bug in the decoder: when an escape septet is followed by a septet with no entry in the extension (single shift) table, TS 23.038 Table 6.2.1.1 states that the MS shall display the character in the main GSM 7 bit default alphabet table, or the active national language locking shift table. Previously, we were decoding this sequence as a space character. Two consecutive escape septets will continue to decode as a space character, according to Note 1 of table 6.2.1.1. Change-Id: I4dab3f0ffe39f3df2064ed93c9c05f26e274d18b
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
1b7f0d4e38799478746ac00650627cfff110d1c9 |
|
23-Apr-2010 |
Wei Huang <weih@google.com> |
am d54c48b2: am 9666bbdf: am 7b88af67: Merge "bug #2618035: applying Moto\'s patch to fix a email/shortcode parsing bug." into froyo
|
fdf3b26ba78ed308f45a2c6f79a5f977663ac3c8 |
|
23-Apr-2010 |
Wei Huang <weih@google.com> |
bug #2618035: applying Moto's patch to fix a email/shortcode parsing bug. Change-Id: Ica1df6582533edf8d9a5825dbe510eeab4828309
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
145ff609de3206b585819ef974fab20cdc2d9f5e |
|
16-Apr-2010 |
Jake Hamby <jhamby@google.com> |
Spelling corrections and other minor cosmetic cleanups. - Fixed a bunch of typos in comments (plus a few variable names) - Removed unused import lines from telephony classes - Added @Override attribute to overriding methods - Made SmsMessage.PduParser inner class private & deleted unused constructor - Added type specifiers to declarations of ArrayList and HashMap - SimulatedCommands.getRegistrationState() had an ArrayIndexOutOfBoundsException trying to write to index 14 of a 14-element array. I removed the out-of-bounds assignment. Change-Id: I054b5156aa64ab6639028d5b45a7e688b2deee08
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
001d0abd3e523dce5c8a4c14e22bd1ea79976f03 |
|
19-Sep-2009 |
jsh <jsh@google.com> |
Fix potential ArrayIndexOutOfBoundsException. When parsing an SMS message as email, extractEmailAddressFromMessageBody() checks parts.length >= 1, but then proceeds to access parts[1] (which may not exist). Instead, check for parts.length >= 2, and treat parts.length = 1 as non-email. b/2122698
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
af6bb1ce9aa0f1f73666b25af404640930be8c10 |
|
31-Aug-2009 |
Satish Roddom <satishroddom@motorola.com> |
SMS-to-email fix for messages from the web Certain carrier websites allow sending SMS to phones on their network. They allow filling out a "Reply to Address" which can be a phone number. The website may send that message to the device as an SMS-to-email, but the "From" address will be an SMS short code and not a valid email address. When the user replies to this message, the response is directed to the short code and not delivered correctly. In extractEmailAddressFromMessageBody(), currently it checks if the sender is a shortcode and an email address is present as the first word in the message body. If so, it replaces the email address as the sender replacing the short code. The fix to support the above case is remove the email address check and treat the first word as FROM address regardless of what the user types. Change-Id: Ifd39a39b352f204024c76fde293164dcd2b0896b
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
95434bfaee62161ce02012c6424f0c0c8fffccb5 |
|
28-Aug-2009 |
Tammo Spalink <tammo@google.com> |
Allow fragmentText to be called for singleton CDMA messages. Corrects for previous partner changes, addressing issue: http://buganizer/issue?id=2063332 Change-Id: I49e564d81c5db3e92a6bad973f21a02a7302875d
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
bd55b0cb156280f44e82c50e02f9a07d6b528dcd |
|
29-Jul-2009 |
Satish Roddom <satishroddom@motorola.com> |
Second word lost when SMS is received from email When SMS is sent from a email address, Email Gateway server sends a string containing from address, message text. Current code is treating the first word as from_address, second word as subject and rest of the string as message_body. Because of this second word is getting stored in separate variable and not as part of message text, so second word is always lost.
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
ab752276ee9838fe05b3fedb18075120c72cfb54 |
|
31-Jul-2009 |
Jaikumar Ganesh <jaikumar@google.com> |
am 0da3bdb4: Fix public API caused due to CDMA changes. Merge commit '0da3bdb476086db02a1076780676b21e239c79d6' * commit '0da3bdb476086db02a1076780676b21e239c79d6': Fix public API caused due to CDMA changes.
|
0da3bdb476086db02a1076780676b21e239c79d6 |
|
28-Jul-2009 |
Jaikumar Ganesh <jaikumar@google.com> |
Fix public API caused due to CDMA changes.
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
daccacb865947c00f277f1823333e2fbf91e652a |
|
10-Jul-2009 |
Wink Saville <wink@google.com> |
Change 107 and 146 from partner repo. These were combined to save testing time. cpr107: Enhance the MDN change during OTA 1. Remove the OTA MDN change code in RuimRecords.java and move to CdmaServiceStateTracker.java 2. Reduce the frequent function GET-CDMASubscription. Move the Get_CDMASubscription from pollstate() to EVENT_NV_READY handler. The CDMA Subscriber MDN/MIN is only changed by OTA programming. Only need fecth the subscriber information when power on and OTA completed. 3. Add new variable for PRL version in cdma subscription cpr146: SMS-to-Email fix for extracting e-mail address
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
fc78f358cb1d1cee99758bcd6ef998a122ef27c9 |
|
11-Jun-2009 |
Tammo Spalink <tammo@google.com> |
for cdma concatenated (long) messages, replace ascii7bit with gsm7bit encoding
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
faf4413dffdc9079683b951736088ff2a01073a4 |
|
30-May-2009 |
jsh <jsh@google.com> |
Manually merge a few fixes from cupcake and cupcake_dcm. CL 144717: Correctly set user data payload length for non-7-bit encoded payload. CL 149058: Check for null TP-OA in SmsMessage.parseMessageBody(). CL 138094: Make sure call state (and other updates) have a chance to get processed between data setup attempts. CL 132624: Added a comment for a way to save a message to the SIM.
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
64c499113a758cf80cddfd4d0183f944a1a6645a |
|
05-May-2009 |
Tammo Spalink <tammo@google.com> |
SmsHeader rewrite, in preparation for migration to public API. See http://b/issue?id=1751571 Changes the semantics of SmsHeader from containing only opaque data to exposing occurs-once frequently-used fields together with a list of opaque fields. Also changes the coding to and from byte array to be symmetrical, whereas previous encoding had an extra length field. Cdma SmsMessage -- cleanup of code paths along with adjustments to match the new header semantics, which should address at least some of the issues with concatenated messages. See http://b/issue?id=1809759
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
83917db040bd7498ebca3b74f879dc1c9e223d8e |
|
14-Apr-2009 |
Tammo Spalink <tammo@google.com> |
Initial code for cdma sms encode and decode, in java, with simple tests. (direct cherry-pick of master 42/42/8)
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|
767a662ecde33c3979bf02b793d392aca0403162 |
|
02-Apr-2009 |
Wink Saville <> |
AI 144185: Integrate cdma into the main code base. Automated import of CL 144185
/frameworks/base/telephony/java/com/android/internal/telephony/SmsMessageBase.java
|