Question: **What is the workflow on devices when the Play Store updates an app? What happens if the user is using the app at the same time?**

I ask because we have some crashes where a String ID cannot be found, and when we looked at the APKs the String resource is available in both versions - but the hex ID reported in the crashes is found in the OLD apk and not in the NEW one. This is strange.

This leads us to think that the Play Store may have updated the app's files and resources while the app was running, and then when it looked up the string resource to load something it used the old ID from memory and of course didn't find it in the newly updated files.. leading to the ResourceNotFound exception.

*How is that possible? Is it even possible?* I'd think not, except we looked in the APKs and the ID that was in the crash matched the old resource id and not the new one that we just pushed.

Answer: 
From what I could find in researching this, it seems as though the App *needs* to be closed in order for the files to be reachable for update. Once closed, Google Play updates only the changed pieces of the apk to save time and cost. 

There are several forum posts I have found that teach you how to rollback app options from flashed ROM (which happens all the time with rooted devices). Perhaps the user attempted to rollback after receiving the update. Either that, or the ID that was in the crash is referenced in part of your apk that was not updated.

Sources:
[Notification of Update](https://stackoverflow.com/questions/9849889/how-to-notifiy-users-about-an-android-app-update)

[What Happens When You Update an App](https://stackoverflow.com/questions/16087714/what-happens-when-you-update-an-android-app)

[Google Play Saves Cost & Time](http://www.techhive.com/article/261004/google_play_smart_updates_save_data_costs_and_time.html)
If the user is using the app at the same time it's updating the app the linux filesystem allows for the behavior described above. A process holding a file open (think the app executable while the app is running) will keep the executable image in memory even if the executable on disk has been updated. What this allows is the new apk to be put in place and unpacked with the old exe image still in memory. 

Resource files tend to be lazily loaded, so navigating the old image in memory will look for resources and potentially load a resource from the newly unpacked app. The resource may not be compatible with the old app and cause a crash.