httptoolkit-android is the phone side of an HTTP proxy

A companion app, not a proxy

The most important thing to understand about this repository is that it is not the proxy. HTTP Toolkit is primarily a desktop application, and this repository contains the Android app which connects to that desktop application and forwards HTTP traffic there. Everything the app does is in service of that forwarding. That framing changes what you should expect to find in the code, because there is no request parsing, no rule engine and no mock server here. Those live in the desktop application. What lives here is the plumbing that gets the device's traffic out of the phone and onto the desktop, and the interface that lets you start and stop it. The project description puts the purpose plainly, automatic Android interception and debugging with HTTP Toolkit, for inspection, debugging and mocking, and the topics reflect a developer tool rather than a consumer app, with android-debug, android-development and android-tools among the tags. The licence is AGPL-3.0 and the last push was on 2026-09-03, with releases v1.7.0 on 2026-08-27, v1.6.0 in November 2025 and v1.5.1 in February 2025.

The app is two parts, and the split is architectural

The README describes the Android app as effectively two parts, and this is the single most useful piece of information for anyone reading the source. The outer wrapper shows the UI, scans QR codes, retrieves proxy configuration from HTTP Toolkit, ensures the device trusts HTTP Toolkit's CA certificate, and starts and stops a VPN. The VPN is the second part, and it receives every IP packet sent by the device, parses them, rewrites some of them to go to HTTP Toolkit, and then sends the parsed requests on via the real network, forwarding responses back. Each of those responsibilities sits on one side of the boundary for a reason. The wrapper is the part with the user interface and the system permissions, so it is where the QR scan, the certificate trust flow and the VPN lifecycle live. The VPN is the part that has to be fast and low level, so it is the part that deals with raw packets. The fact that the rewriting is selective is worth pausing on, since the alternative, tunnelling everything through the desktop machine, would put the whole device's traffic on the link for no reason when you only care about HTTP.

Certificate trust is the step that decides whether anything works

Among the wrapper's responsibilities, the one that most often decides whether a session produces any output is making the device trust HTTP Toolkit's CA certificate. Android will not let an application silently trust an arbitrary certificate authority, so an interception tool has to be installed into the system trust store and the user has to confirm it, and the wrapper handles that flow rather than asking the user to do it by hand. The same list also contains the step that gets the desktop application configured on the device, which is the retrieval of proxy configuration, and the QR code scan, which is how the device and the desktop machine find each other. Those three things together, the scan, the configuration and the trust, are what a user actually sees when they set this up, and everything else happens underneath. It is worth knowing that this is all handled inside the app, because the alternative for a developer is a sequence of manual steps through Android settings that has to be repeated on every new device or every OS update that resets the trust store.

A rooted device helps, but is not required

The contributing section is short and it answers the question most people arrive with, which is whether testing needs a rooted phone. It does not. A rooted device isn't required for testing, but the README says you will find that it helps, as you can test with a wider variety of real app traffic. The reason is not that the app needs root to function, since the VPN approach works without it, but that the traffic available on an unrooted device is narrower. Apps that use certificate pinning will refuse to talk to an interception proxy on a stock device, and apps that ship their own certificate store or that communicate over raw sockets rather than HTTP will produce nothing to see. Root, or an instrumented build of the application under test, widens the range of traffic you can observe, which is exactly what you need when you are trying to work out why a particular request is not appearing. The practical consequence is that a debugging session that shows nothing may be telling you about the app under test rather than about the tooling.

Kotlin for the interface, Java for the packet layer

The build note is unusual and useful. The app is half in Kotlin, described as the outer wrapper, and half in Java, described as most of the VPN code. That split follows the architecture exactly: the UI layer is modern Android work and Kotlin is the natural choice, while the VPN interception code predates that split and stays in Java, which is common for code that deals with low level networking and has to interoperate with platform APIs. The repository layout is the standard Gradle Android project, with an app/ module, build.gradle.kts, settings.gradle.kts, gradle.properties, the gradle/ directory and the gradlew and gradlew.bat wrapper scripts, plus a .idea/ directory for IntelliJ settings and a store-listing/ directory that holds the Play Store listing files. The store-listing directory is a reminder that this ships as a real app that people install, not as a developer tool you sideload, and the AGPL licence and the store listing together are worth a look before you decide how to use it in a commercial setting.

Knowing which repository to change

The contributing section draws a boundary that saves people a lot of time. If you are looking to contribute to the Android app itself, you are in the right place, and if you are looking to explore or change how the ADB-based Android setup works, you want to take a look at the HTTP Toolkit server project instead, which is the separate httptoolkit-server repository. That distinction is not obvious from the outside, because both the ADB route and the VPN route are ways of getting HTTP traffic out of an Android device, and the app supports the VPN route while the server project covers the ADB setup. So a bug in how a device connects to the desktop application, or a question about how the connection is established over ADB, belongs in the other repository. The feedback channel is also stated separately, with issues and votes going to the httptoolkit/feedback repository rather than to this one, which is a common pattern for a single issue tracker shared across a family of components.

Editorial conclusion

Adopt httptoolkit-android when you are debugging the HTTP behaviour of an Android app and want to see, edit and mock its requests without setting up a proxy by hand, and you already have the HTTP Toolkit desktop application or can run the other components locally. Do not adopt it as a standalone tool, since the repository contains no interception logic of its own beyond the packet handling, and the desktop application and the server side are separate repositories. Verify first which of the two parts you actually need to change, since the README points ADB based setup work at the httptoolkit-server project, and confirm that your device and Android version work with the VPN based approach before you rebuild anything.

Frequently asked questions

Official sources

1. httptoolkit/httptoolkit-android on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases