AndroidHttpCapture: On-Device HTTP/HTTPS Capture for Android

What AndroidHttpCapture Is For

AndroidHttpCapture is an Android application that records the HTTP traffic passing through its own WebView, and optionally the HTTP traffic of other apps when the phone's proxy is pointed at it. The README describes it as a mobile version of Fiddler, and the feature list backs that up: request and response headers, cookies and bodies, JSON pretty printing, URL search, pagination, and a share action that packages everything into a HAR file inside a ZIP.

The audience is narrow and specific. It is for Android developers and QA engineers who debug hybrid apps, mobile web pages or backend environment switches, and who want the capture to happen on the device rather than through a desktop proxy. The environment switching feature (normal browser, WeChat, QQ) and the host configuration feature both point at the same workflow: reproducing what a page does when it is opened inside a particular app shell or against a particular backend.

It is not a passive network monitor. Nothing in the README suggests it observes traffic without being in the path. Capture happens either because a page was opened inside the app, or because the phone's proxy setting sends traffic to 127.0.0.1:8888. That distinction matters when you evaluate it against tools that hook the network stack instead.

How the Capture Pipeline Works

The implementation section names the two foundations: Netty and browsermob-proxy. Netty provides the asynchronous network framework, and browsermob-proxy supplies the proxy behaviour. The README states that several parts of browsermob-proxy were modified for Android compatibility, and that part of Netty's certificate implementation was reverse-modified because Android 5.0 and later do not support certificates with the JKS provider. The result is shipped as netty_android.jar.

HTTPS capture follows the same model as Fiddler: a man-in-the-middle proxy. The app presents its own certificate to the client, which is why a CA certificate must be installed before HTTPS requests can be captured. The certificate lives at /har/littleproxy-mitm.pem, and on newer Android versions the app may not be able to open the installation screen automatically, so the README gives the manual path: Settings -> Security & Lock Screen -> Encryption & Credentials -> Install Certificate.

Response injection sits on top of that pipeline. The README is explicit that this version only supports HTTP response modification, which is a real constraint: you can rewrite a plain HTTP response body, but not an HTTPS one. The known issues list also records that when response injection is enabled, some HTTPS pages hit ERR_CONTENT_LENGTH_MISMATCH, and adds that the problem appears to have been improved but needs more user feedback. Treat that as unresolved rather than fixed.

The other known issue is more serious for anyone using this outside a lab: the app currently trusts all server certificates without validation. That is a deliberate convenience for interception, and it means the app cannot tell you whether the certificate a server presented was legitimate.

Installing the App and Making a First Capture

The repository does not publish a demo APK. The README's download section is a placeholder that reads "Please add your APK download link here." The build files are present (build.gradle, settings.gradle, gradle-wrapper.properties, app/), so the practical route is to build from source with the Gradle wrapper. The README gives no build command and no minimum SDK, so treat the wrapper invocation below as the standard Gradle entry point rather than a documented step.

git clone https://github.com/JZ-Darkal/AndroidHttpCapture.git
cd AndroidHttpCapture
./gradlew assembleDebug

The output APK lands under app/build/outputs/apk/debug/. Install it on a device or emulator, then start the app.

Before capturing anything, the README's first instruction is to disable the phone's existing HTTP proxy settings. Then install the CA certificate so HTTPS traffic can be decrypted. On Android versions where the app cannot open the installer, use the manual path shown in the README:

Settings -> Security & Lock Screen -> Encryption & Credentials -> Install Certificate

The certificate file is at /har/littleproxy-mitm.pem. Once it is trusted, open a page through the app's address bar or navigation menu and the preview page should begin listing requests, with JSON bodies formatted automatically. The share action produces a ZIP containing a .har file, which the README says can be imported into Fiddler via Import Sessions -> Select Import Format -> HTTPArchive, or dragged into an online HAR viewer at http://static.hk.darkal.cn/har/.

For capturing other apps, set the phone's proxy server to 127.0.0.1:8888. The README's security notice restricts this to apps and traffic you are authorized to inspect.

Schema Launch and Host Overrides in Practice

Two features make the app useful beyond a single manual page load. The first is schema launch, which lets another app or a script open a URL inside AndroidHttpCapture. The README gives the format:

jdhttpmonitor://webview?param={'url'='http://www.darkal.cn'}

That is a real convenience for repeatable test runs, since you can wire it into an automation flow instead of typing URLs. The second is host configuration, which maps specific domains to custom hosts. That is the feature you reach for when a staging backend sits behind a different hostname and you want the production URL in the page to resolve to the test server.

