Open julianharty opened 2 years ago
This is the first issue reported as part of https://github.com/kiwix/kiwix-android/issues/2903
@MohitMaliFtechiz Do you have an explanation? Would that bug be easy to fix?
hi @kelson42 ,
This bug usually comes when we installed apk outside the google play due to mismatch installation of architecture. please check the following link https://github.com/objectbox/objectbox-java/issues/605. Some users using architecture which is not supported by ObjectBox.
@MohitMaliFtechiz Thx, we have not to identify such a situation at start and make managed exit with clear error? I wonder as well a bit that kiwix starts at all if the code does not match the architecture!
@MohitMaliFtechiz Any feedabck? We should avoid the crash and detect the problem earlier to have a managed exit. What can be done?
Hi @kelson42 , Proper handling for this situation is being done on the above PR.
@MohitMaliFtechiz and @kelson42 Sorry for the late code review, however I've noticed the current message is a bit unclear for the users and I think we can make the message clearer. I've added a code review to the PR.
reopen now because of F-Droid publish FOSS issue.
Copied from https://github.com/kiwix/kiwix-android/issues/2959#issuecomment-1219460710
@kelson42 @MohitMaliFtechiz Here are some ideas about ways we can address the needs of #2904 for both the F-Droid Build and the Google Play Builds while also helping the end users. I expect there will be some details to resolve in terms of the implementation.
Potentially we could write our own detection code and UI (e.g. to help end users find a local solution e.g. if they've copied the app binary locally perhaps they could also copy across the missing files). And similarly, we could potentially write our own download code to obtain the missing files from a) Google Play (if that's practical and they let us do so programmatically) and b) our own servers.
If the download code + hosting the necessary files isn't viable then the first two aspects (writing our own detection code and UI) combined with code that then exits the app (similar to how the Google approach works) could be an alternative.
Another suggestion is that we only implement the Google-based code in the builds that target Google Play, however that'd probably add to the complexity of our code.
What do you think? would any of these suggestions help? Thank you
Julian
AFAIK, we need a FOSS compatible (to the contrary of previous attempt) way to check at start if the APK architecture is the same at the runtime architecture. I'm not in favour to write our own stuff, but maybe there just a simple smart way to do so. Actually I wonder a bit that the runtime engine does not check it!
@gouri-panda I think this whole problem won't exist anymore with Room. Please confirm. If "yes", we should clean all the PR which have already been done for this ticket, in particular #2915.
@kelson42 I don't know much about this ticket but yes if the objectbox causing this issue it won't exist after the migration. We'll see after the migration :)
I admit this may be awkward to fix, the main reason I've added it here is this crash is the most frequent one that occurs currently for production releases of the Kiwix Android when it has not been installed from Google Play. It also happens less often (but still enough to appear in the top few crashes) when the app is installed from Google Play.
If we can find a way to address this problem then even those users who find other ways to install the app will be able to use it reliably.
Reported Impact This crash appears to impact both users who installed the app from Google Play and those who installed it from somewhere else. It affects those who installed the app from somewhere else more frequently than those who used Google Play. It does not occur in the top 40 crashes for the Chemistry and Physics simulation or WikiMed (en) apps and it's unlikely it happens in other ones; that said they may not be downloaded as frequently outside Google Play.
There were 6 crash clusters in the first 25 rows (which are ranked in descending order of occurrences) for this crash cluster:
java.lang.UnsatisfiedLinkError io.objectbox.internal.NativeLibraryLoader.<clinit>
The first column is when the
Installed from Google Play
filter is not used, the second column is when that filter has been applied. The rest of the numbers are unchanged regardless of whether that filter is applied. Tip, the URL has an extra parameter appended when we filter the installs e.g. Cluster 9b1318f4 with &installedFrom=PLAY_STOREThe crash occurs in various app bundles (unique app versions), on various device models, and on various Android versions. It also occurs when the app is in the foreground and in the background (occasionally).
Steps to reproduce the behavior: The steps to reproduce this issue are not known currently, this issue is being reported in Android Vitals, see the first screenshot with the following filters applied:
Screenshots
Top crash cluster with Installed from Google Play filter Cluster 1f31cfb3
Second crash cluster without the
Installed from Google Play
filter:Expected behavior The app should not crash.
That said, perhaps the best we can do is detect an issue where the app cannot find the relevant runtime file and display a message to help the end-user recognise what the problem is, or perhaps we could help them work out how to manually install the file, etc?
Environment Production releases of Kiwix Android
3.4.5
at the time this bug was raised.Logs Here's an example of the most recent stacktrace for this crash from the most frequent (top) crash cluster, Cluster 1f31cfb3 :
For the second most frequent crash cluster, Cluster 1aa80b6e :
I've not included screenshots or stack traces for crash clusters 3 to 6 to save space. They can be added if they're useful.