Network Inspector — What It Is, How It Works, and Monitoring Network Requests

What is Network Inspector?

Network Inspector is a network activity profiling tool built into Android Studio. It allows developers to view in real time all HTTP and HTTPS requests sent by the application, including headers, request and response body, status codes, and execution duration. It is available through the Android Profiler panel starting from Android Studio 3.0.

Purpose and Scope

The main task of Network Inspector is debugging network communication between the mobile application and the server. The tool is used to verify the correctness of transmitted data, analyze response time, search for API errors, and detect non-optimal network patterns — for example, multiple requests when loading a single screen. Network Inspector works on any device with API Level 14.

Compatibility and Libraries

The tool supports all major Android HTTP clients: OkHttp (starting from version 2.x), Retrofit, Ktor (KMM), UrlConnection, Apache HttpClient (legacy), and WebView. For OkHttp and Retrofit, the OkHttp Profiler library is required — it is connected automatically when using Android Studio 4.1+. For Ktor, a separate interceptor configuration is necessary.

How Network Inspector Works

Network Inspector intercepts network calls at the system level using the Profiler Agent mechanism, which is injected together with Android Profiler. A debug build of the application is required for proper operation. The tool does not modify the application code and does not require adding dependencies for basic functionality.

Traffic Interception Mechanism

When profiling starts, Network Inspector connects to the Debug process of the application and listens to all HTTP calls passing through OkHttp Client, UrlConnection, or other supported libraries. Each request is recorded with a timestamp, allowing the construction of a network activity timeline. For HTTPS, a system layer is used, which preserves encryption during transmission but allows viewing decoded content inside Studio.

Data Collection Architecture

Data collection occurs through the Profiler Service of Android Studio, which runs in a separate host process. A lightweight agent runs on the device, transmitting request metadata via the ADB channel. This minimizes the impact on application performance — overhead is less than 3% according to Google. Request data (body, headers) is transmitted only when viewing details is active.

// Connecting OkHttp for integration with Network Inspector
val client = OkHttpClient.Builder()
    .addInterceptor(HttpLoggingInterceptor().apply {
        level = HttpLoggingInterceptor.Level.BASIC
    })
    .build()

// Network Inspector automatically intercepts all calls through the client
client.newCall(Request.Builder()
    .url("https://api.example.com/data")
    .build()).execute()

Key Features of Network Inspector

Network Inspector provides a set of tools for comprehensive network traffic analysis. Each feature is aimed at solving a specific debugging task — from checking headers to analyzing API performance.

Request Timeline

The main Network Inspector screen displays a chronology of all requests as a timeline. Each request is represented by a colored bar: green — successful response (2xx), blue — redirect (3xx), yellow — client error (4xx), red — server error (5xx). The bar length corresponds to the request execution time from connection to receiving the full response. This allows instantly identifying slow or failed requests.

Detailed Request View

When selecting a specific request, a details panel opens with: Headers (all request and response headers), Request Body (request body in text or binary format), Response Body (response body with JSON formatting support), Cookies (sent and received), Timing (time breakdown by phases: DNS, Connection, TLS Handshake, Request, Response).

Filtering and Search

Network Inspector supports request filtering by URL, HTTP method, status code, and content type. Requests to specific domains can be excluded to focus only on the desired API. Search works across all request fields, including body and headers, which is convenient when debugging a specific application function. Combined filters allow creating a set of rules that automatically apply each time profiling starts.

Grouping and Comparing Requests

The timeline supports grouping requests by URL patterns. For example, all requests matching /api/v2/users/* can be collapsed into one group. This simplifies analysis when the application makes hundreds of requests in a short period. The adjacent request comparison feature helps identify changes in server responses on repeated calls.

Debugging Network Requests with Network Inspector

Practical use of Network Inspector covers typical debugging scenarios: checking data format, identifying slow endpoints, detecting memory leaks due to unclosed connections, and analyzing caching.

Checking JSON Response Structure

A common task is to verify that the server returns data in the expected format. Network Inspector shows the response body with JSON formatting, including syntax highlighting. If the response does not parse on the client, the inspector immediately shows the reason: missing field, incorrect data type (string instead of number), or excessive nesting. If the server returns an error, the inspector shows the error structure with code and message. For binary formats (Protocol Buffers, images), size and content-type are displayed.

Execution Time Analysis

The Timing tab breaks down request execution into phases: DNS Resolution, TCP Connection, TLS Handshake, Request Send, Response Receive. If the total time exceeds 1–2 seconds, the phase breakdown helps identify the cause. For example, slow DNS indicates resolver issues, slow TLS Handshake indicates an outdated protocol version on the server, slow Response indicates slow server code or an inefficient query with excessive data. Timing analysis helps identify bottlenecks even before server-side optimization begins.

Finding Duplicate Requests

Network Inspector helps identify redundant requests — for example, when each screen rotation causes the Activity to reload data. On the timeline, a series of identical consecutive requests clearly indicates the problem. The solution may include caching, using ViewModel with state preservation, or SingleLiveEvent for one-time loading.

// Caching requests with OkHttp to eliminate duplication
val cache = Cache(
    File(context.cacheDir, "http_cache"),
    cacheSize = 10L * 1024 * 1024 // 10 MB
)

val cachedClient = OkHttpClient.Builder()
    .cache(cache)
    .addNetworkInterceptor(CacheInterceptor())
    .build()

Network Inspector Limitations and Alternatives

Despite its extensive capabilities, Network Inspector has a number of limitations that are important to consider. For some scenarios — such as intercepting HTTPS with self-signed certificates or analyzing third-party library traffic — alternative tools may be required.

Platform and Library Limitations

Network Inspector works only with Android applications and does not support iOS. For Kotlin Multiplatform (KMM), some requests may not be displayed if they are executed in the native part. Some libraries — for example, gRPC, WebSocket (non-HTTP), GraphQL via Apollo (before version 3.x) — may be partially intercepted or not intercepted at all without configuring additional interceptors.

Alternative Tools

For deeper network traffic analysis, there are third-party solutions: Charles Proxy (full-featured proxy server with HTTPS interception), Proxyman (macOS alternative), Wireshark (packet-level analysis), Stetho by Facebook (integration with Chrome DevTools), Chucker (in-app request inspection library). Each tool has its niche: Charles and Proxyman are indispensable when debugging server interaction in early development stages, while Chucker is useful for collecting information in test builds.