Testing Android R8 and ProGuard with Claude Code and MCP

Testing Android applications with R8 code shrinking and ProGuard obfuscation on physical devices represents one of the most critical yet frequently bypassed validation stages in mobile software engineering. While debug builds compile rapidly with code shrinking disabled (minifyEnabled = false), production release builds subject every Kotlin and Java bytecode instruction to aggressive tree shaking, identifier minification, class merging, and dead-code stripping. When development teams rely exclusively on debug instrumentation tests and JVM unit tests, catastrophic release-only regressions—such as reflection-based JSON deserialization crashes, stripped Jetpack Compose navigation arguments, and broken native JNI bindings—slip undetected into production app bundles. The Model Context Protocol (MCP) revolutionizes release build verification by linking autonomous coding agents like Claude Code, Cursor, and VS Code directly to physical Android silicon. Equipped with real-time visual display perception, semantic node inspection, and deterministic device control, autonomous agents build, deploy, stress-test, and debug minified release APKs on physical hardware before they reach end users.

Key Takeaways

• Catch release-only regressions early: Testing minified release builds with Claude Code and ScreenSync MCP exposes missing ProGuard rules, broken reflection serializers, and runtime class cast exceptions that never manifest in debug builds.
• Direct hardware perception: ScreenSync MCP delivers sub-100 millisecond visual frame streaming over local Wi-Fi via Android's native MediaProjection API, operating with zero root privileges and bypassing ADB screenshot serialization bottlenecks.
• Deterministic input injection: Claude Code drives user journeys across obfuscated apps using Android Debug Bridge (ADB) over USB or authenticated wireless debugging, executing taps, swipes, and text input without fragile UI element IDs.
• Automated stack trace de-obfuscation: When an obfuscated release APK throws an unhandled exception, Claude Code retrieves the mangled logcat trace, retraces the crash with ProGuard mapping.txt, identifies the stripped class, and updates proguard-rules.pro autonomously.
• Unified cross-surface test coverage: ScreenSync MCP bridges 226 total MCP tools (29 mobile/desktop tools and 197 browser automation tools), enabling Claude Code to validate complex flows transitioning from obfuscated native screens to Chrome Custom Tabs and Stripe payment portals.
• Zero cloud telemetry exposure: Video frames stream strictly between the physical phone and the local desktop hub over your local network, safeguarding proprietary staging data and enterprise test credentials from third-party servers.

Why Testing R8 and ProGuard Minification Breaks in CI and Debug Builds

Testing R8 and ProGuard minification breaks in standard CI pipelines because unit tests execute on the host JVM without dexing, while debug builds disable code shrinking and name obfuscation. Autonomous agents like Claude Code bridge this gap by deploying minified release APKs to physical Android devices, executing realistic user journeys, and verifying that obfuscated bytecodes execute reliably without missing class definitions.

In modern Android development, the compilation pipeline differs fundamentally between debug and release configurations. In debug mode, Android Studio and the Android Gradle Plugin (AGP) prioritize incremental compilation velocity. The D8 dexer translates Java bytecode into Dalvik Executable (DEX) files with code shrinking disabled (isMinifyEnabled = false). Variable names, class hierarchies, interface contracts, generic signatures, and reflection metadata remain fully intact. Consequently, libraries that rely on runtime reflection—such as Moshi, Gson, Jackson, Retrofit, and dependency injection frameworks like Hilt—operate seamlessly even if developer keep rules are completely absent.

The Android Build Compilation Divergence

1. Source Compilation Phase:
   Kotlin and Java source files compile via kotlinc and javac into intermediate JVM bytecode (.class files).
2. Debug Execution Pathway (D8 Dexer):
   Bytecode flows directly into D8 for fast incremental dexing. Tree shaking is disabled, identifier names remain untouched, type metadata is preserved, and an unminified debug.apk is produced.
3. Release Execution Pathway (R8 Full Mode):
   Bytecode flows through R8 with full-mode optimization enabled. R8 performs four aggressive transformations before generating release.apk alongside mapping.txt:
   • Tree Shaking: Traverses the application call graph starting from manifest entry points (Activities, Services, Broadcast Receivers, and Application classes). Any class, method, or field unreachable from these roots is pruned from the DEX file.
   • Optimization: Inlines small methods, removes dead code branches, merges single-implementation interfaces directly into concrete classes, and rewrites field accesses for execution speed.
   • Identifier Minification: Renames packages, classes, methods, and fields into short alphanumeric strings (such as com.example.app.User becoming a.a.a).
   • Resource Shrinking: AGP's resource shrinker strips unreferenced drawables, layouts, and strings not indexed in compiled code.