Environment switching complements both. Normal browser, WeChat and QQ are the three simulated environments listed, with normal browser as the default. If you are debugging a page that behaves differently inside WeChat's WebView, this is the switch that reproduces it without asking a colleague to open the link.

The console log viewer rounds out the hybrid app story: console.log output from the WebView page is displayed inside the app, so you do not need a separate remote debugging session just to read logs.

Where AndroidHttpCapture Falls Short

The most consequential limitation is the one buried in Known Issues: the app trusts all server certificates without validation. For a debugging tool that is understandable, since interception requires accepting the proxy's certificate. But it means the app is the wrong instrument if your question is whether a server's certificate chain is valid, or whether an app is pinning certificates correctly. It will happily show you a decrypted stream from a server whose certificate it should have rejected.

The second limitation is response injection scope. Only HTTP responses can be modified. If your test case requires altering an HTTPS response body, this version cannot do it, and the ERR_CONTENT_LENGTH_MISMATCH note suggests the injection path has had stability problems even where it applies.

There is also an operational constraint that the README states plainly: the app is in the path. Traffic is captured because the page was opened inside AndroidHttpCapture or because the system proxy points at 127.0.0.1:8888. Apps that ignore the system proxy, or that use their own networking stack with certificate pinning, will not appear. This is not a packet capture tool at the IP layer, so it will not show you UDP, QUIC or non-HTTP traffic at all.

Finally, the documentation has gaps. The demo APK link, the user guide link and the donation link are all placeholders. Anyone evaluating the project has to read the source to learn the minimum Android version or the upload endpoint behaviour, since the README only says the upload endpoint should be configured manually in MainActivity.

How It Compares to Desktop and On-Device Alternatives

The obvious alternative is a desktop proxy such as Fiddler or Charles, with the phone configured to send traffic to the developer machine. The difference in approach is where the proxy runs. A desktop proxy gives you a mature UI, scripting, breakpoints and HTTPS response rewriting, but it requires the phone and the laptop to be on the same network, a proxy setting the phone accepts, and a firewall that permits the connection. AndroidHttpCapture removes all of that by running the proxy on the phone, which is why the README's system proxy mode is set to 127.0.0.1:8888 rather than a LAN address. The cost is a smaller feature set and a smaller screen.

A second alternative is an Android app that captures at the network layer rather than as an HTTP proxy. Those tools see traffic the proxy approach misses, but they generally cannot decrypt TLS without their own certificate installation, and they do not give you response injection or a HAR export aimed at HTTP analysis. If your problem is "what hosts is this app talking to", a packet-level tool answers it. If your problem is "what did this JSON response contain", AndroidHttpCapture answers it more directly.

A third option is remote debugging through Chrome's WebView inspection. That gives you console logs and DOM state, and the README's own console log viewer overlaps with it. The difference is that remote debugging shows you the page, not the wire. If you need headers, cookies and response bodies in a shareable file, the HAR export is the thing remote debugging does not produce.

Maintenance, Licence and Upgrade Cost

The repository is not archived, and the last push was on 2026-05-07. The most recent release listed is 3.1.30 from 2017-06-02, which added the response modification feature. That gap between the last push and the last release is worth noting: activity in the repository does not necessarily translate into tagged builds you can download, and the README's download section is still a placeholder. If you adopt this, plan to build from source rather than wait for a release artifact.

The project is MIT licensed. The licence text in the README grants permission to use, copy, modify, merge, publish, distribute, sublicense and sell copies, provided the copyright notice and permission notice are included. There is no warranty. That is permissive enough for internal tooling and for modified forks, but the README also notes that parts of Netty and browsermob-proxy were modified for Android compatibility. If you redistribute a build, the notices for those upstream projects are the thing to check with someone qualified to advise on it, since the README does not spell out how their licences interact with the modifications.

Upgrade cost is mostly the certificate. The MITM certificate at /har/littleproxy-mitm.pem is installed into the device trust store, and on Android versions that restrict user-installed CA certificates for app traffic, that installation may not be honoured by the apps you want to inspect. The README already warns that newer Android versions may not open the certificate installation page automatically. Budget time for that step on every new device or emulator image.

Editorial conclusion

Adopt AndroidHttpCapture if you debug your own Android web or hybrid pages and want capture, HAR export and ping or DNS checks without tethering to a desktop proxy. Skip it if you need HTTPS response rewriting, validated certificates, or a tool that can inspect another person's device without their consent. Before relying on it, confirm the CA certificate installs on your Android version, that the app still builds from the repository, and that the upload endpoint in MainActivity points somewhere you control.

Frequently asked questions

Official sources

1. Issues
2. JZ-Darkal/AndroidHttpCapture on GitHub
3. License: MIT
4. README
5. Releases