- a portion of the mms contact lookup wasn't protected by the synchronization block, and that portion used a member variable 'mSelectionArgs', which contains the number to be looked up. If this code is accessed by different threads at the same time, mSelectionArgs could be overridden by a wrong number, causing the resulting contact info be bad. With the bad contact cache, future lookups by phone number would result in the wrong contact. While I didn't reproduce this with release builds, I was able to write a test that looks up a bunch of numbers in thread 1, and another bunch in thread 2. I observed thread #2 overwritting mSelectionArgs for thread 1, causing contact lookup to create bad contact cache. I believe in practice this can happen as the MMS code does look up and create contact cache entries from different threads. This problem should be in builds before ERE19. In ERE19, Dmitri added an optimization in the ContactInfoCache's contact lookup, which should result in contact lookup to fail (zero cursor) when mSelectionArgs is overwritten by a bad phone number. It'd be nice to confirm that, but bug 2384418 doesn't contain a bug report, and we don't know for sure which build it was found in. In any case, this fix is straight forward and should fix the contact lookup. Change-Id: I516ff7039bec47c1b7bdc7dd5e52347c004a5a13
- use PhoneUtils.toCallerIDMinMatch() instead of getStrippedReversed(). The latter uses the whole number, and would treat numbers "1-650-555-1212" and "650-555-1212" differently. The former uses the first 7 digits of the reversed digits, and is what ContactsProvider uses to filter for numbers.
There's a route through a Conversation constructor that will result in the conversation's contacts getting loaded on the UI thread. Add an explicit "allowQuery" parameter to give callers the ability to throttle this behavior. Fixes bug 2280762. Conflicts: src/com/android/mms/data/Conversation.java src/com/android/mms/ui/ComposeMessageActivity.java
After loading a thread with an exact set of recipients, the code called setRecipients() which resets the threadId to zero. As a result, a new conversation was created and displayed, rather than the existing conversation with all of its messages. Fixes bug 2284007. Change-Id: I6b38a046120f320a95f5e63721ee3000290feb1c
…in the xml file isn't present. Change-Id: I628ddd211e1a130b10075dbe55708fca020bcfb6
1) There's a situation where getting a contact could potentially return a cached contact whose contents haven't been completely filled in yet. 2) When a contact's info does change, update the messages in the thread to reflect the current contact data. Bug 2271800. Change-Id: I48403c45c461b3c609400a3a5f55b99aaee01cbd
The Contact.get() API allows the caller to specify whether the operation can block (looking up contact info in the DB) or not. There are about 10 places where various callers were passing "true" to canBlock, all coming from the UI thread. We've previously fixed Contact.get() to always return a Contact, with the number filled in, even if we don't have the contact in the cache. With this change, never block the UI thread getting a contact. The worst side-effect should be showing a number, instead of a name. Fixes bug 2265631.