Because conventional continuous integration pipelines rely on fast JVM unit tests (./gradlew test) to gate pull requests, R8 never runs during standard developer iterations. When teams do configure instrumented tests on CI servers, they frequently run them against debug APKs because compiling minified release builds adds substantial overhead to CI runtimes. Headless cloud emulators exacerbate this blind spot: synthetic virtual devices lack real OEM vendor HALs, display driver idiosyncrasies, and realistic memory limits that trigger edge-case bytecode execution paths. To validate how applications behave under real operating system lifecycle constraints, developers must combine R8 release testing with testing Android process death with Claude Code and MCP on physical hardware.

The Technical Architecture: R8 Shrinking, Dex Optimization, and ScreenSync MCP

The technical architecture of ScreenSync MCP decouples hardware display streaming from deterministic command injection. The physical Android device streams display compositor frames directly to the desktop hub via Android's native MediaProjection API, while Claude Code injects touch and key events over Android Debug Bridge (ADB), providing sub-100ms visual latency without consuming ADB bandwidth.

Validating an obfuscated application requires both high-fidelity visual perception and deep system telemetry. If an AI testing agent were forced to capture device screenshots using standard adb exec-out screencap -p commands, each visual turn would stall for 800 to 2200 milliseconds due to ADB shell pipe serialization overhead. In an interactive testing session where Claude Code must verify animations, screen transitions, and input validation across dozens of screens, this latency penalty makes autonomous verification unfeasible.

ScreenSync MCP eliminates this performance bottleneck through an optimized dual-channel architecture:

Dual-Channel Hardware Communication Model

1. Non-Invasive Video Perception (MediaProjection API):
   The native ScreenSync MCP Android app (package com.screensync.mcp, compatible with Android 7.0 and later) acquires a hardware virtual display via Android's MediaProjection manager. Display frames are encoded directly from the graphics compositor hardware buffer and streamed over your local Wi-Fi network to the desktop hub running on Node.js 18+. In physical LAN environments, this streaming pipeline delivers approximately 94 ms median visual latency. Crucially, MediaProjection requires no root access and does not compete with ADB for USB transfer bandwidth.
2. Deterministic Control & Log Telemetry (ADB Daemon):
   When Claude Code needs to interact with the device, it executes specialized MCP control tools (control_tap, control_swipe, control_type, control_launch_app). The ScreenSync MCP hub translates these JSON-RPC requests into ADB shell commands routed over USB or authenticated wireless debugging. Simultaneously, Claude Code monitors runtime crash logs, unhandled exceptions, and ANR notices using get_logcat.

For teams building complex declarative user interfaces, pairing this architecture with Compose semantics inspection allows agents to navigate dynamic layouts even when underlying class names have been obfuscated. To explore how Claude Code inspects Compose node trees on real devices, review our detailed guide on testing Jetpack Compose apps with Claude Code and MCP.

Catching Release-Only Regressions: Moshi, Compose Navigation, and JNI Failures

Catching release-only regressions requires auditing code paths where R8 strips reflection metadata, type-safe navigation arguments, and native method bindings. Claude Code isolates these failures by launching the minified release build, exercising critical user journeys, parsing mangled stack traces from logcat, and applying targeted ProGuard keep rules to preserve essential classes.

When R8 optimizes an Android release APK, specific architectural patterns are notoriously susceptible to silent corruption or outright crashes. Understanding these failure modes allows engineering teams to construct targeted verification scripts.

1. JSON Serialization & Reflection Regressions

Modern Android architectures frequently use JSON serialization libraries such as Kotlinx Serialization, Moshi, or Gson to deserialize API responses into domain data models. When R8 processes data classes, it minifies field names unless explicit annotations or keep rules protect them:

// Unprotected Data Model
package com.example.screensync.model

import com.squareup.moshi.Json
import com.squareup.moshi.JsonClass

@JsonClass(generateAdapter = true)
data class UserProfile(
    @Json(name = "user_id") val userId: String,
    @Json(name = "display_name") val displayName: String,
    val email: String, // Missing @Json annotation!
    val isVerified: Boolean
)

In debug builds, Moshi reads the email field name directly via Kotlin reflection. In release builds under R8 full mode, if @JsonClass(generateAdapter = true) code generation was misconfigured or if reflection-based fallback is triggered, R8 renames email to c and isVerified to d. When the backend returns {"email": "[email protected]", "isVerified": true}, Moshi fails to locate matching fields, assigning null values or throwing a fatal com.squareup.moshi.JsonDataException: Required value 'email' missing at $.email.

