From examining a customer project that uses AVPro Video (https://renderheads.com/products/avpro-video/) for Android, trying to track down the causes of managed allocations in MediaPlayer.Update() by enabling Call Stacks in the Profiler. For context, examining the code shows that:

- MediaPlayer.Update() calls AndroidMediaPlayer.Update()...
- ... which calls AndroidMediaPlayer.UpdateTimeRanges() (amongst other things)...
- ... which calls AndroidJavaObject.Call() (https://docs.unity3d.com/ScriptReference/AndroidJavaObject.Call.html) ...
- ... and both AndroidMediaPlayer and AndroidJavaObject (disassembled and viewed in Rider) call various methods on AndroidJNIHelper (https://docs.unity3d.com/ScriptReference/AndroidJNIHelper.html) which use StringBuilder and reflection.

If the scripting backend is set to IL2CPP the call stack contains nonsensical information - for example, constructors from random unrelated classes within the project appearing to call each other. If it's set to Mono, the call stacks are somewhat better: they don't include the methods in AndroidJavaObject (inlined, perhaps?), but they do show the use of StringBuilder and reflection.

It would be useful to see more complete and accurate call stacks in this kind of use-case, particularly if IL2CPP is the scripting backend.

Issue seen in Unity 2019.4.32f1. We haven't tested to see how many other calls to garbage-generating Unity APIs result in mangled call stacks.