Ensure escape from freezes

[JackMostow]

@amyogan, @judithodili, et al. -
Freezes, where RoboTutor stops responding to any input, are the scariest type of bug because to escape them in kiosk mode requires rebooting the tablet, which is harder and less obvious than restarting after a crash or tapping Back to escape when an activity gets stuck.

We have found and fixed some specific freezes, but there's no way to ensure we've fixed all of them.
Is there a way to ensure escape from freezes?
One way is to kill the apk if it detects prolonged inactivity, i.e. a timer reaches a limit on the time since the last detected actions.
As one might expect, this approach has known solutions, one of which @amogh112 has already implemented.

To avoid timing out while loading assets, don't start the timer until after loading them.

We want your advice on these questions and on use cases we may not have considered but ought to:

1. How long to wait before timing out?
   a. ~1 minute or less if truly frozen
   b. but not if RoboTutor is playing a video or reading a story; anything else?
2. What constitutes inactivity?
   a. No student taps? But kids may not tap while reading or listening to a story.
   b. No tutor audio output? But RoboTutor may not say anything while a kid is reading.
   c. No animator graph transitions? But do any animator graph states last longer than a minute? Yes, playing a long video.
   d. Staying in the chooser without choosing?
3. What to do about activities with no user input, e.g. story.hear, or intro videos?
   a. Don't time out during them
   -: but what if RoboTutor freezes during one of them?
   b. Make tutor actions restart the timer
4. When is it actually undesirable to exit during prolonged inactivity?
   a. When the kid takes a break during a long story?
   b. When the kid wants to save the state of a game?

Thanks! - Jack

[amyogan]

I think the simplest solution that requires the least amount of parameters is to reboot after a long time of inactivity. Like 10 minutes.

[JackMostow]

Kevin found and fixed the reproducible freezes and added some verbose logging at the point where we suspect intermittent freezes may occur, so that VMC can catch them tomorrow if they recur.
It turns out that we can't distinguish a frozen screen with random tapping from normal activity, which makes auto-timeout not quite as attractive.
I'm mainly concerned about use cases for item 4. Thoughts?

[amyogan]

What's item 4?

[JackMostow]

Sorry, I mean "4. When is it actually undesirable to exit during prolonged inactivity?" in my post above.

[amyogan]

Ah, I think you updated the post, it originally only had 3 items. Um, I'm not sure I have a major concern about rebooting (as long as sufficient time has passed, don't do it after just a few minutes).