The four layers, in order
Monitoring app traffic is a stack of four checks, and each one hides the layer below it. Traffic has to reach a capture point, TLS has to terminate there, the request has to be readable, and the fields have to be traceable back to code. Working in that order prevents the common mistake of reading a capture that never held the call you care about.
- Routing decides whether the app reaches the capture point. Send the device traffic through a capture point. A proxy configured on the device covers most HTTP and HTTPS traffic. An app that ignores the proxy needs a capture point on the device itself, such as a local VPN service.
- TLS termination makes the request readable. Install a certificate authority the app will trust. When the app refuses the certificate, the connection fails before any request is readable.
- The request itself carries the detail. Group what arrived by host, then read the path, the method, the headers and the body.
- The code explains where the values came from. Read the decompiled client to learn how the values in the request were produced.
Confirm the app uses the capture point
An empty capture has two explanations, and they are different problems. Either the app never reached the capture point, or it reached it and the handshake failed. Check the connection log rather than the request list. A TCP connection that appears and then closes points at TLS, while no connection at all points at routing. An app that uses a UDP transport such as QUIC can bypass an HTTP proxy entirely, and it falls back to TCP only when the UDP path fails. A capture point that runs on the device removes both of those variables at once.
Make TLS terminate
Install the certificate authority where the app will look for it. The platform on current Android releases does not trust a user-installed certificate for application traffic unless the app opts in through its network security configuration, which is why a browser can work while the app does not. When the certificate is trusted and the app still refuses, the app is checking the server certificate or public key itself. A pinning check fails the handshake by design, so the capture stays empty. Working around that check is described in intercepting pinned traffic and Android certificate pinning traffic analysis.
Read what arrived
Once TLS terminates, the capture becomes useful. Group requests by host and separate the API host from media, analytics and advertising hosts. Read the call that returns the access token first, because the requests after it depend on that value. Note the content type on each request and whether the body is text or binary, since a binary body tells you that a routine produced the payload rather than a form builder.
A proxy is not the only capture method, and it is not always the right one. A capture point on the device sees every connection the app opens, including the ones that never consult the proxy setting and the ones that use a transport the proxy does not carry. It also records the connection failures, which a proxy reports only when the app chose to send traffic to it. Starting on the device and moving to a proxy when the TLS work is easier there is a reasonable order.
Trace the values back to code
A capture shows a request at one moment with values the app computed a moment earlier. Reproducing the call means reproducing those values, and that work happens in the decompiled code. Find the client construction, then the method that builds each request, then the routine that produces any value you cannot explain. Instrumentation helps when a value genuinely depends on run time state, such as a device identifier or a key that is unpacked during startup. Observation with Frida covers that approach.
Keep the capture usable
- Start the capture before the app launches so that the authentication calls appear.
- Perform one user flow at a time and mark the boundary in an exported session.
- Record the device time, because timestamps in signed requests are compared against it.
- Keep the raw session rather than screenshots, so a request can be replayed or compared later.
A capture is evidence rather than a client. Turning it into a callable integration means reproducing the state and the computed values, which is the work described at undocumented API reverse engineering.
Related work
Reviewed 28 September 2026 · SReverse research desk