Q1, 2, 3: Problem/ versions / tried-so-far:
I'm supporting a field test in Kenya running ODK Collect v.1.24.1 and Android 7.0 on TECNO SAS6 hardware with 8GB of storage and 1GB of memory onboard. The data is being stored on https://kobo.humanitarianresponse.info/#/forms. Most of the interviewer phones do not have SIM cards, and are meant to upload data via hotspot 2-3 times per day. We hoped that each would do ~20-40 completed interviews per day, although the pilot is meant partly to sort whether that's realistic.
We have had numerous phones crash while runnning ODK Collect. I haven't been present when it happens, but I think today I can probably get my hands on a phone that has recently crashed. If there is something helpful I can pull out of the phone to help narrow down the cause, I'll be grateful to learn how to do that.
The project has an extended set of IT support staff, but at the moment we don't have a cohesive approach for this problem and different staff are trying different approaches and solutions and it's not obvious to me that any are effective. Some report that even after resetting the phone to factory settings and re-installing ODK and the forms, it crashes again quite soon.
Some of the IT team believe the problem might be related to the phones needing a Google update. Others believe the problem may have to do with the list of apps that we disabled or deleted to make the phones "less fun" for the field data collectors. I have a list of apps that were disabled/deleted. I've pasted a link to files that describe that below.
I read online today and understand that the problem can be due to using up all the RAM - either by storing too many completed forms or by using logic that is too complicated and not modular. Some of the crashes happened even during training before they had many forms at all...I don't think it's a problem (yet) of too many stored forms. I've pasted a dropbox link to a folder holding the forms. Is there a straightforward or objective tool or way analyze whether the logic is too complicated? I'm sure that if we had realized it was important, we could have made the calculations and relevance statements more succinct or modular, but at this time that is not an area where we can easily experiment as we have the forms in the field on 200+ forms. We CAN replace the forms on all phones if needed, but I would prefer not to do that more than once and I'd like to have a high degree of confidence that it will work before assembling the crew to do that.
Today is our first day in the field and I'll know in a few hours how many successful interviews we had and I'll have an informal report of the proportion of phones with a problem, but based on training yesterday and the day before it was on the order of 10% or more of the phones.
I've instituted a procedure to track which phones fail, what we try, and whether they fail again, but we lack good ideas other than running Google updates.
4. What steps can we take to reproduce the problem?
I don't know what to say here. I've been entering data on my project phone this morning and I think it's safe to say I've entered more data than anyone could have during the training...and I haven't crashed mine yet. I'll keep trying.
5. Anything else we should know or have? If you have a test form or screenshots or logs, attach below.
How do I access a log to share that?
Here's a link to a dropbox folder that holds two sub-folders:
"Apps removed" - holds two excel files...showing how the apps were dropped for phones with and without SIM cards.
"Forms" holds five .xls forms. I have permission to share the forms. The signin forms are almost trivial. The child_vaccination forms are the main point of this survey and are somewhat complex. The missed_vx_follow_up is also somewhat complex; we won't try that one in the field until late in the week, so if we should simplify the logic there, we probably have time. I believe that the failures are happening mostly in: child_vaccination_VOL_tool_v12.xls