0.56.2 keeps crashing on startup #74
Labels
No Label
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Starfish/TinyWeatherForecastGermany#74
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
Updating 0.56.1 to 0.56.2 using the apks provided here:
Unfortunately, I see no way to provide any further debug info.
This is a (tricky) bug in the new stationSearchEngine. Hopefully fixed:
09094109b5Interesting fact: I was able to reproduce it when the device was in landscape mode and the launcher was fixed to portrait mode.
As long as the device and launcher were in portrait mode, the app did not crash.
This is somehow wired, because it should not make a difference.
You can test a userdebug, if you like:
https://kaffeemitkoffein.de/nextcloud/index.php/s/4SXHaLxLSmFd8Ri
I would be happy if you could cofirm that this is fixed now, because somehow it still looks wired that the device orientation seems to play a role here ....
This will very likely harden the app start as well:
970a563ef1The initial processing of the area database (which needs to be done only once!) previously could be interrupted by screen rotation, which led to an incomplete database, which as a result needed to be processed again.
This did not lead to an app crash, but now the screen rotation is locked for a couple of seconds until the database processing finishes.
There was also an issue with the progress dialog crashing when the screen got rotated during processing. The same applies to the "What is new" dialog.
Both are now being closed properly when the activity gets destroyed, e.g. due to device rotation.
Both should harden the app start significantly and prevent some crashes.
Hm. I did not do any rotations.
Hm/2. It was all in portrait.
Did this ASAP and gave
TinyWeatherForecastGermany-build025-version_0.56.2-userdebug-20210704-03-fixed_dialogs
a try. Unfortunately, "It is my sad duity to inform you..." I did not do all cycles above, but even with deinstall and fresh install and after a reboot, I was out of luck. :(
It starts building the database and almost as it hits the 100%
The application keeps crashingand it's dead. The funny thing is, from a glimpse at the background it seems that it did already fetch data for my usual or the default location. I even see it in the task list with a proper display. As soon as I switch to the appboom.Usually I have a widget placed on my home screen but the behaviour does not depend on it's existence, if this is of any help.
If I can provide any additional intel, please let me know.
There was a running condition in the weather warnings, resulting in the possibility that warnings were being read and processed before the area database was ready. This is fixed now:
4d1192ab18Please try the latest userdebug.
Unfortunately, it still dies at the same point, as far as I can judge it at least. Is there a possibility for some poor mans debugging like a
print()if a function enters and/or ends? I fear my report is not really helpful at the moment as I see a "something is broken somewhere", but I have no idea where.Ok, we'll solve it. 😃
Please try the userdebug named error_dialog, it should display any error without crashing and it will copy the error to the clipboard.
When you enable logging, it will also put the error message in the log.
So, we see some restiction to the issue here: it still displays the
what's new, it still builds the area database but it dies before this function has a chance to kick in. IOW I do not get any display nor any text in the clipboard (Markor only offersselectnopaste)How would I do this? Point is: after the update I can not access any menues as it's dead before I have access. I set it on the 0.56, so I guess it carries over, but then how would I access the log if I can't got to the menu item to read it?
What is your Android version? 10?
Android 9 in the SONY flavour, running on a XPeria XZ1 compact (G8441).
There is one thing that changed in the code that is not apparent to the user: the xml files have been re-designed in preparation of a theme support, so that the app will be able to easily switch between different themes and will be able to respect the dark/light theming of the device that is supported in recent apis.
There was also a stupid thing in version 0.56.2: setContentView was called before setTheme. It is possible that your flavour did not tolerate this, as it is advised not to inflate any views before the setTheme call. This is a bug, however, all devices but your's seem to tolerate it. I have not received any crash reports besides this one for 0.56.2. This might solve the issue, as this has been fixed.
I also improved the check for internet connection so that it does not use any classes that are deprecated in api 29. In fact, the check is now done differently on any phone having api 23 or higher. Perhaps this was a cause, too.
Should your app keep crashing with 0.56.3, I will redesign the logging so that userdebug versions will cache logging and will present critical errors on next app launch without really starting the app. In this way, we will be able to trace what happens.
Don't worry, we will get the app working on your device sooner or later. :-)
I fear, I have to report that it does. 🤔
However, accidentally there is some progress. It does not crash, if I disable the rain radar. This is also true for the 0.52.x userdebugs. As soon as I switch off the rain radar all of them start up fine. Switch on the radar, leave settings, it starts to build a database and as soon this is finished or very near the end it crashes.
I did install 0.56.1 switch off the radar (it's on by default, hence I need a working version to do this) and then I can happily update. As soon as I enable the radar in any version I tried, back to square 1.
Also note that some change reintroduced the black menu text on dark background we already had. (My device runs in eternal night mode.)
The other difference I know of compared to the mot usual setup here in Germany, but not sure this is related, its language is set to English. (I really don't likeGerman for software).
I have the same issue it seems. Also German locale, but English language set. Phone has a hardware keyboard, but was not rotated during the test run. Running on Lineage 16 / Android 9.
Here is some logcat I got from Version 0.56.3 (first start of the app after clearing storage):
Ok, seems that SQLITE_IOERR_SHORT_READ is the key.
This means that SQLite cannot read the database of areas.
I will dig into it, but one question:
Did you (or any tool) move the app on the SD card? Can you please check under app details where the app is stored?
Because of the widgets, the app must not be installed on the SD card, which is prevented by the according entry in the manifest file.
My phone doesn't even have an sdcard ;) Also: I did have the widget installed (twice), but removed it recently to see if that causes any errors.
It was installed with the F-Droid Priviledged Extension if that makes any difference.
Here is what is in the app data folder:
Let me know if I should attach the db files
Ok, not having an SD card makes it plausible that this is NOT the issue :-)
It seems that the area database is created properly according to the size. The files do not look suspicious at all.
I will check the code. The most stupid thing is that I need to reproduce it somehow to really fix it. The error points at a quite low level issue (it is basically an IO error), perhaps I do something wrong in the database access. Will check.
The point with the fdroid privileged extension is interesting: can anybody else confirm she/he is using it when installing fdroid apps?
I just tried to access the DB with the sqlite3 installed on the phone and that also looks normal:
I think this warning might be relevant:
At least to me as Java dev this looks a lot like a database connection where close() was not called for some reason. Maybe it's not closed and then opened a second time somewhere else? That might explain the IO error.
Yes, true. This might be the cause. Thanks!
However, it is quite clear now that the error is somewhere in the AreaContentProvider class, because this is the layer between sqlite and the app.
Thanks for the logs, that really helps!
I had a look at the code and I think I found the problem. I started a pull request and described the problem there.
Also: Line 55 looks strange. Why is that "if" empty? Can it be removed or is there something missing? I'm not really an android dev, so I can't tell :)
Just to aks: whould it have been possible for me as a lesser mortal on a standard device to provide these logs as well, and if so, how? If so, I'd be happy to learn about that.
I think logs should be available on adb. You should be able to unlock the developer options https://developer.android.com/studio/debug/dev-options
Then you need a tool called "adb" on your PC. On Linux it is often available in a package from your distribution. Or you can download it here: https://developer.android.com/studio/command-line/adb
Then you need to connect your phone via USB, activate "USB debugging" in the developer options, and start "adb logcat".
All this should be possible on a normal device without root as far as I remember.
@dicer thanks for these pointers, I'll give it a try and see if I can find my way around. :)
There is some news. The pull request from @dicer was a good start (#79), but led to some null pointer exceptions when trying to read area data.
Using ContentResolver instead of directly accessing the AreaContentProvider seems to resolve all errors.
I am not sure why, but it seems to be troublesome to query/write to the AreaContentProvider directly when doing so from different threads, this post points at a similar issue. It seems safer to wrap it with a ContentResolver.
Later this day, I will create a userdebug so that you can test this.
Indeed, I can confirm that
TinyWeatherForecastGermany-build025-version_0.56.2-userdebug-20210729-access_area_data_with_ContentResolverdoes not crash upon startup everytime anymore if I switch on the warnings again.I still do see some spurious crashes of the sort described above. IOW the app starts building the area db and right at the end of that it dies. Sometimes. If I open it again and everything can be fine (or it may crash again and the next startup is fine.) I hope this log captures one of these cycles properly:
If logging worked as expected it should be a failed startup followed by a successful one.
There is also a new issue on that front. TWFG will recreate the database (
This needs to be done only once) every time I close the app and restart it. Now, I have to admit that I might not yet getclosingan app on Android properly. What I do is: fire up the window list and swipe it away from there. Once done this, if I fire up the app from the widget or from it's icon the location database gets rebuilt.The area database creation was broken in the last unserdebug.
It took me quite a long time to find out why (short answer: do not delete a database on the main thread when unsing a ContentProvider at the same time, because the ContentProvider won't notice reliably that the database is gone).
To improve user experience, the creation of the area database does not block the UI any more.
Crashes related to the area database should be finally fixed now.
You can give a new userdebug a try.
Indeed all seems well now! Thank you! :)
And it even looks nice. :)
Then, you can enjoy the sea and costal areas displayed correctly, finally. :-)
fixed:
45668ef37band confirmed by @arwagner