2. Jetpack Compose Type-Safe Navigation Failures

With Jetpack Compose 2.8+ type-safe navigation, routes are defined as @Serializable Kotlin objects or data classes. When navigating between screens, Compose serializes arguments into bundle parameters:

package com.example.screensync.navigation

import kotlinx.serialization.Serializable

@Serializable
data class OrderDetailRoute(
    val orderId: String,
    val transactionRef: String,
    val amountCents: Long
)

If R8 strips the generated serializer or mangles the companion object's $serializer class, navigating from the catalog screen to the order screen triggers an immediate runtime crash: kotlinx.serialization.SerializationException: Serializer for class 'OrderDetailRoute' is not found. Because this failure only occurs in minified builds, standard unit tests and debug runs never detect it.

3. JNI and Native C++/Rust Method Bindings

When Android applications incorporate native shared libraries via JNI (Java Native Interface), native C++ or Rust functions register bindings matching exact Java class and method signatures (e.g., Java_com_example_screensync_NativeBridge_processHardwareFrame). If R8 renames NativeBridge to a.b.x or inlines the processHardwareFrame() method, the Android runtime throws an uncatchable java.lang.UnsatisfiedLinkError: No implementation found for void com.example.screensync.NativeBridge.processHardwareFrame().

To prevent these regressions, developers must maintain strict proguard-rules.pro configurations:

# Preserve Kotlinx Serialization and Moshi Generated Adapters
-keepattributes *Annotation*, Signature, InnerClasses, EnclosingMethod

# Keep serializable model classes and their synthetic serializers
-keepnames class kotlinx.serialization.SerializationException { *; }
-keepclassmembers class * {
    @kotlinx.serialization.Serializable *;
}
-keepclassmembers class *$$serializer {
    public static final *$$serializer INSTANCE;
}

# Preserve Moshi JsonQualifier and Generated JsonAdapters
-keepattributes RuntimeVisibleAnnotations, RuntimeInvisibleAnnotations
-keepclassmembers class * {
    @com.squareup.moshi.Json <fields>;
}
-keep class *JsonAdapter {
    public <init>(com.squareup.moshi.Moshi);
    public <init>(com.squareup.moshi.Moshi, java.lang.reflect.Type[]);
}

# Protect JNI Native Method Signatures
-keepclasseswithmembernames class * {
    native <methods>;
}

# Preserve Jetpack Compose Navigation Route Classes
-keep @kotlinx.serialization.Serializable class com.example.screensync.navigation.** { *; }

In your module-level build.gradle.kts, ensure that release builds enable R8 full mode and resource shrinking:

plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.android)
    alias(libs.plugins.kotlin.serialization)
}

android {
    namespace = "com.example.screensync"
    compileSdk = 35

    defaultConfig {
        applicationId = "com.example.screensync"
        minSdk = 24
        targetSdk = 35
        versionCode = 1
        versionName = "1.0.0"
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
            signingConfig = signingConfigs.getByName("debug") // Used for staging release verification
        }
    }
}

To verify how database schemas and persistence layers survive obfuscation and migrations, see our companion guide on testing Android Room database migrations with Claude Code and MCP.

Step-by-Step Setup: Configuring Claude Code, the Desktop Hub, and Physical Android Hardware

Configuring Claude Code to test R8 obfuscated builds on physical Android hardware requires four sequential steps: preparing workstation tools, launching the ScreenSync desktop hub, registering the stdio MCP server in Claude Code, and pairing the physical Android smartphone over a secure local connection.

Step 1: Workstation and Hardware Prerequisites

Before initiating autonomous release testing, confirm that your workstation and mobile environment satisfy the following technical prerequisites:

1. Development Host: A PC running Windows 10/11, macOS (Intel or Apple Silicon), or modern Linux with Node.js 18+ installed and available on your system PATH.
2. Android Hardware: A physical Android smartphone or tablet running Android 7.0 (API level 24) or newer.
3. Android Platform Tools: Android Debug Bridge (adb) installed, configured, and accessible from your terminal command line.
4. Local Network Subnet: Both your development workstation and your test smartphone must reside on the same local Wi-Fi network to facilitate low-latency display frame streaming and mDNS auto-discovery.

Step 2: Extract and Launch the ScreenSync MCP Desktop Hub

