Handle configuration changes in the right way #6538
Description
What is the user problem or growth opportunity you want to see solved?
The app doesn't handle configuration changes (theme switch, screen rotation, etc.) as recommended in the official docs. We have configChange property in the manifest for some of the activities, so we do not see any crashes there but for others, we aren't persisting state everywhere.
Is adding configChange to manifest the right way? Probably no. But adding defensive checks everywhere or simply making a property nullable to avoid that crash doesn't seem right either. We need a framework/SOP around how we tackle configuration changes in the app.
We can use a coding agent to figure out all such points in the codebase as long as it suggests the standard ways mentioned in the docs. The problem with solving one crash report at a time with an LLM is that the fix is localised and not maintainable. For instance, in one of the recent PRs, it detected configuration changes as a "timing issue", which it probably wasn't since the crash happens even after waiting for some time. Any further questions had a localised response.
With limited context (one or two crash reports), we'll not be solving the root cause and end up with different solutions every time we try to solve for a crash report. Opening this issue so that we discuss and come up with a standardised approach (with or without an LLM).
How do you know that this problem exists today? Why is this important?
Recent crash reports and how they were fixed.
Who will benefit from it?
Maintainers and the open source community which take a reference of our code.
Anything else you would like to add?
No response