App Crashes

[QISPSK]

Hi all,

As we work through all the providers to upgrade to the newest version of the app (v1.3), we've encountered a handful (~10) that seem to be crashing on startup continuously and providers cannot submit data.

Panharith, who has been out in the field updating, was kind enough to collect that ADB output related to the application which I've attached here. Could you look into this issue and estimate how much time/effort it would take to fix this?

Here are two verbose ADB logs: https://drive.google.com/open?id=0BwQE0UgKE3AmVU1JcWNCYlZMcDQ

Thanks, Eli

[QISPSK]

Following up on this issue as I haven't heard a response. Any thoughts? Thanks!

[ifoche]

Sorry @QISPSK for not answering before. As talked through email, could you please provide us with the DB of any of the providers having that problem?

[QISPSK]

@ifoche No worries! The app is crashing on launch - is there a way to pull the DB from outside of the application?

[QISPSK]

@ifoche Sorry to keep bugging, but just making sure these messages are still coming through. Can you explain how we can pull the DB off the phone outside of the application? Perhaps using ADB? Thanks.

[ifoche]

@QISPSK sorry, looks like I'm always missing your messages. This time I was on leave moving to a new place. I hope no more delays will come in the future. To extract the DB you just have to go to settings inside the app, activate the "Developers options". That will make a new option appear in the top-right menu saying "Export database". That will ask you to select the method. Maybe you can use Gmail and export it to me...would that be possible? Thanks!

[QISPSK]

@ifoche No worries! Unfortunately, this app crash happens every time the app is opened and thus does not allow us to access the settings menu within the application. We messed around with ADB to see if we could manually pull it off, but it appears this is only possible on a rooted phone. Any other ideas/ways you may know of that we can extract the database for you?

[ifoche]

@QISPSK Ok, I see. If your device (virtual or real) is not rooted, you're right that you cannot obtain the DB through ADB...so I guess there's no way (apart from creating an specific patch for the app to export the DB before entering it...but that looks like very expensive).

However digging a little bit more on your ADB messages I think even without having the exact DB and situation we can guess why that problem happened or at least build a workaround to protect the app against that situation. BTW, thank you very much for that. It's really useful.

[ifoche]

@QISPSK we're currently blaming the performance of those devices, we're looking for a workaround but in the meantime but...would it be possible to know the model of some failing devices?

[ifoche]

@QISPSK it would be great if you could also provide their Android versions

[QISPSK]

@ifoche Both LG K7s and LG Leons are experiencing the issue in the field. There does seem to be some connection between the version of android as upgrading the version has seemingly fixed the issues for almost all phones in one province, however at least one phone in that province is still running into the issue after the update.

While I don't have the phone associated with either log on hand, I do have an LG Leon that is experiencing the issue here which is on Android version 5.0.1. If it would be helpful, I'd be happy to send through the ADB logs of this phone as well.

[ifoche]

Oh, that's great. We think we could have a workaround so maybe we can send you a version with that workaround for you to test it in that phone?

[QISPSK]

@ifoche Sure! Happy to give it a shot and see if it fixes the issue

[ifoche]

Fine, let us test it a little bit before and we'll deploy a new version once tested for you to verify. Please be sure to test it both in the failing device and at least another "control device", just to be sure that it works for both of them

[QISPSK]

@ifoche Sounds good. Note that it may be slightly difficult to test on our end as we're not 100% sure what is causing the problem. If we simply uninstall and reinstall the app, it seems to fix the issue temporarily, however it seems to break again after entering some data. Regardless, we will play around with the build on both this device and a control to see if we run into issues.

[ifoche]

@QISPSK please let me know whenever you test the new version in the failing device if it makes the app work or if it doesn't. If it continues failing in that device, it would also be very helpful to have the ADB logs. Thanks!

[QISPSK]

@ifoche App seems to be working after some very quick testing, however can you elaborate on what you think the issue is and what may be causing the crash? Given that we cannot replicate the crash on phones that have experienced the issue previously, it would be helpful for us to know what conditions may have lead to the crash so we can test these out under the new BB version. Thanks!

