[Investigation/Bug] Check Mms.apk (Lost SMS)

[ezterry]

Without any lock messaging app in ram there is no loss of messages in AOSP 2.2; However the gingerbread build has been causing people issues with lost SMS messages.

This will need to be verified in addition to validate what has changed since the older version; as its been indicated that those that downgraded the MMS apk from cm6.1 are not having the lost SMS issue.

A quick glance at the code indicates many things may have been made asynchronous.. thus may not be completing in time for the OOI.

[hrk]

It has happened here to me three times as I was watching the phone.

From a user/logcat point of view, it is clear that the SMS is received, all registered BroadcastReceiver-s receive the intent and are fired. MMS application dies before writing the message in the internal database and before showing the notification.

Once this happens the first time, all subsequent messages seem to get lost until the phone is rebooted. I can't confirm this 100%, but as of now I have sent two more messages after the first "missing" one and they re all missing. Yesterday Ihad the same issue, and after a reboot the (new) sms would be received fine. Phone is at 11h of uptime, more or less.

Can I add a logcat here somehow?

[ezterry]

logcats or other extended text can goto pastebin or a gist (see link left of search github)

[hrk]

Thank you, here they are.

https://gist.github.com/848753

There is a lot of "noise", especially w/ the tag "Paolo", which is an app which monitors SMS (and luckily prints the bod text, so I could read the message in the log!).

Other apps which handle the SMS and can be seen starting are com.skebby and com.prey.

MMS app doesn't show any message, except that the process is killed.

[ezterry]

re-evaluation with 2.3.3 appreciated.. however from xda chatter this still seems to be an issue.

[hrk]

Looks like it hasn't happened (yet), but I haven't been receiving many SMSs in the past days.

[ezterry]

With the update to 2.3.4 and the addition of 8MB compcache please re-evaluate this issue

[hrk]

The last "Lost SMS" happened with ADS_20110429, with minfree settings reverted to the old values using "echo 1,2,3,4,5,6 > /sys/..." (which give me always 30MB free). It was already using zram.

I will update to the latest ADS + ezGBKernel 1.1, keeping everything "stock" and report back in a while.

[hrk]

I just received (w/ Gingerbread Ghostly SMS) 2 messages which were not recorded in the Mms app.

The bug triggered while Browser was open and loading a simple webpage (I guess it clogged both CPU and RAM, so Mms.apk was killed before it could finish its work).

[ezterry]

I think my goal here will be a temporary lock mms in ram. this means for say 30 or 60 seconds after the intent behave like the mms apk is a perceptible app.rather than just a background app or service.

The idea is mms need no run when there is no message.. but needs to run long enough to spawn a notification + save to flash when an actual message arrives

[hrk]

... I didn't know it was possible to do something like that!

I guess it could really fix the bug, giving the app the time it requires to live (I guess even 15 seconds could be enough, but better to be safe than sorry, 30-60 seconds sounds fair to me).

Good work!

[ghost]

did you look how cm sms lock works ? maybe it could be "tweaked" ^^

[ezterry]

CM?

frameworks/base/services/java/com/android/server/am/ActivityManagerService.java is where all minfree adjust settings are updated (front application, visible, service, home, ect:

        if ("com.android.mms".equals(app.processName) &&
            Settings.System.getInt(mContext.getContentResolver(),
            Settings.System.LOCK_MMS_IN_MEMORY, 0) == 1 ) {
            // MMS can die in situations of heavy memory pressure.
            // Always push it to the top.
            adj = FOREGROUND_APP_ADJ;
            schedGroup = Process.THREAD_GROUP_DEFAULT;
            app.adjType = "mms";
        }

In short always force it as if it was in front of the user.. this is exactly what we want AFTER a message is received.. but once the message is processed it ought to back off into a normal background task .. because I don't know about you but I don't have the spare ram for the 99.99% of the time I don't have a SMS message.. but on the same token missing them is unacceptable.. (and currently the duplicate is a bit annoying)

Thus needs some additional logic.

[hrk]

Don't be so mean! I even added an option to disable the duplicate notification ;-)

[ghost]

im pretty sure thats what i said Terry ;) for DS it needs a touch, other devices dont really mind the sms in there.

[ezterry]

Well tweaking that (or even re-creating it as many similar blocks are in that code) is the easier part of the problem.. and I realized that part when I thought of the idea of a time delay.

framework/base/telephony/java/com/android/internal/telephony/SMSDispatcher.java:
            try {
                int result = dispatchMessage(sms.mWrappedSmsMessage);
                if (result != Activity.RESULT_OK) {
                    // RESULT_OK means that message was broadcast for app(s) to handle.
                    // Any other result, we should ack here.
                    boolean handled = (result == Intents.RESULT_SMS_HANDLED);
                    notifyAndAcknowledgeLastIncomingSms(handled, result, null);
                }
            } catch (RuntimeException ex) {
                Log.e(TAG, "Exception dispatching message", ex);
                notifyAndAcknowledgeLastIncomingSms(false, Intents.RESULT_SMS_GENERIC_ERROR, null);
            }

If I'm reading it right somewhere behind dispatchMessage() is where the Intent goes out [in our case a GSM version of this function .. but its more hardware dependent .. so best catch it here

This means just before this we want to lock down and MMS app requests in ActivityManagerService.java Then keep it locked down until either a trigger from the MMS app releases us if you want to avoid time based events .. or 30 seconds or so after dispatchMessage() returns

This needs to be done via some not yet defined state between the two components. (SettingsProvider? file? system propery?)

This is the outline.. half of it I looked up today.. but too sleepy to cleanly code it this evening..

[Obihoernchen]

Keep up the good work this fix will help all Galaxy (I7500) users as well :)

[ezterry]

Ok.. here is what I was thinking in code :) [Will be pushed this evening with a new ezGb build]:

Primary framework version:

https://github.com/ezterry/GB-framework_base/commit/2282c47f89f6ac1d397aa20d88aafd0b67ea5f1c Additional init system property permissions: https://github.com/ezterry/GB-system_core/commit/4edd231bfdec0c473959889fc4eede6225c78c4f

Once I have this in a public build test it and we can hopefully close this issue

[ghost]

nice work, looks like how it should be done :)

[Obihoernchen]

We use this in GAOSP http://code.google.com/p/gaosp/ (Samsung Galaxy/I7500) now. I'll report whether it solves the issue :)

[Obihoernchen]

It seems to work very well!

[ezterry]

receiving a SMS while loading github on the Dream seems to still not quite work. It's not low memory killer.. so lock in ram methods will not strictly help. (and the patch is working/helping)

I think I need to look how MMS is passing the information from the intent to the service it starts; (since its the service that saves the message currently)

and change it to talk via the database or flat file.

That way if the service fails next time MMS is launched it can find any missing messages and save/notify properly. (extra credit to me if I make it in a way SystemServer knows and can periodically attempt a re-try)

Problem is I only partly know where to begin.

[ghost]

Sounds complicated ><

[hrk]

I don't know if it may be useful to you, but this is exactly what I do inside Gingerbread Ghostly SMS: there's a BroadcastReceiver which is fired when a message is received, and just stores the message(s) as a blob in an internal DB. Then there's a user Activity which lists the blobs and uses the "standard" SMS ContentProvider w/ the url "sms://inbox".

But........ if you're going to change the behaviour of the Mms.apk, wouldn't it be easier to just undo the "damage" done by Google in the move from Froyo to Gingerbread? Or....... did the bug exist with Froyo too?