The free, open-source Android tool routes traffic through Android’s local VPN interface rather than a remote server, then maps connections to the app responsible for them. That makes it useful for a quick audit of a newly installed app without rooting a phone or tablet. It also makes PCAPdroid a practical companion to Windows tools such as Wireshark, since captures can be exported for desktop analysis.
But the MakeUseOf experiment also demonstrates the limit readers should keep in mind before drawing conclusions from a long domain list. A connection is evidence of communication, not evidence of misconduct. Analytics, crash reporting, fraud prevention, content delivery, push notifications, certificate checks, ad delivery, and legitimate first-party infrastructure can all appear as third-party hostnames.
PCAPdroid exposes traffic Android normally hides
PCAPdroid uses Android’s VpnService mechanism to receive traffic locally on the device, without sending it through a vendor-operated VPN endpoint. The project’s documentation says it can associate network flows with user and system apps, identify DNS names, TLS server names, IP addresses and some HTTP information, and write packet captures for later inspection.
That approach solves a real problem for Android users. An app’s Play Store privacy label, permission request, or settings page may tell a user that an app accesses location, contacts, or storage, but none of those screens shows the network destinations the app contacts after installation. A connection monitor can identify whether a game is calling ad-tech services, whether a finance app reaches a crash-reporting platform, or whether an unfamiliar utility immediately starts talking to dozens of external hosts.
The MakeUseOf author describes PCAPdroid as the closest Android analogue they found to Portmaster, the Windows and Linux network monitor. The comparison is directionally fair, but the products answer different questions. Portmaster is built around network policy, filtering, and contextual presentation, while PCAPdroid is closer to a packet-capture and connection-inspection tool. PCAPdroid can expose the raw activity; deciding whether it is expected requires investigation.
For Windows users, that distinction should feel familiar. Wireshark can show a destination and protocol with extraordinary detail, but it does not automatically turn an IP address or a TLS hostname into a verdict. PCAPdroid puts a stripped-down version of that investigative workflow on Android.
The OPay results are a useful warning against overreading logs
The author’s OPay banking-app capture recorded 61 connections across 20 domains, including opayweb.com services alongside AppsFlyer, Datadog, Google’s app-measurement infrastructure, Meta’s Graph API, and Akamai’s IP-checking service. On its face, that is more external infrastructure than many customers would expect from a banking app.
Yet MakeUseOf correctly stops short of alleging wrongdoing. AppsFlyer is commonly used for mobile attribution, Datadog is widely used for application monitoring and telemetry, and Google and Meta endpoints can support analytics, authentication flows, marketing measurement, embedded web content, or anti-fraud operations. An IP lookup endpoint can be part of geolocation, abuse prevention, diagnostics, or basic network handling.
The bigger finding is not that OPay’s traffic proves the app is unsafe. It is that the app’s visible banking function does not tell users which outside services are involved in operating, measuring, and monitoring the software. For a finance app, that may warrant a closer look at its privacy policy, data-sharing disclosures, and the exact behavior that triggers those requests.
A better audit would capture the app in controlled stages: first launch, sign-in, balance view, transfer flow, card-management screen, and idle background state. If an analytics or advertising endpoint appears only after opening a promotion page, that tells a different story than the same endpoint connecting during login or while the app is idle. PCAPdroid’s app filter and exported captures make that kind of test possible, but the MakeUseOf account did not establish which user action corresponded to each OPay connection.
A child-focused game deserves closer scrutiny, but the domain list is incomplete evidence
The sharpest observation in the MakeUseOf report came from a Monster High game played by the author’s niece. PCAPdroid reportedly logged 375 connections within a few minutes, including domains and infrastructure associated with Pangle, AppLovin, DoubleClick, Moloco, Firebase Crashlytics, Chartboost, InMobi, TikTok-related services, and Alibaba Cloud.
That pattern is consistent with a mobile game carrying a substantial advertising, measurement, crash-reporting, and content-delivery stack. It is also precisely the kind of result that should cause a parent or administrator to investigate further before approving the app for a child’s device.
Still, the reporting leaves out facts needed to assess the result rigorously: the exact package name, game version, device Android version, region, account status, whether consent dialogs were accepted, and whether the game was marked as child-directed in Google Play. “Monster High” is not specific enough to identify a single Android title or confirm which SDKs were actively collecting data rather than merely being contacted for configuration, ad inventory, or content delivery.
That missing information matters because ad-tech traffic is not uniform. A connection to an SDK domain does not show whether it transmitted an advertising identifier, an IP address, a precise location, a hashed account value, an event log, or no personally identifying data at all. It also does not establish whether the traffic was sent before or after a consent choice.
The practical conclusion remains sound: parents should treat unusually broad ad-tech traffic as a reason to review an app, not as a final technical finding. If a game offers little value beyond a licensed character and casual play, a large stack of advertising and measurement partners may be enough reason to remove it even before a deeper investigation.
Chrome’s 4,930 connections illustrate the attribution problem
Chrome generated the largest result in MakeUseOf’s test: 4,930 connections across 543 domains. That figure initially made the browser appear to be the most aggressive app on the tablet, until the author traced many of those destinations back to websites they had visited and the advertising, analytics, and third-party services embedded in those pages.
This is the central analytical correction users need when inspecting mobile traffic. PCAPdroid identifies the Android process that opened the connection. When Chrome loads a news site with advertising exchanges, a video embed, a customer-data platform, analytics tags, a web font host, and a CDN, the capture assigns those connections to Chrome. It does not mean Chrome independently decided to contact every one of those companies.
The same principle applies to Android apps containing web views. A retail app, airline app, or banking app may embed a web page whose scripts call external services. The connection log attributes the network request to the enclosing app, but the underlying source may be a third-party page, payment form, help center, advertising tag, or content-management system.
That is why domain counts are weak as a standalone privacy score. A more useful measure is behavior: which requests occur while the app is idle, which occur before consent, which appear only after a specific feature is used, whether they can be disabled, and whether they match the app’s disclosures.
HTTPS decryption is deliberately difficult — and QUIC adds another blind spot
MakeUseOf also ran into the technical boundary that separates network visibility from payload inspection. The author installed PCAPdroid’s MITM add-on and certificate, obtained limited “Decrypted” results, then found that many connections failed certificate validation or remained unavailable. PCAPdroid’s documentation warns that many apps will not trust a user-installed certificate and that successful TLS decryption often requires a rooted device or other specialized setup.
That is an expected security property, not merely a shortcoming of PCAPdroid. Financial apps, password managers, messaging clients, and other security-sensitive software may use certificate pinning or their own trust stores specifically to reject interception proxies. If a banking app accepted a casual man-in-the-middle certificate without protection, that would be more concerning than a failure to decrypt it.
QUIC is another limitation. The protocol is widely used for HTTP/3 traffic, including services in Google’s orbit, and PCAPdroid identifies QUIC as unsupported for its regular decryption path. The tool can still expose useful metadata such as the app, destination, volume, and connection timing, but it will not necessarily show the URLs or contents carried inside encrypted QUIC sessions.
Users should therefore avoid treating an unreadable payload as either harmless or suspicious. It means only that the connection was encrypted beyond what the configuration could inspect.
PCAPdroid also comes with operational trade-offs. It occupies Android’s active VPN slot, which can conflict with a work VPN, a privacy VPN, or another local-VPN filtering application. Its own documentation notes that some traffic conditions and settings can affect connectivity, and the MakeUseOf author reported stalled browsing, offline media apps, delayed notifications, and lost captures when Android killed the process during memory-only “No dump” sessions.
For any capture meant to inform a real decision, save to a PCAP file instead of relying on in-memory data. Then move the file to a Windows PC and examine it in Wireshark if the domain names or timing raise questions. Capture one app at a time, record what you did during the test, and compare an idle session with a session where you actively use the app.
That workflow turns PCAPdroid from a source of alarming numbers into something more valuable: a repeatable way to ask whether an Android app’s network behavior matches the job users installed it to do.