How to predict Android release build runtime crash due to Proguard obfuscation

While I am aware of how to troubleshoot Proguard related issues, verifying that no crash will occur when the app is launched is time consuming:

1. Modify module's proguard.cfg
2. Build > Clean Project
3. Build > Generate Signed App Bundle / APK...
4. Wait for the entire build to finish
5. Uninstall the previous APK
6. Connect the phone via USB (no crash occurs on emulated device).
7. Copy the release APK to the phone
8. Install this new APK
9. Open the app
10. Boom...

  FATAL EXCEPTION: main
  java.lang.NoSuchFieldError: No field xxx of type yyy

When troubleshooting such an issue, I am not always sure whether my fix would work and so I end up repeating the above steps several times (as in this LinkageError).

This is, of course, very time consuming and I wish there were some messages during the build/generate itself that would tell me about those runtime errors.

It is possible that I am doing something fundamentally wrong and so I am looking for tips or advise that would help me shorten the aforementioned cycle considerably.

Is there a technique to predict Android release build runtime crash due to Proguard obfuscation?

If so, how do I accomplish this?

The following tip will help you immensely, although by no means is it a comprehensive answer:

When you Build > Generate Signed App Bundle / APK... and you get the following the following error in your Build console (during the minifyReleaseWithR8 task):

Missing classes detected while running R8. Please add the missing classes or apply additional keep rules that are generated in <project_root_path>\build\outputs\mapping\release\missing_rules.txt.

Note the "missing classes" details:

• For every file listed in missing_rules.txt requiring a -dontwarn statement/line, don't add the -dontwarn rule to your existing keep rules in order to suppress warnings (as suggested by R8).
• Instead, add -keep public class com.yourorg.yourlib.MissingClassName { *; }

In essence, this prevents those "runtime bombs" (in the form of "warnings") from become runtime FATAL EXCEPTIONs.