Download the ScreenSync MCP desktop hub package from the official project repository. Extract the archive into a dedicated directory on your computer, such as C:\tools\screensync-hub on Windows or ~/tools/screensync-hub on macOS and Linux.

Start the desktop hub using the included startup script:

# On Linux or macOS
cd ~/tools/screensync-hub
chmod +x start-hub.sh
./start-hub.sh

# On Windows (PowerShell or Command Prompt)
cd C:   ools\screensync-hub
.\start-hub.bat

Upon initialization, the desktop hub boots a local HTTP listener on port 3000 to ingest mobile video streams and exposes Model Context Protocol endpoints over standard input/output (stdio). The terminal logs print your session bearer token (SCREEN_SYNC_TOKEN) and render an ASCII QR code for fast mobile onboarding.

Step 3: Register ScreenSync MCP in Claude Code and Claude Desktop

To connect Claude Code CLI to ScreenSync MCP, execute the native registration command in your terminal:

# Register ScreenSync MCP with Claude Code CLI
claude mcp add screensync node "/path/to/screensync-hub/screensync-hub.js"

If you are using Claude Desktop, open your configuration file (claude_desktop_config.json, accessible via Settings > Developer > Edit Config) and add the server entry:

{
  "mcpServers": {
    "screensync": {
      "command": "node",
      "args": [
        "/path/to/screensync-hub/screensync-hub.js"
      ],
      "env": {
        "SCREEN_SYNC_TOKEN": "your_hub_bearer_token_here"
      }
    }
  }
}

Note: The web-based ChatGPT interface requires remote HTTPS-hosted MCP endpoints and cannot interface with local stdio servers. ScreenSync MCP is built specifically for local AI coding environments, including Claude Desktop, Claude Code, Cursor, and VS Code in agent mode.

Step 4: Install the Android Application and Pair the Hardware

On your physical Android device, install the free ScreenSync MCP application (package com.screensync.mcp) directly from Google Play.

1. Launch the ScreenSync MCP application on your smartphone.
2. The application will scan your local Wi-Fi network using mDNS to detect the running desktop hub. If your router blocks multicast discovery, tap the QR scanner icon within the app and scan the terminal QR code.
3. Tap Start Projection. The Android operating system will present a system security dialog requesting display capture authorization via MediaProjection. Tap Start Now.
4. Enable Developer Options on your phone (open Settings > About Phone and tap Build Number seven times), navigate to Developer Options, and toggle USB Debugging or Wireless Debugging to enabled.
5. Connect your device via USB cable or establish wireless pairing using our comprehensive guide on Android wireless debugging for MCP servers. Verify the connection by running adb devices in your workstation shell. For detailed troubleshooting instructions, consult the official ScreenSync MCP setup guide.

Practical Autonomous Agent Workflows: Building, Deploying, and Retracing R8 Crashes

Practical autonomous agent workflows empower Claude Code to build release APKs, deploy them to hardware, execute comprehensive smoke tests, capture obfuscated crash logs, and retrace stack traces using mapping files. This closed-loop automation eliminates manual debugging cycles and accelerates release readiness.

When an autonomous agent has access to both your local project codebase and a live physical Android device, it can execute sophisticated, multi-phase verification pipelines.

Workflow 1: Autonomous Release Build, Deployment, and Smoke Testing

Developers initiate the release verification pipeline with a high-level natural language prompt in Claude Code:

Developer Prompt:
"Claude, please compile a minified release build of our app with R8 enabled. Install it on the connected Android phone, launch the MainActivity, navigate through the onboarding carousel to the login screen, enter test credentials, and verify that the user dashboard renders without R8 reflection errors."

Claude Code begins by assembling the release APK using your local Gradle wrapper:

./gradlew assembleRelease

Once the build finishes, Claude Code retrieves the output APK path (app/build/outputs/apk/release/app-release.apk) and installs it onto the physical hardware via ADB:

adb install -r app/build/outputs/apk/release/app-release.apk

Next, Claude Code uses ScreenSync MCP's 29 phone and desktop tools to launch the obfuscated application:

{
  "name": "control_launch_app",
  "arguments": {
    "packageName": "com.example.screensync",
    "activity": "com.example.screensync.ui.MainActivity"
  }
}

Claude Code allows the activity transition to stabilize, then queries the live UI hierarchy:

{
  "name": "get_ui_hierarchy",
  "arguments": {}
}

Even though underlying view classes or composable functions may be obfuscated in bytecode, Android's Accessibility Node Provider exposes semantic content descriptions, test tags, and visible text strings. Claude Code identifies the onboarding swipe container and dispatches gesture commands:

