ee82e34a28
The problem was: - MessageFileViewFragment.clearContent (A) is called in onDestroy - MessageFileViewFragment.openMessageSync (B) is called in a bg thread to load an eml file - And both try to hold the same lock. (mLock) - If EML is large enough, B takes _seconds_. If you press back during this, onDestroy gets blocked trying to lock mLock. - This could also cause a crash, because the task that runs openMessageSync won't get cancelled in this case, because that's done in clearContent. Because of this, the task's onPostExecute tries to touch a UI element when the fragment is actually being destroyed. The lock was introduced to protect mFileEmailUri, only to keep the same semantics for openMessage() as MessageViewFragment. i.e. openMessage can be called multiple times for the same instance of the fragment. However, in practice, this won't happen. Unlike the regular message view, we never reuse MessageFileViewFragment. MessageFileViewFragment instances are created per message. This lock was just reminiscence from the early developmen stage. So, fix is simple -- just remove the lock. Bug 3500487 Change-Id: If2b22a683666de535454bb1293563796fa7acfd7 |
||
---|---|---|
assets | ||
docs | ||
emailcommon | ||
images | ||
res | ||
src/com | ||
tests | ||
.classpath | ||
.project | ||
Android.mk | ||
AndroidManifest.xml | ||
CleanSpec.mk | ||
MODULE_LICENSE_APACHE2 | ||
NOTICE | ||
proguard.flags | ||
remove-exchange-support.sh |