[SOLVED] "Backup Call log" crashes Android Q on Pixel 4a

[uj]

Before you report your issue, please consider perusing the https://github.com/jberkel/sms-backup-plus#faq and searching the issues page to see if it has already been reported.

Expected behaviour

Program will not crash when "Backup Call Log" is enabled and the BACKUP button is pressed

Actual behaviour

As soon as you press "BACKUP", the program closes (exits) without any error message. No error popup. If you unclick "Backup Call Log", the SMS messages are backed up properly and the program does not crash.

Steps to reproduce the behaviour

Enable "Backup Call Log"
Press BACKUP

Please specify the following:

• Android 11 Build RQ1A.201205.008
• Pixel 4a
• SMS Backup 1.6.0 Beta 2
• Textra

[kurahaupo]

Please attach the debug log

[blip-unicorn]

sms_backup_plus.log

Not much information in it, I use a "Custom IMAP server" and there is no connection made to the server, the app crashes within a second from clicking the "Backup" button so my guess would be somewhere in counting how many calls there is to backup. After this log I unchecked "Backup Call log" and it happily backed up one SMS.

[uj]

Same here. Nothing in the log.

[blip-unicorn]

If I change the setting "Maximum number of items per backup." to "All" it works, any other value (100, 200, 500) makes the app crash.

[kurahaupo]

@blip-unicorn Thanks for both of those.

Even that minimal log helps narrow down where the crash could have occurred.

The information about limiting the number of items per backup will be useful too.

[rdslw]

Same here.
Pixel 4 (not 4a).
Newest android.
App crashes immediatly after pressing 'backup'.
Disabling 'call log' (leaving sms and mms) -> backup works no problem.
I had 500 as max items per backup.
After setting 100 and enabling 'call log' -> still crashes.
Changing max tiems to 'All -> it works (looks like, as it shows 500 items and backup is progressing as I'm typing ;)

Conclusion: if call log items to be backuped up > limit set by the user = app crashes.

[blip-unicorn]

Conclusion: if call log items to be backuped up > limit set by the user = app crashes.

I don't agree with this conclusion since my phone is new and I do not yet have 100 calls in the call log.

[kurahaupo]

This is new behaviour that's only started in the last few months, breaking releases of SMS Backup+ that were "working" for over a year before that.

So one can only surmise that some update to Android has caused or triggered the problem.

Most people are reporting that it crashes unless they choose "unlimited" (or doesn't crash, so they're not talking about it). Personally it's still working fine for me, so it's a bit tricky to diagnose, but it seems like there's a glitch in the limit-handling code somewhere, probably well before it ever starts the backup process judging by the log that's attached.

For example, it might be that when the limit is chosen by the user, the dialog handling code stores a Java object with the wrong type where the limit should be, which later causes a run-time abort. But a null can't cause a type-conflict, which is why "unlimited" still works. And if I had to guess further, I'd say that the object with the wrong type is provided by Android to the application, and Android has recently changed the type of object that it provides.

Please note that this last part is speculative: I'm merely trying to figure out what's most likely from the evidence given so far; I haven't looked at that part of the code yet.

[blip-unicorn]

stacktrace.txt

Given the attached stacktrace I think the culprit is line 59 of BackupQueryBuilder.java where the LIMIT is put into a sortOrder argument of a Query that is later used on line 62 of BackupItemsFetcher.java as an argument to android.content.Resolver.query() which only wants a simple ORDER BY clause in its sortOrder argument.

What I don't understand is how this works for SMS and MMS, it uses the same code and should have the same problem.

[kurahaupo]

@blip-unicorn nice bit of sleuthing there.

That would previously have worked if the back end was constructing an SQL statement, so that

select * from foo order by date

becomes

select * from foo order by date limit 500

So yes, the back end has changed to be more strict about what's accepted in the "order by" field.

In the short term, everyone please turn off this limit.

[blip-unicorn]

If I read the Android source correct this is a change between Android 10 and Android 11 and was introduced by commit 1949102

[kurahaupo]

@blip-unicorn looks like you're right on the money there, thanks!

(However why they needed to exclude LIMIT mystifies me, as it can only take an integer parameter, so it doesn't introduce any risk of "bad" or "costly" SQL injection.)

[kurahaupo]

To reiterate for everyone else: if you're on an Android-11 device, do not attempt to limit the number of backed messages to be backed up or restored.

[ghost]

My thanks to everyone who figured this out! I KNEW it had to be something about my phone, because this just started recently & I'd never had a problem with it in years of use. I just noticed issues over the last week or so, & was trying to narrow it down based on what I saw as the most recent dates for the SMS, MMS, & call log backups. I had limited the number of items in the past because, in the course of switching phones a year ago, I've wound up with multiple copies of, really, a LOT of items. But now, having switched to "All", the app appears to be back to normal.

[hieu76]

Vào 9:39, Th 2, 11 thg 10, 2021 Hương Ngô ***@***.***> đã viết:

…

Vào 7:54, Th 5, 7 thg 10, 2021 Rrtccd ***@***.***> đã viết: > My thanks to everyone who figured this out! I KNEW it had to be something > about my phone, because this just started recently & I'd never had a > problem with it in years of use. I just noticed issues over the last week > or so, & was trying to narrow it down based on what I saw as the most > recent dates for the SMS, MMS, & call log backups. I had limited the number > of items in the past because, in the course of switching phones a year ago, > I've wound up with multiple copies of, really, a LOT of items. But now, > having switched to "All", the app appears to be back to normal. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#1054 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AHG3HMA2W3KP7KG24QY6GNDUFTVTBANCNFSM4WQGM7YQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > >

[JKS258]

THANK YOU to all that figured this out! I've been having the exact same problem everyone else has for months. Text messages and the call log are EXTREMELY critical to me since it date and time-stamps some extreme issues in my personal life and provide me with evidence of who said what and when. Without it, I'm doomed to 'he said, she said." This App has been invaluable for me since I've had it, which has been about as long as it's been out; so long I can't remember! Fortunately, I signed up for updates on this topic, got the email with the solutions many in this group figured out, tried them myself (no limit on number of items per backup) and now it's working! WHAT a relief and a virtual lifesaver in my case. Thanks again to all, along with the developer. All the best...