Lens: Give Your Entire Team X-Ray Vision Into Your Android App

Lens lets your team see what is happening inside a running mobile app—from a normal web browser.

You Know This Bug, Right?

It is Friday afternoon. QA tells you that the profile screen is blank after login.

You open the same app, follow the same steps, and everything works. The app does not crash. System logs do not show anything useful. The ticket only says, “It happens every time on my device.”

So you start asking questions. Did the API fail? Was an old login token still saved? Was some data missing from the local data store? Was a feature flag different on the QA device?

Mobile platforms give us many good tools, such as system logs, database inspectors, file explorers, and network interceptors. But the information is spread across different places. QA can see the problem but cannot see what caused it. A developer can inspect the app, but may not have the exact data that caused the bug.

Sometimes fixing the bug is easy. Finding the right context is the hard part.

What Is Lens?

Lens is a small web server that runs inside the debug version of your mobile app. It uses a lightweight networking engine and listens on a custom connection port by default.

Connect your phone or simulator, establish a connection bridge, and open Lens in your browser:

That is it. You now have a web page that can show your app’s network calls, local data stores, key-value settings, feature flags, events, files, and debugging sessions.

You can also open Lens over local Wi-Fi. Wi-Fi access is protected by a PIN. A connection through a direct bridge and localhost is trusted automatically.

Let’s Debug That Profile Screen

Let us go back to the blank profile screen. With Lens, you can follow the bug step by step:

1. Find the profile API call.
2. Check its status code, headers, response, and time.
3. Look at the login values saved on the device.
4. Check the profile data in the local data base.
5. See which feature flags were enabled.
6. Use a mock response to make the problem happen again.
7. Review the session to see what happened before the blank screen appeared.

You do not need to jump between many tools and guess what changed. The important information is available in one place.

See the Real Network Response

Lens has a network browser that can read captured transactions. You can search by URL or host, filter by request type or status code, and open any request to see its full details.

Instead of saying, “The profile did not load,” QA can say, “The profile API returned 500, and this was the response.” That gives both Android and backend developers something useful to work with.

Look at the Data Saved on the Device

Not every bug comes from the latest API call. Sometimes an old app version left bad data behind. A migration may have stopped halfway. A user may have taken an unusual path through onboarding.

Lens lets you view and edit key-value settings, inspect data stores, browse local tables, run custom queries, and export data.

Without Lens, you may need to pull files from the device, open another tool, change the data, and push the files back. With Lens, you can inspect and change the state while the app is running.

Change Feature Flags Without Rebuilding

Two test devices can behave differently because one feature flag is not the same. Lens lets you search for registered flags and change them from the browser.

You can move between old and new app flows without building and installing the binary again. QA can also show which flags were active when the bug happened.

Test API Problems Without Waiting for the Backend

Some screens are hard to test. Maybe you need an empty response, a server error, or a field that is missing. The real backend may not give you that response when you need it.

Lens has a network mock interceptor. You create a rule for a request, add the response you want, and turn the rule on or off from the browser.

You do not need to change app code, ask for a special account, or wait for someone to change the backend.

Record What Happened Around the Bug

A normal screen recording only shows what appeared on the screen. It does not show why it happened.

With Lens, QA can start a debugging session before trying the steps. Lens can take screenshots when the user touches the app. It can also connect network calls and important state changes to the same timeline.

When a developer opens the session, they can see what the user touched, which request happened next, whether local data changed, and what the screen looked like at that moment.

Instead of asking, “Can you reproduce it again while we are on a call?”, the developer can start with the information captured during the first failure.

Lens Works With the Tools You Already Use

Lens is not trying to replace your integrated development environment (IDE) or your own debug tools. It gives those tools one shared home in the browser.

The flow is simple:

1. Your app has the data: local data stores, key-value settings, network calls, flags, events, and files.
2. Lens reads that data: its services expose the debugging features you choose.
3. The built-in server shares it: Ktor serves the Lens pages from the debug app.
4. Your team opens it: use the browser or command-line tools through a connection bridge or Wi-Fi.

You can also add tools made for your own app, such as deep links, analytics events, crash logs, cache controls, screen capture, debug exports, or internal settings.

What Changes for the Team?

Before Lens

QA reports what they saw. A developer tries to reproduce it, asks for logs, connects the device, and checks several tools. By then, the original state may be gone.

With Lens

QA records the issue. The failed request, saved data, flags, and user actions are available together. A developer can also mock the response and repeat the bug.

Lens does not fix the bug for you. It removes a lot of the waiting and guessing that happens before real debugging can begin

Keep Lens in Debug Builds

Lens can read and change data inside your app. That is powerful, so it should only be included in debug or internal test builds.

Use a secure connection bridge when possible. Protect Wi-Fi access with a PIN. Use a trusted network. Check which app features you expose, and hide tokens or personal data in anything you share.

We Are Open-Sourcing Lens

We believe debugging should not be limited to the developer who has a development environment open. That is why we are open-sourcing the core Lens platform.

Lens includes database and preference tools, network browsing, API mocking, feature flags, session recording, screen capture, debug exports, a browser interface, a command-line interface, and a system for adding your own features.

We hope mobile teams will connect Lens to their own tools, add new ideas, and help make app debugging easier for everyone.

Spend Less Time Recreating the Bug

Mobile developers should not spend half of an investigation trying to rebuild the state in which a bug happened. QA should not need a full development environment to share useful details. Backend developers should not have to guess what the app received.

Lens gives everyone the same view of the requests the app made, the data it saved, the settings it used, and the actions that led to the problem.

Lens helps your whole team see the same debugging story—and start fixing the real problem sooner.