| 0aa683b47dfd8590f71d88e0814dade4503f0b5d |
|
14-May-2016 |
Ta-wei Yen <twyen@google.com> |
Add VisualVoicemailSmsFilter
Several implementation exists for OMTP-like visual voicemail SMS
interfaces because what type of SMS to use is not specified.
Before this CL we can only handle data SMS using the DATA_SMS_RECEIVED
broadcast. With this CL, we can handle data, text and type-0 SMS.
SMS filters will potentially do actions base on the SMS or drop it, so
proper priority should be established to make them work nicely together.
The android framework already provides the CarrierMessagingService
interface to filter SMS. There are 2 possible packages that implements
the interface, the carrier package and the system package. One of them
if any will be chosen to do the filtering. The carrier package is
installed with user interaction and have complex restraints. The
system package is preloaded by the OEM.
If there's a carrier package, we will filter after the carrier package
as it should have priority. If there's a system app, we will filter
before it as we offered mechanism to enable/disable us.
For type-0 SMS, we will filter it before it is going to be dropped.
We will filter visual voicemail SMS based on the content of the message.
A visual voicemail SMS should start with a certain prefix defined
through TelephonyManager, have a event field, and the rest of the message
is consist of OMTP key-value pairs. Future CL will add further
restrictions like originating number and destination port number to
reduce false positives.
If the parsing succeeded, we will compile it into a intent and send a
broadcast. The broadcast is to be made explicit in a future CL.
Bug:27816386
Bug:27817303
Change-Id: I120418d344a1537ff006583759659fa025cac712
/frameworks/opt/telephony/src/java/com/android/internal/telephony/gsm/GsmInboundSmsHandler.java
|
| ecac744a4e585e3c7af95ffa06fa3e711131200c |
|
02-Mar-2016 |
Amit Mahajan <amitmahajan@google.com> |
First unit test for ImsPhone.
Bug: 25691379
Change-Id: I61a2f0805220782e7dbebaf50604b596ef3ba24b
/frameworks/opt/telephony/src/java/com/android/internal/telephony/gsm/GsmInboundSmsHandler.java
|
| 97b3c4e45f156d8d5ae25a32357c9b31e018da32 |
|
10-Feb-2016 |
Amit Mahajan <amitmahajan@google.com> |
Support for storing voicemail count for multi-sim.
Bug: 18108420
Change-Id: I08edb714b839b44472b3b7a4d0aba287da2969d3
/frameworks/opt/telephony/src/java/com/android/internal/telephony/gsm/GsmInboundSmsHandler.java
|
| 1a87ab3d7170d618f048c4f5af8c7504a587aaa5 |
|
10-Dec-2015 |
Jack Yu <jackyu@google.com> |
Merge from master
Change-Id: Ifbd86600111d2c444031ff608fab62fb2ee4b236
/frameworks/opt/telephony/src/java/com/android/internal/telephony/gsm/GsmInboundSmsHandler.java
|
| 26a4150cfb8cd317eb64994b9d9fd6109bd87ba7 |
|
03-Jan-2014 |
Sukanya Rajkhowa <srajkh@codeaurora.org> |
Telephony: Voice mail notification related changes
* Separate voice mail notify from SIM/RUIM card
* For GSM store voice mail count in phone memory
irrespective of SIM write result.
* Display voice mail count for GSM
Bug: 17299884
Change-Id: I368bfb98c8798ed1f43bcc330e6d97e8f95f0f54
/frameworks/opt/telephony/src/java/com/android/internal/telephony/gsm/GsmInboundSmsHandler.java
|
| 6aa799c9d555854ecac94b15967e9016c55b4340 |
|
26-Sep-2014 |
Amit Mahajan <amitmahajan@google.com> |
Change to show correct number of unheard voicemail in notification.
Bug: 17299884
Change-Id: Ie26a61cbfc2254f95686b8031a0988b9cd58609d
/frameworks/opt/telephony/src/java/com/android/internal/telephony/gsm/GsmInboundSmsHandler.java
|
| d2feaf918ab0c1173d4ada182532e48d0c0d3f77 |
|
31-Oct-2013 |
Wink Saville <wink@google.com> |
When phone changes update InBoundSmsHandlers and CellBroadcastHandlers.
Without this change for devices where the phone can change, for instance
on N5 with Sprint the phone will change from a GSMPhone to a CDMALTEPhone
and messages will not be sent to the appropriate handler.
For Sprint this was most readily seen when the voice mail notification
wasn't sent to the notification manager.
Bug: 11254397
Change-Id: Ia0e764cf6fa04208a7e194a35435f251a177309f
/frameworks/opt/telephony/src/java/com/android/internal/telephony/gsm/GsmInboundSmsHandler.java
|
| 0d4bcdf379842af4b6304809156971e926f374f0 |
|
18-Mar-2013 |
Jake Hamby <jhamby@google.com> |
Refactor inbound (MT) SMS handling into new handler classes.
Moved all MT SMS handling to separate StateMachine classes, which
save all incoming PDUs in the SmsProvider "raw" table, previously
used only for storing PDUs of concatenated messages. Then we ACK the
message, before starting the ordered broadcast as usual. If a receiver
of the broadcast sets the status to failure, we ignore it, but in the
future we could provide a mechanism to redeliver the broadcast.
New classes are (without com.android.internal.telephony prefix):
- CellBroadcastHandler
- InboundSmsHandler
- InboundSmsTracker
- SmsBroadcastUndelivered
- WakeLockStateMachine
- cdma.CdmaInboundSmsHandler
- cdma.CdmaServiceCategoryProgramHandler
- gsm.GsmCellBroadcastHandler
- gsm.GsmInboundSmsHandler
This fixes a bug in the SMS dispatcher. Previously we delivered
incoming SM's as ordered broadcasts and then sent an acknowledgment
to the SMSC after the broadcast completed. It was possible for the
ordered broadcast to take over 20 seconds to complete, causing SMS
retransmissions because we didn't ACK quickly enough. Also, a
broadcast receiver could set the result code to failure (the AOSP
MMS app never does this), causing us to negatively acknowledge the
SMS, potentially leading to many retries and a backlog on the SMSC.
The reason for saving all PDUs in the raw table before ACKing is so
InboundSmsHandler can handle the failure case of a device crash or
power failure in between ACKing the message and the delivery of the
ordered broadcast to receivers. This is handled when the Phone class
starts, creating a new thread to run SmsBroadcastUndelivered.
This Runnable scans the raw table once, finding all complete
PDUs and sending IncomingSmsTrackers to the state machine to
broadcast them again to receivers. In the worst case, a message might
be added twice to the MMS inbox, but it won't be lost.
However, due to the current MMS app implementation, which immediately
acknowledges the ordered broadcast before starting a new Service to
process the message, there is a very short window of time when a
message could potentially be lost, if the MMS app or device crashed
after the ordered broadcast returns and the message is deleted from
the raw table, but before the MMS service has added the message to
its own tables. To fix this will probably require API changes.
Another improvement from this change: SmsBroadcastUndelivered also
deletes PDUs for incomplete multipart messages that are older than
30 days. We've never garbage collected this table in the past, so
it's possible for a phone to accumulate a number of old PDUs in the
raw table if not all components arrived successfully.
The wake lock handling is also improved in this version, as we now
acquire a wakelock when the state machine leaves the Idle state,
releasing it 3 seconds after returning to the idle state, instead
of the previous 5-second timeout. If a new SMS arrives while a
broadcast is being delivered, we add it to the raw table and ACK the
new PDU immediately, then send the InboundSmsTracker as a message to
handle when the previous broadcast completes.
In order to keep track of whether a PDU is in 3GPP or 3GPP2 format,
the destination port column of the raw table is extended with three
flags: 3GPP format, 3GPP2 format, and no destination port present.
Because the destination port is a 16-bit value in both 3GPP and
3GPP2, the upper bits of the destination port can be used for flags.
This saves us from having to modify the SMS provider to update the
DB version and to add extra columns to keep track of these flags.
Bug: 7099232
Change-Id: Ibbc01ccb83320f4b6112fe3dd31355eb6f570b67
/frameworks/opt/telephony/src/java/com/android/internal/telephony/gsm/GsmInboundSmsHandler.java
|