This reverts commit cd88c0f.
The SmsReceiverService registered for SERVICE_STATE changes and this was causing the Messaging app to be needlessly started up on every SERVICE_STATE change. With this fix, we only register for that event when we fail to send a SMS message because of no radio sig, etc. Once we successfully send the queued message, we'll unregister the event filter. Change-Id: I12cbe0cb9a72bbf628bf9a4929680519e85057a2
…ed to be initialized. - this caused by a recent change to store the recipient id key as a Long instead of a String in RecipientIdCache. It's an easy fix.
- my change Ia80a2736 added code to validate and scrub MMS address. However, as a side effect it also disallowed email address for SMS messages. Fix that. Change-Id: Iac3783e056c933531da73bd53eb8ea9d7c0eb154
When the Mms app starts up, Conversation starts a background thread to load all the conversations into a cache. It had a lock on the cache. Meanwhile, the ComposeMessageActivity started up and tried to load its conversation, but was blocked and eventually ANR'd. Make the sync lock cover a much smaller scope and don't hold the lock during the slow operation of looking up the contact info. Also, remove the unused SuggestionsProvider. It was causing the Mms app to spin up needlessly. Fixes bug 2220565. Change-Id: I0f8260338a5368dc4b8ef11249361ca0716a2887
In rare cases, a Mms pdu header will not contain a "from" address. Rather than leaving the from address blank, use a slower, but more reliable method of getting the from address from the "addr" table. This is the technique the Mms notification system uses to get the address displayed in the notification bar when a new message is received. Fixed bug 2241939. Change-Id: If932d4f1c24f46f3c3906a7e2658d7f67d4a2cfa
…track. - need to call Conversation.setRecipient() when creating a new Conversation object.
…es with new SMS/MMS number. - when the user sends a message, let's check if the new message's address is different than the one stored in the recipientId's cache. If it is, let's update the cache and the underlying canonical_addresses table in the db, so we wouldn't keep using a bad number for future references. Change-Id: I3ac9940fa3c37d29c7398cac4535915249469563
- one of my previous change allowed makeSendPdu() to return null if there is not a valid recipient for the message. However, there is a separate code path that makes the recipientless message a valid scenario. So always return a valid pdu object. Change-Id: Ice49d158e23374ca31575efc523af7e063bcb2ff
The first time Messaging is launched, a background thread loads the conversations threads, which loads the contact info cache. While this is happening, the ConversationList activity starts and the first thing it does is clear the contact cache that is being built in the background. Don't clear the cache if it's currently being built. Fixes bug 2167799. Change-Id: Id8a9345caaf7905d1f4bcc18ee45d11cb860d293
Don't toss and rebuild the ContactInfoCache on every contact change. With this change, we mark a contact as stale and the next time we're asked for the contact, we asynchronously update the contact in the background. Helps speedup bug 2167799. Change-Id: Idc1271776cddd43fedcd7f31608a3302c8861813
- need to catch the NPE and deal with it, like clean up and delete the queued message. Otherwise we not only get a crash in the app, but the queued message would keep getting retried, therefore grow the conversation thread everytime it retries. - also catch a RuntimeException when we try to insert an existing conversation into the Conversation cache. That caused an app crash too! Change-Id: Iba081955e19d7a5eb517c3a3aea5186534787c15
…age. - add MMS address validity checking and scrubbing. If the phone number used to send a MMS message contains invalid characters (non digits and non-valid separators), we now warn the user when he tries to send the message. The prior validity checking code only checks against GSM SMS address, so it would miss all the invalid chars for MMS address. - assuming the MMS address is ok but contains separators that are not valid MMS address chars (as far as the network is concerned), we scrub the number when creating the SendReq data structure for MMS message. - flag a few places where things are still not correct, but too risky to fix for MR1. Change-Id: Ia80a2736f955b94a8cac51ffeb06617a95580ab8
Previously fixed this, but if the underlying search in ContactHeaderWidget fails or takes a long time, the contact header will still show the wrong info. Force an invalidate after clearing the ContactHeaderWidget so it'll redraw empty, rather than leave the previous contact information. Bug 2233151.
…ntent, replace the matching contact cache with the intent address. - this is basically another path in which we have the actual dest address (in the intent). When the compose screen finds the matching cached contact, it should replace the contact's address with the specified address in the intent, in case the cached contact has a bad address. Change-Id: Id55500e212df5dcd47ff7a1858bc99d4b4656df1
…d lead to permanent failure for the messaging thread even after a good number is used. - when the user selects/types a new number in the recipients editor, and we find a cached contact, set the contact's number to be the newly selected number. This will allow the user to correct the address, at least until the next time MMS rebuilds the contact cache with the bad number stored in the database. This will get us to par with the Cupcake behavior. Unfortunately, after MMS app is relaunched, the thread would use the bad initial adddress again (loaded from the 'canonical_address' table in the db). That's a much harder, riskier fix, so deferring to later. Change-Id: If32958482b14848bd770cff50e4736457c47ac8a
If for some reason the SmsProvider returns a null cursor when we try and load the SIM messages, show the "no sim messages" UI rather than leaving the UI in a constant loading (animated loading cursor) state. This is part three of three fixes for BC-triaged bug 2205782. Change-Id: Ie3dceea621f8c2aa0a2c98f79278c120df3c37e7