{
  "name": "control_swipe",
  "arguments": {
    "startX": 950,
    "startY": 1200,
    "endX": 150,
    "endY": 1200,
    "duration": 300
  }
}

After swiping through the carousel, Claude Code taps the login button, injects test credentials using control_type, and requests a hardware display frame via get_latest_screenshot to confirm that the dashboard renders correctly. To benchmark app launch performance and verify that R8 optimizations improve cold start times, explore our guide on testing Android app startup with Claude Code and MCP.

Workflow 2: Automated Retracing and ProGuard Rule Self-Healing

If an unhandled exception or missing class causes the application to crash, Claude Code diagnoses and resolves the defect autonomously:

Developer Prompt:
"The release app crashed immediately upon opening the user profile screen. Check logcat, de-obfuscate the crash stack trace using our release mapping file, identify the root cause, add the required ProGuard keep rules, and verify the fix on the phone."

Claude Code calls get_logcat to pull the recent system error buffer:

{
  "name": "get_logcat",
  "arguments": {
    "lines": 120
  }
}

The tool returns the raw, mangled stack trace from logcat:

FATAL EXCEPTION: main
Process: com.example.screensync, PID: 18452
java.lang.NullPointerException: Parameter specified as non-null is null: method a.b.c.d.a, parameter email
    at a.b.c.d.a(Unknown Source:7)
    at com.example.screensync.ui.profile.ProfileViewModel$loadUser$1.invokeSuspend(Unknown Source:42)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(Unknown Source:11)
    at kotlinx.coroutines.DispatchedTask.run(Unknown Source:98)

Notice that the failing class and method are completely obfuscated (a.b.c.d.a). Claude Code locates the build's ProGuard mapping file at app/build/outputs/mapping/release/mapping.txt and invokes the Android SDK retrace tool:

$ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/release/mapping.txt obfuscated_trace.txt

The de-obfuscated stack trace reveals the exact culprit:

FATAL EXCEPTION: main
Process: com.example.screensync, PID: 18452
java.lang.NullPointerException: Parameter specified as non-null is null: method com.example.screensync.model.UserProfile.<init>, parameter email
    at com.example.screensync.model.UserProfile.<init>(UserProfile.kt:12)
    at com.example.screensync.ui.profile.ProfileViewModel$loadUser$1.invokeSuspend(ProfileViewModel.kt:48)

Claude Code analyzes UserProfile.kt, recognizes that the email field was stripped by R8 during Moshi deserialization, and edits app/proguard-rules.pro to add the missing rule:

-keepclassmembers class com.example.screensync.model.UserProfile {
    <fields>;
}

Claude Code re-runs ./gradlew assembleRelease, installs the updated APK via ADB, re-launches the profile screen, and confirms that get_logcat logs zero runtime exceptions. For developers seeking to integrate autonomous agent testing into automated release pipelines, review our guide on building resilient mobile CI/CD pipelines with Android MCP.

To inspect the full inventory of mobile inspection and telemetry tools, consult our comprehensive documentation on the complete Android MCP tool reference.

Cross-Surface Verification: Minified Native Apps Interfacing with Web Portals

Cross-surface verification ensures that obfuscated Android applications seamlessly hand off user journeys to external web portals. When a minified release APK triggers an OAuth2 login or a Stripe checkout flow inside Chrome Custom Tabs, ScreenSync MCP bridges 29 mobile tools and 197 browser automation tools to validate the entire end-to-end transaction.

Commercial mobile applications do not exist in isolation. In production releases, user workflows frequently transition from native Android screens to mobile browser surfaces:

1. Third-Party Payment Gateways: Security and compliance mandates often require delegating credit card checkout to hosted web portals like Stripe Checkout, Shopify, or PayPal.
2. Federated OAuth2 Authentication: Enterprise single sign-on (SSO) and social logins (Google, Apple, Okta) typically launch inside a Chrome Custom Tab to prevent native applications from intercepting user credentials.
3. App Links and Web Redirects: Marketing campaigns and deep links route users between native activities and responsive web landing pages.

Traditional testing tools struggle severely when flows transition across process and platform boundaries. Appium requires complex driver switching, while Espresso cannot automate actions outside the host application's sandbox.

ScreenSync MCP resolves this limitation by bundling 226 total MCP tools within a single unified platform. In addition to 29 mobile and desktop tools, ScreenSync MCP includes a Manifest V3 browser extension for Google Chrome and Microsoft Edge that provides 197 web_* automation tools.

