Unfortunately, due to the way the Android framework is structured we - and other SDKs - can't just register for callbacks on Android Activity state changes. Activity changes are communicated to an app via overridden methods on the activity class for the application.
Since you're trying to minimize the amount of 3rd party SDKs you modify you could simply replace the Plugins/Android/AndroidManifest.xml supplied with your own that includes the components you need. Then customize it by calling your own application specific activity instead of the one supplied by us (Firebase) or 3rd party SDKs. From your own application specific activity you can include the logic from 3rd party SDK activities. You don't need to change any of the 3rd party jars / aars, if they're not referenced by the AndroidManifest.xml then - assuming you have Proguard turned on - they'll be stripped out and they won't be called anyway.
We're open to ideas to improve this situation. Something we considered were free floating methods that could be called from an application specific Activity class but that isn't possible in the case of "fixing" Unity's "Activity.onCreate" since we need access to mUnityPlayer which is a protected member of the class. I guess we could try something hokey like try still shipping an Activity that extends UnityPlayerActivity but has static methods that could modify other activities that extend UnityPlayerActivity, TBH it doesn't feel that much better to me.
I hope this helps.
Cheers,
Stewart