I've had some years of experience with hacking round in mobile environments, here's some of the methods and notes that may help you in getting up-to speed and keeping your own hardware a bit safer while performing your investigation.
For general threat modal and network sniffing ya may wish to check my answer posted to the question of detecting if a phone is secretly sending data noise will have to be sifted though though if the target device isn't compatible with non-root firewall options suggested there and be sure to pay attention to referenced malware jumping from Android to USB connected PC before attempting USB connected forensics. Another option I don't think I listed there was that DNS look-up monitoring/poisoning may help in sorting legit apps' traffic from non-legit traffic.
Small warning, while I've not seen it in the wild it's very possible that the infected device could attempt to attack the Wi-Fi networks it comes across, so consider making a VAP (Virtual Access Point) to separate the network of the infected device from anything else while performing MiTM investigations. Metasploit and others aren't too difficult to install on Android so be very cautious of that infected device sneezing on others.
Now because you've stated that network traffic is noisy and you'll likely end up plugging it in to a USB for imaging it would behoove you to consider either USBguard or disabling HID entirely and use ssh to interact with your forensic device. However, because malware keeps getting smarter it would be a good idea to only use a cheaply replaceable device for USB based forensics; hint web search "system on a chip" and narrow the available options to boards with x86 CPU architecture to have an easier time loading ADB (Android Debug Bridge) drivers and maintaining a solid connection for imaging the file system.
Note once you've sufficiently secured the device that'll be connecting to the possibly infected device the best thing to keep in mind is that
pull commands with ADB are just as forgiving as in-file and out-file command line options used with
dd, which is to say not very forgiving, so be careful.
Side note, Tripwire and similar file system tools can be very helpful for finding cross platform malware, but that and others would need setup prior to plugging in the infected device... only really applicable if your threat modal is sufficient to require forensic inspection of the device preforming forensics operations on the possibly infected device, and this also stats the line of questioning if the watcher is watching the watcher watching the watched in a trustworthy way... and if we go down that line of thought I'll hit the character limits for posting answers again.
Next up is emulating the imaged device, there's a few options but the AVD (Android Virtual Device) manager that comes with Androids' SDK (Software Development Kit) should be sufficient for this task. Make a backup of the possibly infected device, load a AVD to simulate the target's hardware and restore the backup to the emulated device's file system, then go to town on dissecting memory or setting breakpoints or even attempt to penetrate the emulated device in order to find egress points used by the original malware... it maybe possible to root the emulated device too to test if possible malware has been waiting for that before taking actions... oh and be sure to unplug/unmount and remove power from the physical device that maybe infected once you've loaded it's backup into the emulated environment. So long as you're working on an emulated version of the infected device your actions won't break anything for the client so get as rough with the emulated device as you like, however, if you've the space make a backup of the backup so that bricking the emulated device doesn't require re-plugging in the possibly infected device.