When an obfuscated Android app opens a Chrome Custom Tab for checkout, Claude Code uses mobile tools to trigger the action:

{
  "name": "control_tap",
  "arguments": {
    "x": 540,
    "y": 1850
  }
}

Once Chrome takes foreground focus, Claude Code transitions to the browser toolset to complete the payment flow:

{
  "name": "web_fill",
  "arguments": {
    "selector": "#card-number",
    "value": "4242424242424242"
  }
}

After completing the transaction with web_click, Chrome dispatches an Android App Link redirecting back to the native application (screensync://checkout/success). Claude Code switches back to get_latest_screenshot on the physical smartphone to confirm that the native order confirmation screen displays the expected transaction identifier. For enterprise security, the ScreenSync browser extension includes a built-in human confirmation prompt for sensitive actions, ensuring complete safety during unattended runs.

Production Best Practices: Hardening Obfuscated App Verification in CI/CD

Production best practices for validating obfuscated builds require establishing local network isolation, securing staging credentials, maintaining versioned mapping archives, and adhering to a rigorous release validation checklist. These measures ensure that production releases remain stable, performant, and secure.

Local Network Isolation and Enterprise Data Privacy

When deploying autonomous AI agents to validate release builds, engineering organizations must maintain strict boundaries around intellectual property and customer privacy:

• Local Frame Transmission: In ScreenSync MCP, live video frames captured via MediaProjection stream directly from the phone to your workstation desktop hub over your local Wi-Fi network. No video frames, touch coordinates, or device identifiers are ever transmitted to EpsolDev servers.
• Model Provider Boundaries: When Claude Code invokes get_latest_screenshot, that individual visual frame is transferred across the local stdio transport to the Claude Code CLI, which sends the image to Anthropic's model API for multimodal reasoning. Staging builds should utilize synthetic test databases and mock user profiles to ensure sensitive production customer data is never rendered on test screens.
• Versioned ProGuard Mapping Archives: Never deploy a release APK without archiving its exact mapping.txt file alongside the build artifact. Without the matching mapping file, de-obfuscating crash reports collected in production is virtually impossible.

Obfuscated Release Validation Checklist

Before releasing an Android build to the Google Play Store, execute this comprehensive checklist using Claude Code and ScreenSync MCP:

• [ ] R8 Full Mode Enabled: Verify that android.enableR8.fullMode=true is set in gradle.properties and isMinifyEnabled = true is configured in build.gradle.kts.
• [ ] Physical Hardware Active: Test smartphone running Android 7.0+ is connected via USB or wireless debugging, with adb devices confirming authorized device state.
• [ ] ScreenSync Hub Listening: Desktop hub running Node.js 18+ is active on port 3000, streaming MediaProjection frames with sub-100ms latency.
• [ ] Core User Journeys Exercised: Claude Code has navigated key application funnels (onboarding, login, checkout, settings) on the physical device without triggering missing class errors.
• [ ] Logcat Exception Audit: get_logcat telemetry confirms zero unhandled NullPointerException, ClassNotFoundException, NoSuchMethodError, or JsonDataException entries.
• [ ] Stack Traces Retraced: Any logged warnings or handled exceptions have been de-obfuscated using mapping.txt and verified against intentional code paths.
• [ ] Cold Startup Benchmarked: Physical cold launch latency has been measured to verify that R8 method inlining and dex optimization yield tangible startup speed improvements.

Conclusion

Testing Android applications with R8 code shrinking and ProGuard obfuscation on physical devices eliminates the risk of releasing fatal bytecode regressions to production. By combining low-latency MediaProjection screen mirroring with deterministic ADB command execution, ScreenSync MCP equips autonomous AI agents like Claude Code with the perceptual vision and low-level control required to validate minified release builds with complete confidence. Beyond bytecode verification, developers can also apply autonomous testing to security-critical features by reviewing how to evaluate mobile reverse engineering and static analysis workflows and verifying real-world device compatibility in our guide on testing Android applications on real mobile hardware with Claude Code. For end-to-end guidance on structuring autonomous QA suites, consult our complete guide on autonomous mobile app testing with Claude Code.

ScreenSync MCP provides developer tools including the ScreenSync MCP Android app, ScreenSync MCP desktop hub, and ScreenSync MCP browser extension to engineering teams worldwide. To get started with autonomous Android release testing, review our Android MCP servers directory and download the free mobile app directly on Google Play. For inquiries, contact [email protected] or visit https://www.screensyncmcp.tech.