[ifoche]

@QISPSK it was a combination of 2 very simple fixes: 1) Move the initialization of filters (the dropdown) to the onResume() method of the activities instead of the onCreate() method (so if the app goes to standby, the filters are initialized again when opened, to prevent a NullPointerException there) 2) From your ADB we read a NullPointerException when trying to use the ListView object of the DashboardSentFragment (the screen where you see the surveys that have already been sent). This object was sometimes used in asynchronous tasks that could be reached in certain situations without it being initialized. We included a safe access to the object by first asking if it's null and retrieving it from the ListFragment itself (ListFragment has a getListView() method).

Unfortunately, I cannot tell you exactly which conditions took you to the crash. My guess is that: 1) It may have to do with leaving the app in background still working and while in background receiving a notification of a survey that has been sent. 2) Devices with a poor performance that may take more time to do operations happening in parallel

But honestly...we would need to physically have a device with the problem to analyse more in detail.

So...does it mean that we can publish on Google Play this fix?

[QISPSK]

@ifoche Thanks for the detailed explanation! We will run it through the usual paces a bit more today and likely request that you publish it around COB today.

Also, a question on budget - approximately how much is this fix going to set us back?

Thanks!

[ifoche]

@QISPSK Thanks to you.

I'm not sure to properly understand your question. You mean how many hours did what's done took or how many hours would it take to analyze one of the phones that were presenting the crash problem and guarantee that the workaround that we introduced will work for every situation and otherwise code the final solution?

[QISPSK]

@ifoche I think just how many hours spent working on the fix as we will only really find out if it's working when we start to roll it out.

Also, unfortunately it looks like we spoke too soon. Panharith is out in the field testing the BB version and has run into a similar crash due to a NullPointerException and the logs look nearly identical to what we were seeing on the previous version.

Here is a link to a video of the crash and two new ADB log files.

Note that this is happening on an LG K7, android version 5.1. Tests were entered the previous day and then Panharith tried to enter 10 new tests today and the app crashed during entry. When he tried to reopen the app, it continued to crash. Those continued crashes are what show up in the logs. Let us know if you need any other information.

[ifoche]

@QISPSK just a question. Panharith is using the last BB version we deployed 2 days ago in those phones that produced the crash, right?

Re the fix time, I think we've spent around 5 hours if we count all the analysis, coding, coordination, etc. I'm not sure because I would need to analyze our internal registers for being more specific, but I hope that estimation is enough for you to have an idea.

In this sense, I guess having the DB would be really useful to make the bug much more easy to find. Would that be possible?

[QISPSK]

@ifoche Yes, that is correct, he is using BB61 - the one that came out 2 days ago.

As for the estimation, that is perfect, just trying to get a sense of how much the fix may cost as budgets here are limited due to the unforeseen costs associated with updating DHIS2 to v2.25.

And unfortunately, the devices are not rooted (and I haven't found an easy solution online to root the devices) nor can the app be accessed as it crashes on load so we cannot pull off the DB. If you know of any other way, let us know and we can try and pull off a copy for you.

[QISPSK]

@ifoche Sorry to keep bothering you on this, but this is a pretty critical issue to our program as more and more phones are unable to report due to this bug. Do you know of any way that we can pull the DB off phones that are not rooted? Thanks.

[QISPSK]

@ifoche any updates on this? More and more phones are crashing and providers are unable to send data. Any updates would be appreciated.

[ifoche]

Sorry @QISPSK for the long delay. We're now generating a new version were we've modified a bit how we're logging the messages for the ADB logs. As we don't have that crash it's difficult to trace. If you could send us the ADB log (from a crashing device) using the apk recently generated, that would be very helpful. Thank you and sorry again!

[QISPSK]

@ifoche Thanks for the response and update! Definitely can appreciate that it's a bit more difficult to figure out what's going on given that we aren't sure how to replicate the issue.

Panharith is out in the field this week and will work on testing the new BB version (and I will test here in Phnom Penh) to see if we can again replicate the issue and send through the logs. Fingers crossed!