How the web layer is packaged and loaded
Cordova copies the web application into the APK under a www directory inside assets. The shell activity creates a WebView and loads the entry page from that directory, usually through a file URL. Plugins are declared in an XML configuration file under the resource directory, and their Java classes sit under the Cordova package names.
Capacitor copies the build output of the web project into the Android assets directory, commonly under a public folder, and the runtime serves those files to a WebView through a local server. A configuration file in the web project names the web directory, the scheme and hostname the WebView uses, and, when live reload or remote deployment is configured, a server address on the network.
The configuration file is worth reading first. It states whether the app loads files from the device or from a remote origin, and it lists plugins by name. A remote origin changes where the traffic starts and which cookies apply, which is the difference between a capture that shows the API calls and one that shows a page load.
Where the JavaScript bundle lives
The bundle is minified and often split into chunks. Look under the assets directory for JavaScript files, a manifest that lists the chunks, and any source map that shipped with the build. A source map restores the original module paths and function names, and when it is absent the minified names still sit next to the string constants.
Strings survive in the bundle, including host names, path segments, header names, keys that the build inlined, and parameter names. Search the bundle text directly for a scheme and for known path fragments. Environment files from the web project are compiled into the bundle, so a base URL configured for a staging build can appear as a literal.
The plugin registry is a second index. Cordova names its plugins in the configuration and Capacitor lists them in a generated file, so the set of native capabilities is readable before you open any plugin code. That list tells you how much of the app can reach the network outside the page.
Which calls go through the native bridge rather than the network stack
A bridge call never becomes an HTTP request in the WebView. Cordova reaches native code through its exec function, which passes a service name, an action, arguments and callbacks across a JavaScript interface object. Capacitor sends a message with a plugin identifier, a method name, options and a callback identifier, and the runtime dispatches it to the matching plugin. Both paths travel through a message channel rather than a socket, so a capture of the WebView shows nothing for them.
Some plugin methods then make a request in native code. The Capacitor HTTP plugin is the clear example: when the application enables it, the runtime replaces the page fetch and XMLHttpRequest functions and performs the transfer through the native HTTP stack. A request of that kind carries the application client stack and uses native certificate handling, so it differs from a request the page sends by itself.
- Plugins that touch hardware, files, camera, geolocation or secure storage produce no HTTP traffic at all, because their data comes from the device.
- Plugins that wrap a vendor service call that vendor directly from the device, so the destination differs from the application backend.
- Plugins that receive a request from the page, sign it and return one header to the page leave the actual transfer in the WebView.
Telling a bridged call from an HTTP call
The user agent identifies the sender in most captures. A request from a WebView carries a WebView user agent string, while a request from a native client carries the application client identifier or a library default. Cookies differ as well, because the WebView keeps its own cookie store.
Bridge traffic is visible in other places. Both runtimes write to the device log, so plugin dispatch, method names and plugin errors appear there while a network capture stays silent. With WebView debugging enabled, the page console shows the JavaScript side of the same call. When a call appears in the log and returns a result with no matching request in the capture, it went through the bridge.
Signing in a hybrid app usually sits in the bundle, where the page computes a hash or a token, or in a native plugin that returns a signature to the page. Either way the material that feeds the signature is a string in the bundle or an argument in the bridge message, and that is where reconstruction starts. Work on a packaged web layer is a form of Android API interoperability, and the same recovery applies when the shell mixes the page with native modules. The delivered result is described under APK to API.
Related work
Reviewed 28 September 2026 · SReverse research desk