As well as the other answers, an alternative is to use smali to somewhat decompile the app, figure out which HTTP library it's using, delete the call to the function that enables pinning, rebuild the apk, sign it and run that version.

The longer version is that it really varies based on the app. Some apps are using something like React Native and have all their logic in Javascript. Some apps have the API in Java code and you can figure it out by using jadx to get a reasonable approximation of the original source. Some apps do all of this in native code, and then you're into Ghidra territory. My personal experience is that MITMing the connection is the easiest way to get an understanding of the overall shape of the API, with inspection of the code itself then being used to fill in gaps.

For me it’s using a rooted phone. I have some info for my RE on another app that might be helpful.

https://docs.google.com/document/d/1q0Pz2t5Gmt-vv8z-2Yswhvg2...

For me, the fastest way involves using apktool to decompile it, then simply reading the API code. Or insert a log statement, recompile, run on phone w adb log - requires minimal Android code fluency

Does this usually work? I just unzipped an apk once and saw it was all javascript but I assumed other apps would be minified.

Java/Android is basically gibberish to me as is - Maybe it is obfuscated sometimes. But strings themselves (API endpoints) have to be present some way or another.

There is also something called "smali" which is an intermediate representation - You can edit it following something like https://stackoverflow.com/questions/31101740/method-to-add-a....

Finally, there are occasionally native ARM libs included in the jar - You can get these with tool "retdec" or just run strings on it to find interesting stuff

I use frida https://frida.re/ along with android-x86 VM. Worked well for every app I tried so far