Information Session thread_id exception handling (MMS Draft modified recipient, SMS new information lost thread data)

1, SMS receives the message, the thread table does not have the create new data. Causes the number of unread messages to be displayed, but not visible in the session list.
(Even now.) Workaround: Filter The SMS information lost by thread when querying unread information. Avoid this bug first)

　Analysis: The RIL layer receives new information through the framework to send notifications--android.provider.telephony.sms_deliver

Com.android.mms.transaction.PrivilegedSmsReceiver receive broadcast, application MMS starts processing

protected voidOnreceivewithprivilege (context context, Intent Intent,Booleanprivileged) {String Action=intent.getaction (); //If ' Privileged ' is false, it means that the intent were delivered to the base//no-permissions receiver class. If we get an sms_received message, it//means someone have tried to spoof the message by delivering it outside the normal//permission-checked route, so we just ignore it.        if(!privileged && Intents.SMS_DELIVER_ACTION.equals (ACTION) | | "Android.cellbroadcastreceiver.CB_AREA_INFO_RECEIVED". Equals (action)) {            return; } intent.setclass (Context, smsreceiverservice.class); Intent.putextra ("Result", Getresultcode ());    Beginstartingservice (context, intent); }

 Public Static voidBeginstartingservice (Context context, Intent Intent) {synchronized(mstartingservicesync) {if(Mstartingservice = =NULL) {PowerManager pm=(PowerManager) Context.getsystemservice (Context.power_service); Mstartingservice=Pm.newwakelock (Powermanager.partial_wake_lock,"Startingalertservice"); Mstartingservice.setreferencecounted (false); } mstartingservice.acquire ();        //Use Powermanager.wakelock to ensure that the service can still run Context.startservice (intent) in the off-screen state ; }    }

Smsreceiverservice get the SMS data from the intent and insert the  database Private Uri Insertmessage (context context, smsmessage[] msgs, int error, String format) {...}

When calling Storemessage (context context, smsmessage[] msgs, int error), the ThreadID is judged and the newly received information is unlikely to be threadid, so create the thread

if NULL NULL ) ) {            = conversation.  Getorcreatethreadid(context, address);            Values.put (sms.thread_id, threadId);}

Contentresolver resolver = Context.getcontentresolver ();

Uri Inserteduri = Sqlitewrapper.insert (context, resolver, Inbox.content_uri, values); //Database update

Now make sure we don't over the limit in stored messages
Recycler.getsmsrecycler (). Deleteoldmessagesbythreadid (context, threadId);
Mmswidgetprovider.notifydatasetchanged (context);

return Inserteduri;

The problem of bug feedback should not be seen from the code. This bug occurs when the thread table is updated with the Create thread fail, or when the subsequent update is new-created-thread-data deleted.

Customer urged, version production is imminent, had to avoid this problem. Filters for thread_id that exist in SMS while querying for data, but do not exist in thread.

 Caseuri_unread_and_lost_threads: { //Customize a query type for unread SMS to thread_id filter String unreadsmsquery = "Select _id, thread_id, address" + "from SMS" + "WHERE sms.read = 0 and thread_id not in (select _id from Threads) "; Cursor=mopenhelper.getreadabledatabase (). Rawquery (Unreadsmsquery, Empty_string_array); if(cursor!=NULL&& Cursor.getcount () >0){                    //should repair the lost data in thread table, but I had no good idea now, so just leave itLOG.E ("Antoon", "Mmssmsprovider, with Lost thread SMS:" +Cursor.getcount ()); }        returncursor;}

--------------------------------------------------------Gorgeous split-line------------------------------------------------

2, the MMS Draft modifies the recipient to produce a new thread.
(Must be present.) Workaround: Pass the original thread_id and new recipients to the provider, update the recipients to avoid generating a new thread)

MMS Draft Save

Private voidAsyncupdatedraftmmsmessage (FinalConversation Conv,Final Booleanisstopping) {        if(Log.isloggable (Logtag.app, Log.verbose)) {Logtag.debug ("Asyncupdatedraftmmsmessage conv=%s mmessageuri=%s", conv, Mmessageuri); }        FinalHashmap<uri, inputstream> preopenedfiles =mslideshow.openpartfiles (Mcontentresolver); NewThread (NewRunnable () {@Override Public voidrun () {Try{draftcache.getinstance (). Setsavingdraft (true); FinalPdupersister Persister =Pdupersister.getpdupersister (mactivity); FinalSendreq Sendreq =makesendreq (conv, msubject); Persister.setmmsdraftthreadid (moldmmsdraftthreadid); //Add by Antoon, send old thread_id to PDU                                         if(Mmessageuri = =NULL) {Mmessageuri= Createdraftmmsmessage (Persister, Sendreq, Mslideshow,NULL, mactivity, preopenedfiles); //For MMS Save, THREAD_ID will be created when PDU is saved } Else{updatedraftmmsmessage (Mmessageuri, Persister, Mslideshow, Sendreq, Preopenedfiles);                    //After modifying the previously saved MMS, the PDU updates the data, which is based on the recipient Getorcreatethreadid, so modifying the recipient will result in the creation of a new thread } ensurethreadidifneeded (conv, isstopping); //Confirm that thread_id was created or obtained successfully, or else execute Getorcreatethreadid conv.setdraftstate again (true); if(Log.isloggable (Logtag.app, Log.verbose)) {Logtag.debug ("Asyncupdatedraftmmsmessage CONV:" + conv + "uri:" +Mmessageuri); }                    //Be paranoid and delete any SMS drafts that might be lying around. Must do//This after ensurethreadid so conv have the correct thread ID.asyncdeletedraftsmsmessage (CONV); } finally{draftcache.getinstance (). Setsavingdraft (false);                Closepreopenedfiles (Preopenedfiles); }            }        }, "Workingmessage.asyncupdatedraftmmsmessage"). Start (); }

See ensurethreadidifneeded (CONV, isstopping)

Private voidEnsurethreadidifneeded (FinalConversation Conv,Final Booleanisstopping) {        if(Isstopping && conv.getmessagecount () = = 0) {            //We need to save the drafts with an unorphaned thread ID. When the user goes//Back to Conversationlist while we ' re saving a draft from CMA ' S.onstop,//Conversationlist would delete all threads from the thread table//don ' t has associated SMS or PDU entries. In case our thread got deleted,//Well call Clearthreadid () so Ensurethreadid would query the DB for the new//thread.Conv.clearthreadid ();//Force us to get the updated thread ID        }        if(!conv.getrecipients (). IsEmpty ())        {Conv.ensurethreadid (); }    }

 Public synchronized voidClearthreadid () {//remove ourself from the cache        if(Log.isloggable (Logtag.app, Log.verbose)) {Logtag.debug ("Clearthreadid old ThreadId is:" + Mthreadid + "now zero");        } cache.remove (Mthreadid); Mthreadid= 0;} Public synchronized LongEnsurethreadid () {if(DEBUG | |deletedebug) {Logtag.debug ("Ensurethreadid Before:" +Mthreadid); }        if(Mthreadid <= 0) {            if(Misgroupchat && Mgroupchat! =NULL) {HashSet<String> numbers =NewHashset<string>();                Numbers.add (String.valueof (Mgroupchat.getthreadid ())); ContactList Grouprecip= Contactlist.getbynumbers (Numbers,false); Mthreadid=Getorcreatethreadid (Mcontext, Grouprecip, misgroupchat); } Else{Mthreadid=Getorcreatethreadid (Mcontext, mrecipients, misgroupchat); }        }        if(DEBUG | |deletedebug) {Logtag.debug ("Ensurethreadid after:" +Mthreadid); }        returnMthreadid;}

For MMS, SMS drafts are called ensurethreadidifneeded when they are saved, and if the recipient is modified, there should be thread_id rebuild to get the operation.

But for SMS, there is no feedback on this issue, what is going on?

Information Session thread_id exception handling (MMS Draft modified recipient, SMS new information lost thread data)