Android Text Messages Intermittently Going Astray 325
theodp writes "Reports from Engadget and others suggest that Tiger Woods and Brett Favre might want to avoid Android for the time being. It seems Android's default text messaging app still has horrible text messaging bugs that can that intermittently send texts to the wrong person. 'This is ticking me off like no other technology glitch that I experienced in recent years,' reads one unhappy camper's post on a lengthy Help Forum thread opened on March 16th. 'If a bank deposited my paycheck into another person's account I wouldn't stress so much cause I can always get the money back. How the hell do you take words back? "Oh sorry boss you had to find out that I think you're an idiot, can I still keep my job, please please please?"' Over at Google Code, Issue 9392 — SMS are intermittently sent to wrong and seemingly random contact — carries a priority of 'Medium,' even though it has 600+ comments and has been starred by 3,600+ people."
Definitely bug. One or several remains to be seen. (Score:5, Informative)
No, it is not a fat finger issue. It IS sending messages to the wrong recipient without notification, and even sorting them in a different thread than where it was sent; there are steps to reproduce in the bug report. Your assumptions about the issues are misleading others just as badly as FUD could.
uh.... maybe not (Score:5, Informative)
If a portion of your user population has enough trouble with your UI that they are 'fat fingering' their way into trouble, then at some point it is _your_ issue.
But that having been said, a quick glance through the support thread shows things like this: "http://www.google.com/support/forum/p/android/thread?tid=345259e6d424bad3&fid=345259e6d424bad300048dfbff785d0c&hltp=2"
The code reverses the numbers before doing its (loose) compare... so uses the 7 last digits.
Bob - 408-555-1234
Fred - 510-555-1234
become
4321-555-804
4321-555-015
And it only uses the first 7 digits, which for both numbers, is "4321555"...
So if you send a message to Fred, and it looks in the cache for the contact, there's a chance it will go to Bob.
Android randomly deletes all of your SMS too (Score:2, Informative)
If it doesn't send them to someone random it will just delete all of them. http://code.google.com/p/android/issues/detail?id=5669 That's also labled as medium.
Re:It's open source (Score:5, Informative)
Software should be free.
Texts should be free.
Free, free, free (or almost free).
"When phones are on, they are ALWAYS connected to the cell phone tower. The phones and cell phone towers exchange little packets worth of information back and forth so when ever a call comes it, they can find you straight away. Can anyone guess how big the packets are? If you guess 160 characters, you are right." In other words they are charging for a service that should be free, because the phone and tower are *already sending* Texts to one another. It costs nothing for the company to append that Text to the outgoing packet.
"When you think of it on a kilobyte level it costs us $1.09 per text message Kilobyte. The markup for costs is 7300%." So using an typical 2000 messages/month, that's just 320,000 characters or 0.00032 gigabytes. It shouldn't cost 25 dollars (what VirginMobile charges me). Continued here: http://www.spoiledtechie.com/post/The-Actual-Cost-of-Texting2c-Short-Codes-and-a-731425-Mark-up.aspx [spoiledtechie.com] and here: http://www.google.com/search?q=cost+of+texting [google.com]
To summarize: Phones are "texting" towers constantly as part of the cellular standard.
The appending of a personal message costs nothing extra for the company.
The rates are outrageously high for the minuscule data passed.
It's been fixed (Score:5, Informative)
Though I guess it'll take a while to get into builds/updates for existing handsets.
Re:It's open source (Score:4, Informative)
I'm wondering if Handcent or other 3rd party apps are affected by this bug also or if its just in the Google app code only.
None of the other FREE (or paid) SMS apps have had this reported.
Further, its very rare, and complicated to reproduce this, unless you frequently have a lot of message threads between many people going on, and respond asynchronously.
"Darth Mo" posted how a specific a sequence of messages [androidcentral.com] can cause this problem, and it seems to involve the Back Button on Android, after reading a message from one contact but then deciding to respond to a different prior message thread.
Re:uh.... maybe not (Score:5, Informative)
The actual code is here [kernel.org].
Reading the various compare() implementations definitely leaves room for doubt about correctness. The compareStrictly() code is a lovely illustration of the ambiguity that exists in the world of phone numbers. The comparison implementation mentioned above is found in compareLoosely() and is characterized in comments as "similar() not equals()", meaning collisions are possible. Which of compairStrictly/Loosely is actually use is subject to configuration; the caller can't know which is used without examining configuration resources.
Haven't yet seen evidence that this is the cause of the problem folks are having; does the SMS code rely on this? The comments claim the compareLoosely() method is "identical enough for caller ID purposes." One could imagine that when the user hits 'reply' on a message the code might hunt through the phone book using compareLoosely and stop on the first "match", which may be incorrect due to a collision. There seems to be some correlation between reports of this phenomenon and the 'threaded' 'conversation' stuff in Android, which could mean people are relying on 'reply' and getting wrong results.
Who knows. Bugs will happen and phones aren't trivial. The real problem in my mind is that this one has been on the books for a looong time now (six months, approximately) and it's not getting the attention it clearly deserves.