114 posts tagged with "Android"

End-to-end tests often fall apart the moment your app requests a system permission. The standard integration_test package can only see your Flutter widget tree - it can’t tap “Allow” on Android’s permission controller or “Allow While Using App” on iOS. That’s exactly where Patrol shines. With Patrol, you can write true end-to-end tests that drive both Flutter widgets and native UI, so you can reliably automate permission requests, notifications prompts, backgrounding, and other OS features.

This guide is a practical, production-focused walkthrough of patrol flutter integration testing. We’ll build a minimal permission flow, drive the native dialogs on Android and iOS, run tests locally via Patrol CLI, and wire it all into GitHub Actions CI. Along the way we’ll cover real-world pitfalls, stability tactics, and cross-platform differences.

What you’ll build​

• A minimal Flutter screen that requests location permission using permission_handler
• A Patrol end-to-end test that: ◦ Launches the app ◦ Taps the request button in Flutter ◦ Interacts with the native permission dialog on Android and iOS ◦ Verifies the in-app result
• Local runs using Patrol CLI on Android emulators and iOS simulators
• CI pipeline to integrate Patrol in GitHub Actions (Android and iOS)

Prerequisites​

• Flutter 3.22+ (stable) and Dart 3.x
• Xcode 15+ for iOS simulator runs (macOS only)
• Android SDK 34+, an Android emulator or device
• Cocoapods for iOS builds (if on macOS)
• A recent Patrol package and Patrol CLI

Tip: When upgrading Flutter/Dart, also update patrol and permission_handler to their latest versions for best compatibility.

Why Patrol?​

• Interact with native UI: permission dialogs, settings panes, notifications, app switcher, etc.
• Drive Flutter widgets and native elements from a single Dart test API.
• Works on real devices, emulators, and simulators.
• Fits into your existing integration_test workflow, but extends it to true end-to-end coverage.

Project setup​

1. Add dependencies​

pubspec.yaml (dev deps for tests + permission handler for demo):

name: patrol_permission_demo
description: Demo of Patrol end-to-end testing with native permission dialogs
publish_to: "none"

environment:
  sdk: ">=3.3.0 <4.0.0"

dependencies:
  flutter:
    sdk: flutter
  permission_handler: ^11.3.1

dev_dependencies:
  flutter_test:
    sdk: flutter
  integration_test:
    sdk: flutter
  patrol: ^3.0.0 # use latest stable

flutter:
  uses-material-design: true

Then:

flutter pub get

2. iOS and Android permission configuration​

• iOS: add a usage description to Info.plist so iOS can show the system dialog.

ios/Runner/Info.plist:

<key>NSLocationWhenInUseUsageDescription</key>
<string>We use your location to show nearby content.</string>

• Android: declare the permission in AndroidManifest.

android/app/src/main/AndroidManifest.xml (inside <manifest>):

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

Note:

• On Android 12+ the system may also consider coarse location. Keep UX consistent in your app code if you require fine accuracy.
• Ensure your app actually triggers a runtime permission request (done via permission_handler in our demo).

3. Install Patrol CLI​

dart pub global activate patrol_cli
patrol doctor

Make sure $HOME/.pub-cache/bin is on your PATH so the patrol command is available.

Minimal app under test​

We’ll build a tiny screen that asks for location permission and reports the result.

lib/main.dart:

import 'package:flutter/material.dart';
import 'package:permission_handler/permission_handler.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatefulWidget {
  const MyApp({super.key});
  @override
  State<MyApp> createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  String _status = 'Permission not requested';

  Future<void> _requestLocation() async {
    final status = await Permission.locationWhenInUse.request();

    setState(() {
      if (status.isGranted) {
        _status = 'Location granted';
      } else if (status.isPermanentlyDenied) {
        _status = 'Location permanently denied';
      } else if (status.isDenied) {
        _status = 'Location denied';
      } else {
        _status = 'Location status: $status';
      }
    });
  }

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Patrol Permission Demo',
      home: Scaffold(
        appBar: AppBar(title: const Text('Patrol Permission Demo')),
        body: Padding(
          padding: const EdgeInsets.all(16),
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: [
              Text(_status, key: const Key('permission_status')),
              const SizedBox(height: 16),
              ElevatedButton(
                key: const Key('request_location'),
                onPressed: _requestLocation,
                child: const Text('Request location'),
              ),
            ],
          ),
        ),
      ),
    );
  }
}

Writing the Patrol end-to-end test​

We’ll write a test that:

1. Launches the app
2. Taps the button in Flutter
3. Accepts the native permission dialog on each platform
4. Verifies widget state updates to “Location granted”

Create integration_test/permission_flow_test.dart:

import 'dart:io' show Platform;

import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:patrol/patrol.dart';

import 'package:patrol_permission_demo/main.dart' as app;

void main() {
  patrolTest(
    'requests location permission and accepts the dialog',
    ($) async {
      // Start the app like a user would
      app.main();
      await $.pumpAndSettle();

      // Trigger the permission request
      await $.tap(find.byKey(const Key('request_location')));

      // Interact with native permission dialogs
      if (Platform.isAndroid) {
        // Depending on Android version, text can differ:
        // - "While using the app" / "Allow" (API <= 30)
        // - "While using the app" or "Allow only while using the app" (API 31+)
        // We'll use a broad "Allow" contains to keep it resilient.
        await $.native.tap(Selector(textContains: 'Allow'));

        // Some OEMs or versions show a two-step dialog:
        // If another "Allow" or "While using" appears, try tapping it again.
        // This extra tap is safe if nothing is visible.
        await $.native.tap(Selector(textContains: 'Allow'), optional: true);
      } else if (Platform.isIOS) {
        // iOS commonly displays "Allow While Using App" and "Don’t Allow".
        // Use labelContains for accessibility labels and variations across versions.
        await $.native.tap(Selector(labelContains: 'Allow While Using'));
        // On some iOS versions or languages, it might just be "Allow"
        await $.native.tap(Selector(label: 'Allow'), optional: true);
      }

      // Wait for the app to react and re-render
      await $.pumpAndSettle();

      // Validate the in-app state after permission is granted
      expect(find.text('Location granted'), findsOneWidget);
    },
  );
}

Notes:

• patrolTest gives you $, a PatrolTester instance that can drive both Flutter and native UI.
• $.tap(Finder) interacts with Flutter widgets.
• $.native.tap(Selector(...)) interacts with native UI elements.
• We use textContains/labelContains to guard against minor UI text variations across OS versions. You can also localize these strings if your CI runs in non-English locales.
• The optional: true parameter allows the tap to be skipped if that selector is not found, improving resilience.

Running locally with Patrol CLI​

• Android (emulator or device connected):

# List Android devices to get an ID
adb devices

# Run the end-to-end test against a specific device
patrol test -t integration_test/permission_flow_test.dart -d emulator-5554

• iOS (simulator; macOS only):

# List iOS simulators
xcrun simctl list devices

# Run on a specific simulator
patrol test -t integration_test/permission_flow_test.dart -d "iPhone 15"

If you have multiple Flutter flavors, build configs, or targets, Patrol supports passing build options (e.g., --flavor, --dart-define) similar to standard Flutter build/test commands. Run patrol --help for details.

Production tips for stable end-to-end testing​

• Centralize native selectors: Create “robots” or “page objects” for permission flows so text/label changes are updated in one place.
• Prefer contains/matches selectors: OEM skins and OS updates tweak exact button labels. Use textContains, labelContains, or regex matches when appropriate.
• Handle both first-run and subsequent runs: If permission was already granted, the dialog won’t appear - make your test robust by verifying the outcome rather than assuming the dialog always shows.
• Pin emulators/simulators in CI: Use consistent device profiles and API levels to reduce flakiness caused by UI differences.
• Test denial flows: CI often needs both “Allow” and “Don’t Allow” scenarios for analytics, error handling, and fallback UX.
• Reset state when necessary: On CI, consider wiping the simulator/device between runs so the permission prompt always appears, or explicitly revoke the permission via platform tools.

Integrate Patrol in GitHub Actions​

Below is a minimal setup for a two-job matrix: Android on Ubuntu and iOS on macOS. It installs Flutter, activates the Patrol CLI, boots devices, and runs the same Patrol end-to-end test.

.github/workflows/patrol-e2e.yml:

name: Patrol E2E

on:
  push:
    branches: [ main ]
  pull_request:

jobs:
  android:
    runs-on: ubuntu-latest
    timeout-minutes: 30
    steps:
      - uses: actions/checkout@v4

      - name: Set up Java
        uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "17"

      - name: Set up Flutter
        uses: subosito/flutter-action@v2
        with:
          channel: stable
          cache: true

      - name: Flutter pub get
        run: flutter pub get

      - name: Activate Patrol CLI
        run: dart pub global activate patrol_cli

      - name: Run Patrol tests on Android emulator
        uses: reactivecircus/android-emulator-runner@v2
        with:
          api-level: 34
          target: google_apis
          arch: x86_64
          profile: pixel_6
          script: |
            export PATH="$PATH:$HOME/.pub-cache/bin"
            flutter pub get
            patrol doctor
            # Optional: clean/wipe to ensure permission dialog is shown every run
            adb uninstall com.example.patrol_permission_demo || true
            patrol test -t integration_test/permission_flow_test.dart

  ios:
    runs-on: macos-latest
    timeout-minutes: 45
    steps:
      - uses: actions/checkout@v4

      - name: Set up Flutter
        uses: subosito/flutter-action@v2
        with:
          channel: stable
          cache: true

      - name: Install CocoaPods
        run: |
          sudo gem install cocoapods --no-document
          pod repo update

      - name: Flutter pub get
        run: flutter pub get

      - name: Activate Patrol CLI
        run: dart pub global activate patrol_cli

      - name: Boot iOS Simulator and run Patrol
        env:
          PATH: ${{ env.PATH }}:$HOME/.pub-cache/bin
        run: |
          SIM="iPhone 15"
          xcrun simctl boot "$SIM" || true
          xcrun simctl bootstatus "$SIM" -b
          patrol doctor
          # Optional: uninstall to re-trigger permission prompt each run
          xcrun simctl uninstall "$SIM" com.example.patrolPermissionDemo || true
          patrol test -t integration_test/permission_flow_test.dart -d "$SIM"

Notes:

• Use consistent device profiles to avoid UI discrepancies.
• Uninstalling the app between runs ensures fresh permission prompts in CI.
• If you localize your app or the runner’s locale is not English, adapt selectors accordingly.

This satisfies the “integrate patrol in github actions” search intent with a practical, copy-pasteable workflow.

Extending to other OS prompts​

The same pattern applies to:

• Notifications: tap “Allow” vs “Don’t Allow” on iOS; handle Android 13+ notification permission dialog.
• Photos/camera/microphone: buttons usually vary slightly by version; use textContains/labelContains.
• Backgrounding and returning: after granting permission, you can continue your flow (e.g., open camera, capture media) and assert postconditions.

Keep OS and OEM variance in mind - prefer flexible selectors over exact text when possible, and add optional taps for multi-step prompts.

Common pitfalls and troubleshooting​

• The system dialog never shows:
  • Ensure Info.plist/AndroidManifest entries are correct.
  • Make sure your code calls request() at runtime (not just checks status).
  • If permission was already granted, the OS will not prompt again; uninstall the app or revoke permission before the test.
• Flaky or slow CI:
  • Increase timeouts and add await $.pumpAndSettle() after significant UI transitions.
  • Use stable emulator/simulator versions and pin API levels.
• Text doesn’t match across OS versions or locales:
  • Prefer textContains/labelContains, regex matches, or separate selectors by platform/OS version.
• Build/system errors on iOS:
  • Ensure Cocoapods is installed and pod install runs if needed.
  • Validate Xcode Command Line Tools path: sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer.
• Android permission controller differences:
  • OEMs sometimes customize wording. Keep selectors loose (contains/matches) and consider adding a second optional tap.

Architecture and maintainability tips​

• Use the Robot pattern. Example:

class PermissionRobot {
  final PatrolTester $;
  PermissionRobot(this.$);

  Future<void> allowLocationDialog() async {
    if (Platform.isAndroid) {
      await $.native.tap(Selector(textContains: 'Allow'));
      await $.native.tap(Selector(textContains: 'Allow'), optional: true);
    } else if (Platform.isIOS) {
      await $.native.tap(Selector(labelContains: 'Allow While Using'));
      await $.native.tap(Selector(label: 'Allow'), optional: true);
    }
  }

  Future<void> denyLocationDialog() async {
    if (Platform.isAndroid) {
      await $.native.tap(Selector(textContains: 'Don’t allow'), optional: true);
      await $.native.tap(Selector(textContains: 'Deny'), optional: true);
    } else if (Platform.isIOS) {
      await $.native.tap(Selector(labelContains: 'Don’t Allow'));
    }
  }
}

• Keep OS logic centralized. If a new OS version changes wording, you only update one place.
• Combine with your app’s architecture (Clean Architecture/BLoC/Riverpod) to inject fakes and run richer end-to-end scenarios with server mocks or local fixtures.

What about other test types?​

• Unit tests: Validate pure Dart logic and view models.
• Widget tests: Validate widget trees without the OS.
• Integration/end-to-end tests with Patrol: Validate real device flows including native UI and system features.

Use all three tiers for defense-in-depth quality.

Beyond CI: Monitoring Real-World Permission Drop-Offs with Appxiom​

Automated tests in Patrol prove that your happy and unhappy paths work under ideal, simulated conditions. But in production, native OS permissions are one of the biggest conversion drop-off points in mobile apps.

Real users behave unpredictably: they dismiss system dialogs, hit OEM-specific battery/permission quirks (e.g., Xiaomi MIUI or Samsung OneUI), revoke permissions mid-session in system settings, or encounter silent native bridge failures that never register as fatal crashes.

To close the loop between pre-release automation and live user experience, pair Patrol with Appxiom Real User Monitoring (RUM)

Conclusion​

Patrol elevates end to end testing flutter apps from widget-only checks to real device automation. With patrol flutter integration testing you can reliably handle flutter testing native permission dialogs, notifications prompts, and OS interactions that used to be out of reach. The Patrol CLI makes local runs simple and enables a clean patrol cli tutorial android ios workflow you can lift straight into CI. In GitHub Actions, you can integrate patrol in github actions to run on Android emulators and iOS simulators with predictable results.

Key takeaways:

• Use Patrol when your tests need to interact with native UI or OS features.
• Keep native selectors resilient using contains/matches and optional taps.
• Reset app state in CI to consistently trigger first-run dialogs.
• Centralize platform differences using Robots for maintainability.

Next steps:

• Add denial and “Ask Next Time” flows.
• Extend tests to notifications and camera/photo permissions.
• Parallelize device matrices (API levels, iOS versions) to increase confidence before release.

With Patrol in place, your test suite will cover the last mile - where your app meets the OS.

Bridge the Gap Between Test Automation and Production Health​

Patrol protects your releases in CI, but what happens when real users hit your native permissions in the wild? Don't let silent onboarding bottlenecks and permission friction destroy your funnel conversion.

Explore Appxiom plans and pricing to start tracking Goal Friction Impact, or check out our developer documentation to integrate our lightweight SDK in under 5 minutes. Protect your app's performance with a 30-day free trial.

Introduction: The Unseen Cost of Poor Mobile Performance​

In mobile development, app speed and reliability aren't luxuries-they're the price of entry. Even small performance issues-UI jank, input lag, or unresponsive screens-directly translate to user churn and negative reviews. For engineers, these aren’t “just bugs”; they are signals of deeper systemic issues, often buried within OS layers and not easily uncovered with surface-level profiling.

This is where Systrace steps in. Far from a basic profiling tool, Systrace delivers deep, OS-level observability, empowering developers, QA engineers, and engineering leaders to find the real root causes of performance cliffs in Android apps. In this post, we’ll dive into how to leverage Systrace for actionable low-level performance tuning, focusing on practical debugging, observability, and reliability strategies for all skill levels.

Why Systrace: Beyond Studio Profiler and Logcat​

While tools like Android Studio Profiler and Logcat provide critical insights, their granularity often ends at the process or framework level. Issues like “mysterious” jank, dropped frames, background thread bottlenecks, or cross-process contention often stay hidden. Systrace fills these gaps by capturing a system-wide, time-stamped trace of what every thread and process (including the kernel and system services) are doing.

Common real-world issues Systrace helps uncover:

• UI thread blocked on I/O, mistakenly assumed to be a CPU bottleneck
• Long GC (Garbage Collection) pauses causing animation stutter
• Synchronization deadlocks or lock contention on background workers
• Misuse of the main thread for expensive operations (leading to ANR)
• Resource contention between your app and system daemons

Key Systrace Features:

• Visualizes thread states and events over time
• Points directly to which code or system resource is the true bottleneck
• Offers microsecond-level temporal accuracy

Using Systrace in Practice: Step-by-Step Workflow​

1. Setup and Capture a Trace​

Systrace is available via adb or the Android Studio Profiler:

adb shell 'setprop debug.atrace.tags.enableflags 0xFFFFFFFF'
adb shell atrace -z -b 4096 -t 10 gfx view wm input sched freq idle am res dalvik > trace.html

• -t 10 captures 10 seconds.
• The event categories (gfx, view, etc.) control which subsystems to trace.
• Output is a self-contained HTML for Chrome’s trace viewer.

Pro tip: Always capture a few seconds before and after the incident. Many performance problems are effects, not causes.

2. Reading the Trace: Key Patterns to Spot​

Load trace.html in Chrome. Here’s what to look for:

• Jank & Frame Drops: Look for long red blocks or gaps in Choreographer, RenderThread or MainThread bars.
• Long CPU Burst: Examine “sched” lanes; excessive CPU time on main/UI thread can signal unoptimized code.
• Blocking on I/O or Locks: “Uninterruptible sleep” or “mutex_wait” in thread state-a sign your UI thread is waiting for disk/network or locks.
• GC Events: GC activity (seen as “GC” or “Dalvik” events) overlapping frame rendering often correlates with visible UI stutter.

Actionable Debugging: Practical Examples​

Let’s explore concrete scenarios and how Systrace provides answers where other tools fall short.

Case 1: UI Jank on List Scrolling​

Problem: Users report laggy scrolling when images load in a RecyclerView.

With Systrace:

• You see MainThread blocked for ~60ms, coinciding perfectly with dequeueBuffer in RenderThread.
• Zooming in, you spot “disk_read” in a worker thread initiated by the image loader, but a lock contention with the main thread.

Root Cause: The image loader’s result is being posted synchronously back to the UI thread, causing it to wait unnecessarily.

Solution: Refactor to fully decouple image loading and UI update, perhaps via AsyncListDiffer or separate UI handler.

Case 2: Random, Infrequent ANRs (App Not Responding)​

Problem: Sporadic ANRs in production with no clear thread in ANR reports.

With Systrace:

• You find that several background threads are hitting heavy disk I/O at the same time the main thread tries to commit SharedPreferences synchronously.
• The “sched” lane shows the main thread is runnable but not scheduled-starved by system load.

Root Cause: Too many concurrent background jobs are blocking system-level I/O.

Solution: Batch writes, use apply() for async SharedPreferences commits, and set sensible thread pool limits.

Building Observability Into Your App: Making Systrace Even Stronger​

Systrace supports custom trace markers. Annotate critical parts of your code to trace business logic, not just framework operations.

Example: Annotating long-running code

import android.os.Trace

fun loadData() {
    Trace.beginSection("LoadData:fetchFromApi") // Custom marker
    // Expensive network or DB code here
    Trace.endSection()
}

These custom sections become visible in traces, making it much easier to map expensive operations to code changes, releases, and business features.

Tips for actionable observability:

• Use markers for large DB queries, network calls, and custom rendering.
• Combine Systrace with app-level logging to correlate user-level events and system-level performance.

Reliability: Preemptive Tuning and Guardrails​

Engineering leaders and QA teams can leverage Systrace as a proactive safeguard in release cycles:

• Baseline creation: Regular Systrace captures from “stable” releases create a performance baseline. Compare traces after major merges to spot regressions before rollout.
• CI Integration: Automated smoke tests can trigger Systrace captures for key user flows, alerting engineers to invisible performance regressions early.
• Production forensics: Ship lightweight Systrace collectors (with user opt-in) to capture post-mortem traces for irreproducible bugs.

Takeaways and Next Steps​

Systrace is not just another profiling tool-it’s your OS-level microscope for Android performance. By surfacing kernel, framework, and application events side-by-side, it empowers developers and leaders to:

• Precisely diagnose the source of jank, ANR, or mysterious slowdowns.
• Implement observability with custom trace markers.
• Leverage traces to proactively guard reliability across engineering teams.

Action Items:

• Integrate Systrace captures into your regular performance debugging toolkit-not just for “crash” bugs, but for every major user flow.
• Start annotating your code with custom markers today for business-relevant observability.
• Encourage team-wide familiarity with reading and interpreting Systrace outputs as an engineering best practice.

Looking forward: As Android frameworks become more complex and performance expectations rise, deep system observability is not optional. Systrace enables you to build not just faster apps, but fundamentally more reliable and predictable mobile experiences.

Further Reading & Resources:

• Official Android Systrace Documentation
• Chrome Trace Viewer

Stay curious, stay precise-happy tracing!

Introduction​

Garbage Collection (GC) pauses are among the most common sources of frame drops, UI jank, and app unresponsiveness in Android applications. For developers, QA engineers, and engineering leaders, understanding and managing memory efficiently is not a mere academic interest-it's the bedrock of delivering smooth, reliable user experiences. In this post, we’ll explore actionable, real-world strategies for optimizing memory usage, reducing GC-induced performance hitches, improving observability, and enhancing app reliability. Whether you’re just starting with Android or leading a team through the trenches of mobile performance, this guide provides technical depth and practical solutions that you can apply immediately.

Understanding the Real-World Impact of GC Pauses​

Before diving into optimizations, let’s ground our approach in real-world challenges:

• GC Pauses Harm Perceived Performance: Even a 100-200ms pause-barely perceptible on paper-can nullify the painstaking work behind silky-smooth animations or lightning-fast data fetches.
• Memory Leaks = Reliability Nightmares: Unchecked leaks can eventually destabilize the entire app, leading to crashes or system-driven terminations.
• Mobile Constraints Multiply Trouble: With limited RAM, slower CPUs, and frequent app switching, Android apps feel the sting of poor memory management more acutely than their desktop counterparts.

Performance Optimization: Strategies to Minimize GC Pauses​

1. Use Object Pools Carefully​

While Java/Kotlin's GC ultimately collects unused objects, object pooling can significantly reduce allocation churn, especially for short-lived, high-frequency objects (e.g., Bitmap, custom buffer types). However, misuse can lead to stale references and leaks.

object ByteArrayPool {
    private val pool = ArrayDeque<ByteArray>()

    fun acquire(size: Int): ByteArray =
        pool.find { it.size == size } ?: ByteArray(size)

    fun release(array: ByteArray) {
        pool.add(array)
    }
}

Tip: Only pool objects with measurable allocation overhead and ensure timely release back to the pool after use.

2. Prefer Value Types and Primitives​

Reducing heap allocations for simple data can decrease GC pressure:

• Use primitive arrays (IntArray, FloatArray) instead of boxed counterparts.
• Favor Kotlin's data classes judiciously and be aware that excessive nesting creates more GC work.

3. Limit Use of Anonymous Inner Classes and Lambdas in Hot Paths​

Each lambda or anonymous inner class may result in an object allocation. In performance-critical sections (adapters, frequent callbacks), prefer function references or static singletons where applicable.

// Instead of:
button.setOnClickListener { /* ... */ }

// Use:
val sharedClickListener = View.OnClickListener { /* ... */ }
button.setOnClickListener(sharedClickListener)

4. Control Bitmap Memory Proactively​

• Always recycle() unused bitmaps.
• Prefer inBitmap option with BitmapFactory.Options to reuse existing memory.
• Downsample images based on actual display size.

val options = BitmapFactory.Options().apply {
    inSampleSize = calculateSampleSize(...)
    inMutable = true
}
BitmapFactory.decodeResource(resources, R.drawable.large_image, options)

5. Defer and Batch Allocations​

Whenever feasible, allocate memory-intensive objects off the UI thread and batch allocations to avoid small, frequent heap pressure bursts.

Debugging Memory Issues: Effective Strategies​

Tools of the Trade​

• Android Studio Profiler: Inspect heap allocations, GC events, and allocation timelines for your app in real-time.
• LeakCanary: Automatically detects memory leaks and provides stack traces to frequently-leaked objects.
• MAT (Memory Analyzer Tool): Analyze heap dump files (.hprof) for deep inspection and dominator tree analysis.

Practical Debugging Steps​

1. Capture Heap Dumps at Key Interactions: Especially after navigating back from a memory-heavy screen, to ensure expected GC and deallocation.
2. Track Lifecycle-Related Leaks: Fragments, views, and background jobs often outlive their welcome-ensure you sever references in proper lifecycle methods.

override fun onDestroyView() {
    super.onDestroyView()
    binding = null  // Prevents view holding reference in Fragment
}

3. Instrument and Annotate Code: Use loggers and custom tooling to record object lifecycle events, making it easier to spot trends that lead to memory bloat.

Implementing Observability for Memory Health​

Observability isn’t just for server-side systems. Reliable Android apps demand similar discipline.

Expose and Monitor Key Metrics​

• Heap Usage: Sample heap size periodically and log spikes. Android’s Debug.getNativeHeapAllocatedSize() is useful for tracking native memory leaks.
• GC Frequency and Duration: React to repeated GC cycles (known as GC thrashing) that often precede crashes or OOM errors.

val runtime = Runtime.getRuntime()
Log.d("Memory", "Used: ${(runtime.totalMemory() - runtime.freeMemory()) / 1024} KB")

In-App and Remote Monitoring​

• Integrate lightweight reporting (e.g., via Firebase Performance Monitoring, custom endpoints) to capture memory health in production, not just in dev builds.
• For QA teams: automate checks for memory peaks during exploratory testing flows.

Ensuring Application Reliability​

Reliability means your app remains stable under stress, high user load, and edge conditions.

Defensive Engineering Approaches​

• Graceful Degradation: Catch and report OutOfMemoryError in isolated threads/components; avoid bringing down the whole app.
• Low-Memory Handling: Leverage ComponentCallbacks2.onTrimMemory() to proactively release caches or scale down memory use when signaled by the OS.
• Automated Stress Testing: Regularly run soak and stress tests that simulate extended usage, background/foreground rapid switching, and large input datasets.

override fun onTrimMemory(level: Int) {
    if (level >= ComponentCallbacks2.TRIM_MEMORY_MODERATE) {
        // Free up in-memory caches, clear bitmap pools, etc.
        imageCache.clear()
    }
}

Key Takeaways and Next Steps​

GC pauses are inevitable, but their impact can be drastically mitigated with disciplined, context-aware memory management. Proactive optimization, rigorous debugging, robust observability, and defensive engineering collectively build critically reliable mobile experiences.

Next steps for your team:

• Audit object allocation and deallocation patterns-single out hot paths.
• Instrument your builds with observability and leak detection from early development to production.
• Encourage “fail early, recover gracefully” approaches to memory errors.
• Bake memory stress into your automated QA workflows.

Building responsive, crash-free Android apps isn’t just about writing correct code-it’s about owning the full lifecycle of memory within your app, from allocation to deallocation, visibility to resilience. Start small, measure often, and empower your team to deliver apps users can trust-even under pressure.

Further Reading:

• Android Performance Patterns - Memory
• LeakCanary Documentation
• Android Profiler Guide

Happy debugging and optimizing!

How to Implement the Decorator Pattern in Jetpack Compose

Jetpack Compose gives you an incredible amount of freedom when building Android UIs. You describe what the UI should look like, and Compose takes care of the rest. But even with this flexibility, there are moments where you want to add behavior or styling around a component - without rewriting it or making it harder to maintain.

That's where the Decorator Pattern fits in beautifully.

The decorator pattern allows you to wrap additional behavior or visual enhancements around an existing component without changing its core implementation. In Jetpack Compose, this aligns perfectly with composable functions and modifiers, letting you layer responsibilities in a clean, reusable, and scalable way.

UI bugs are sneaky. Everything looks fine on your device, animations feel smooth, and then - someone reports that a button doesn't respond, a screen doesn't load, or a critical flow breaks on a specific device. By the time you hear about it, the damage is already done.

This is where UI testing earns its keep.

With Jetpack Compose becoming the standard way to build Android UIs, testing strategies need to evolve as well. Espresso is still a powerful UI testing tool - but testing Compose-based UIs requires a slightly different mindset.

Let's walk through how to test Jetpack Compose UIs using Espresso, step by step, in a way that actually makes sense when you sit down to write tests.

Prerequisites​

Before jumping into writing tests, make sure you have the basics in place:

• An Android project using Jetpack Compose
• Android Studio Arctic Fox or newer
• Basic familiarity with:
  • Jetpack Compose
  • Espresso
  • JUnit
• UI tests enabled in your project (androidTest source set)

If you already have a Compose screen running, you're good to go.

Setting Up Espresso for a Compose Project​

Jetpack Compose doesn't replace Espresso - it complements it. Espresso still handles UI synchronization and assertions, while Compose provides its own testing APIs.

In your app module, make sure you have the required dependencies:

androidTestImplementation 'androidx.test.espresso:espresso-core:<version>'
androidTestImplementation 'androidx.test.ext:junit:<version>'

This setup allows Espresso and Compose Test APIs to work together seamlessly.

Writing Your First Espresso Test with Jetpack Compose​

Let's put theory into practice and write a simple UI test. The goal here isn't to be fancy - it's to understand how Espresso and Jetpack Compose work together in a real test scenario.

We'll create a test that checks whether a button is visible on the screen and then performs a click on it.

Step 1: Create a UI test class​

Start by creating a new Kotlin file inside your app's androidTest directory. You can name it something like ExampleEspressoTest.

This file will hold all your UI test logic.

Step 2: Import the required dependencies​

You'll need imports from both Jetpack Compose testing and Espresso:

import androidx.compose.ui.test.*
import androidx.compose.ui.test.junit4.*
import androidx.test.espresso.Espresso.*
import androidx.test.espresso.matcher.ViewMatchers.*
import org.junit.Rule
import org.junit.Test

These give you access to Compose test rules, UI matchers, and Espresso actions.

Step 3: Set up the Compose test rule​

The test rule is what launches your Compose content in a controlled testing environment:

class ExampleEspressoTest {
    @get:Rule
    val composeTestRule = createComposeRule()
}

This rule tells the test runner how to render Compose UI before running assertions.

Step 4: Write your first test​

Now for the actual test. We'll render a simple button and verify two things:

1. The button is visible
2. The button can be clicked

@Test
fun testButtonVisibilityAndClick() {
    // Launch the Compose screen/activity
    composeTestRule.setContent {
        // Compose UI code here
        Button(
            onClick = { /* Button click action */ }
        ) {
            Text("Click Me")
        }
    }

    // Check if the button is displayed
    onView(withText("Click Me")).check(matches(isDisplayed()))

    // Perform a click action on the button
    onView(withText("Click Me")).perform(click())
}

What's happening here:

• setContent renders a Compose UI just for this test
• Espresso verifies the button exists on screen
• Espresso simulates a real user click

This might look simple - and that's the point. UI tests should clearly describe user behavior, not hide it behind complexity.

Step 5: Run the test​

You can run the test directly from Android Studio or use the test runner to execute it as part of your test suite.

Once it passes, you've officially written and executed your first Espresso test for a Jetpack Compose UI.

From here, you can expand into testing state changes, navigation, error states, and full user flows.

Working with Matchers and Actions​

Even when you're testing Jetpack Compose UI, Espresso's core ideas - matchers and actions - still apply. The difference is what you're interacting with. Instead of traditional View objects, you're now targeting Compose-based UI elements.

Matchers help Espresso find the UI element you care about, while actions define what you want to do with it - just like a real user would.

Commonly Used Matchers​

Matchers are used to locate Compose components based on their properties:

• withText("text") - Finds a composable that displays the given text.
• isDisplayed() - Ensures the composable is currently visible on the screen.

These matchers make your tests readable and expressive, almost like describing what a user sees.

Commonly Used Actions​

Actions simulate user interactions:

• click() - Performs a tap on the matched Compose component.

When combined, matchers and actions let you write tests that read like user behavior:

"Find this button, make sure it's visible, then tap it."

This approach keeps your tests focused on what the user does, not on internal implementation details - which is exactly how good UI tests should behave.

Testing Jetpack Compose Components​

When testing Compose components, you can use the onNode method to target specific components.

For example, to test a Button component:

onNode(hasText("Click Me")).performClick()

Verifying Assertions the Right Way​

Assertions tell you whether your UI behaves as expected. For example:

• isDisplayed(): Checks if the Compose component is currently visible on the screen.
• hasText("text"): Checks if the Compose component contains the specified text.

Conclusion​

Testing Jetpack Compose UI with Espresso isn't complicated - but it does require a shift in how you think about UI testing.

Compose simplifies UI structure.

Espresso ensures stability.

Assertions keep regressions in check.

Together, they help you ship UIs that behave correctly - not just in demos, but on real devices, under real conditions.

Because the best UI bug is the one your users never see.

Happy testing.

Modern Android applications are expected to deliver smooth animations, rich visuals, and real-time graphical effects. However, executing heavy graphical operations on the CPU can quickly lead to performance bottlenecks, increased battery consumption, and poor user experience. For a broader look at tools that can elevate your Android development workflow, check out our guide on 10 Android libraries you really need.

Earlier, Android developers relied on RenderScript for GPU-accelerated workloads. With RenderScript now deprecated, Vulkan has emerged as the most powerful and future-ready alternative for high-performance graphics and compute operations on Android.

In this blog, we'll explore how to utilize GPU capabilities using Vulkan in Kotlin-based Android apps to efficiently handle intensive graphical workloads and unlock next-level performance.

You know that moment when you're rushing to book a cab, the payment is about to go through, and suddenly the app freezes? For a few seconds, you're stuck - did the payment go through or not? Do you retry? Do you close the app? That tiny moment of uncertainty is enough to frustrate most users. And more often than not, they don't come back.

That's exactly how silent damage begins in mobile apps. Not with big disasters-but with small, unexpected failures in moments that matter most. On Android, even one crash in a critical flow like login, checkout, or onboarding can quietly push users away, hurt your ratings, and impact revenue. While no app can ever be completely crash-proof, Kotlin gives you a strong safety net to reduce these risks long before users feel them.

Imagine building a house with your bare hands. Then, someone hands you a toolbox that automates half the work, ensures structural safety, and even paints the walls. That's what the right Android libraries feel like.

You don't just want to write code. You want to write clean, efficient, testable code that doesn't give you a migraine three months later. These 10 libraries? They're your survival kit.

Let's break them down together. I'll show you real examples, sprinkle in some numbers, and tell you exactly why each one deserves a spot in your next Android project. No fluff - just the stuff that actually helps.

Have you ever dated someone who just… wouldn't let go?

You break up, move on, start fresh - and boom - they're still texting, still showing up in your life, refusing to be deleted.

That's your app with a memory leak.

It's holding on to screens, data, and objects long after it should've moved on. You've moved past the Activity, but it's still lingering in memory like a clingy ex who didn't get the memo.

The worst part? You might not even know it's happening.

But users will. They will feel it in the slowdowns, the crashes, the app that once felt smooth now feeling… emotionally unavailable.

And in Android, they're not just annoying. They're dangerous. They can slow down your app, cause freezes, and eventually - boom! A crash.

Let's dive into the most common memory leak scenarios in Android. I'll walk you through real-world examples, show you how to spot them, and most importantly, how to fix them.

The streak broke. So did the flow.

It wasn't that I forgot. I remembered, just a little too late.

Right before midnight, I opened the app to log my progress. But the screen just sat there, trying to connect. No internet. No log. No streak.

It sounds small, but if you've ever built a habit one day at a time, you know what a streak can mean. It's not just numbers. It's proof. And losing it? That stings.

That moment made one thing very clear: apps that help you grow should work with you, not against you, especially when the internet doesn't cooperate.

So let's build something better.

"Hey… why does this screen freeze every time I scroll too fast?"

That's what my QA pinged me at 11:30 AM on a perfectly normal Tuesday.

I brushed it off. "Probably a one-off," I thought.

But then the bug reports started trickling in:

• "The app slows down after using it for a while."
• "Navigation feels laggy."
• "Sometimes it just… dies."

That's when the panic set in.

Ever wondered how big apps manage free vs paid versions, or white-label multiple client apps from a single Android project? The answer is Gradle Flavors.

Imagine you're building an app for a fitness startup. The client loves it. Then they say: "Can we also get a version for our premium users, with extra features and no ads? Oh, and one more version for our corporate partners?"

You smile, and quietly panic.

Do you:

• Copy the codebase three times?
• Manually toggle features before every build?
• Cry?

Nope. You use Gradle Flavors.

You're out for dinner. Ambience? Perfect. Service? Spot on. Then your dish arrives. But something's off. The pasta's missing salt, or the steak's slightly overcooked. You raise your hand to get the waiter's attention. But before you can say a word, they smile and say, "The chef already noticed. A fresh plate is on its way."

It feels like magic. But really, it's just attention to detail before a complaint even happens.

That's the kind of experience your users expect from your app too. Silent problems fixed before they even realize something went wrong.

In today's mobile-first world, users expect apps to work seamlessly, even when there's no internet connection. This blog post will guide you through the process of building an offline-capable Android app using Kotlin and Jetpack Compose. We'll use a ToDo app as our example to illustrate key concepts and best practices.

Architecture Overview​

Before diving into the code, let's outline the architecture we'll use:

• UI Layer: Jetpack Compose for the user interface

• ViewModel: To manage UI-related data and business logic

• Repository: To abstract data sources and manage data flow

• Local Database: Room for local data persistence

• Remote Data Source: Retrofit for API calls (when online)

• WorkManager: For background synchronization

Setting Up the Kotlin Project​

First, ensure you have the necessary dependencies in your build.gradle file:

dependencies {
    implementation("androidx.core:core-ktx:1.10.1")
    implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.6.1")
    implementation("androidx.activity:activity-compose:1.7.2")
    implementation("androidx.compose.ui:ui:1.4.3")
    implementation("androidx.compose.ui:ui-tooling-preview:1.4.3")
    implementation("androidx.compose.material3:material3:1.1.1")
    
    // Room
    implementation("androidx.room:room-runtime:2.5.2")
    implementation("androidx.room:room-ktx:2.5.2")
    kapt("androidx.room:room-compiler:2.5.2")
    
    // Retrofit
    implementation("com.squareup.retrofit2:retrofit:2.9.0")
    implementation("com.squareup.retrofit2:converter-gson:2.9.0")
    
    // WorkManager
    implementation("androidx.work:work-runtime-ktx:2.8.1")
}

Implementing the Local Database​

We'll use Room to store ToDo items locally. First, define the entity:

@Entity(tableName = "todos")
data class ToDo(
    @PrimaryKey val id: String = UUID.randomUUID().toString(),
    val title: String,
    val description: String,
    val isCompleted: Boolean = false,
    val lastModified: Long = System.currentTimeMillis()
)

Next, create the DAO (Data Access Object):

@Dao
interface ToDoDao {
    @Query("SELECT * FROM todos")
    fun getAllToDos(): Flow<List<ToDo>>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertToDo(todo: ToDo)

    @Update
    suspend fun updateToDo(todo: ToDo)

    @Delete
    suspend fun deleteToDo(todo: ToDo)
}

Finally, set up the Room database:

@Database(entities = [ToDo::class], version = 1)
abstract class ToDoDatabase : RoomDatabase() {
    abstract fun todoDao(): ToDoDao

    companion object {
        @Volatile
        private var INSTANCE: ToDoDatabase? = null

        fun getDatabase(context: Context): ToDoDatabase {
            return INSTANCE ?: synchronized(this) {
                val instance = Room.databaseBuilder(
                    context.applicationContext,
                    ToDoDatabase::class.java,
                    "todo_database"
                ).build()
                INSTANCE = instance
                instance
            }
        }
    }
}

Implementing the Repository​

The repository will manage data operations and decide whether to fetch from the local database or the remote API:

class ToDoRepository(
    private val todoDao: ToDoDao,
    private val apiService: ApiService
) {

    val allToDos: Flow<List<ToDo>> = todoDao.getAllToDos()

    suspend fun refreshToDos() {
        try {
            val remoteToDos = apiService.getToDos()
            todoDao.insertAll(remoteToDos)
        } catch (e: Exception) {
            // Handle network errors
        }
    }

    suspend fun addToDo(todo: ToDo) {
        todoDao.insertToDo(todo)
        try {
            apiService.addToDo(todo)
        } catch (e: Exception) {
            // Handle network errors, maybe queue for later sync
        }
    }

    // Implement other CRUD operations similarly
}

Setting Up the ViewModel​

The ViewModel will handle the UI logic and interact with the repository:

class ToDoViewModel(private val repository: ToDoRepository) : ViewModel() {
    val todos = repository.allToDos.asLiveData()
    
	fun addToDo(title: String, description: String) {
        viewModelScope.launch {
            val todo = ToDo(title = title, description = description)
            repository.addToDo(todo)
        }
    }

    fun refreshToDos() {
        viewModelScope.launch {
            repository.refreshToDos()
        }
    }
    // Implement other operations
}

Creating the UI with Jetpack Compose​

Now, let's create the UI for our ToDo app:

@Composable
fun ToDoScreen(viewModel: ToDoViewModel) {
    val todos by viewModel.todos.collectAsState(initial = emptyList())
    LazyColumn {
        items(todos) { todo ->
            ToDoItem(todo)
        }
        item {
            AddToDoButton(viewModel)
        }
    }
}

@Composable
fun ToDoItem(todo: ToDo) {
    Card(
        modifier = Modifier
            .fillMaxWidth()
            .padding(8.dp)
    ) {
        Row(
            modifier = Modifier.padding(16.dp),
            verticalAlignment = Alignment.CenterVertically
        ) {
            Checkbox(
                checked = todo.isCompleted,
                onCheckedChange = { /* Update todo */ }
            )
            Column(modifier = Modifier.weight(1f)) {
                Text(text = todo.title, fontWeight = FontWeight.Bold)
                Text(text = todo.description)
            }
        }
    }
}

@Composable
fun AddToDoButton(viewModel: ToDoViewModel) {
    var showDialog by remember { mutableStateOf(false) }
    Button(onClick = { showDialog = true }) {
        Text("Add ToDo")
    }
    if (showDialog) {
        AddToDoDialog(
            onDismiss = { showDialog = false },
            onConfirm = { title, description ->
                viewModel.addToDo(title, description)
                showDialog = false
            }
        )
    }
}

@Composable
fun AddToDoDialog(onDismiss: () -> Unit, onConfirm: (String, String) -> Unit) {
    // Implement dialog UI here
}

Implementing Background Sync with WorkManager​

To ensure our app stays up-to-date even when it's not actively running, we can use WorkManager for background synchronization:

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {
    private val repository = ToDoRepository(
        ToDoDatabase.getDatabase(context).todoDao(),
        ApiService.create()
    )
    override suspend fun doWork(): Result {
        return try {
            repository.refreshToDos()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

Schedule the work in your application class or main activity:

class ToDoApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        setupPeriodicSync()
    }

    private fun setupPeriodicSync() {
        val constraints = Constraints.Builder()
            .setRequiredNetworkType(NetworkType.CONNECTED)
            .build()

        val syncRequest = PeriodicWorkRequestBuilder<SyncWorker>(1, TimeUnit.HOURS)
            .setConstraints(constraints)
            .build()

        WorkManager.getInstance(this).enqueueUniquePeriodicWork(
            "ToDo_Sync",
            ExistingPeriodicWorkPolicy.KEEP,
            syncRequest
        )
    }
}

Handling Conflicts​

When working offline, conflicts may arise when syncing data. Implement a conflict resolution strategy:

suspend fun syncToDo(todo: ToDo) {
    try {
        val remoteToDo = apiService.getToDo(todo.id)
        if (remoteToDo.lastModified > todo.lastModified) {
            // Remote version is newer, update local
            todoDao.insertToDo(remoteToDo)
        } else {
            // Local version is newer, update remote
            apiService.updateToDo(todo)
        }
    } catch (e: Exception) {
        // Handle network errors
    }
}

Testing Offline Functionality​

To ensure your app works offline:

• Implement a network utility class to check connectivity.

• Use this utility in your repository to decide whether to fetch from local or remote.

• Write unit tests for your repository and ViewModel.

• Perform UI tests with network on and off to verify behavior.

Conclusion​

Building an offline-capable Android app requires careful consideration of data flow, synchronization, and conflict resolution. By using Room for local storage, Retrofit for API calls, and WorkManager for background sync, you can create a robust offline experience for your users.

Remember to handle edge cases, such as first-time app usage without internet, and always provide clear feedback to users about the sync status of their data.

Would you like me to explain or break down any part of this code?

What is Gemini Nano​

Gemini Nano is an efficient AI model for on device tasks according to Google. With Gemini Nano, developers will be able to deliver rich generative AI experiences without requiring a network connection or moving data off-device. Gemini Nano is ideal for use cases where low latency, low cost, and privacy safeguards are paramount.

Architecture​

To handle AI services, Android OS has introduced a new module called AICore. It is available in Android 14.

AICore, a brand new system service that simplifies using AI features in your apps. AICore takes care of everything behind the scenes, from managing AI models to ensuring their safe operation on your device. AICore lets your apps run powerful AI models like Gemini Nano directly on your device. This means faster processing compared to sending data to the cloud.

Gemini Nano and AICore Architecture - Image from Google

AICore prioritizes Privacy​

Limited Connections:  AICore operates in a restricted environment, only interacting with essential system functions. This isolation helps prevent unauthorized access to your data by other other apps.

• Secure Downloads: AICore doesn't directly access the internet. Instead, it relies on a separate, privacy-focused app (Private Compute Services) to download any required models. This ensures your information stays secure during the download process.

Getting Started with Gemini Nano​

You will need Google AI Edge SDK for Android to work with Gemini Nano. This SDK provides APIs for interacting with the model and managing its functionalities.

Currently the SDK is available only for private review and is not available for public, but soon it will be.

Compatibility Check​

Not all Android devices support Gemini Nano. Hence you need to run a compatibility check in your code.

fun isDeviceSupported(): Boolean {
  val edgeManager = AiEdgeManager.getInstance(context)
  return edgeManager.isModelSupported(GeminiNano.MODEL_NAME)
}

Accessing Gemini Nano​

Once you've confirmed compatibility, you can obtain an instance of the GeminiNano class using the AIEdgeManager in AI Edge SDK:

val geminiNano = AiEdgeManager.getInstance(context).getAiModel(GeminiNano.MODEL_NAME) as GeminiNano

Example: Sentiment classification​

Gemini Nano claims it is good in performing inference on data. Let's run a piece of text and infer the sentiment score.

val text = "I'm happy to meet you again."
val i = TextInput.Builder().setText(text).build()
val o = geminiNano.runInference(i) as TextClassificationOutput
val sentimentClassification = o.classification

Pretty straight forward. The model classifies the sentiment and stores in a variable.

Gemini Nano UseCases​

Comming back to Gemini Nano, here are some of the use cases of the model that can be put to use by developer once it is out of private beta.

• Get smarter summaries:  Gemini Nano can condense lengthy articles or reports into easy-to-understand summaries, saving you time.

• Find answers fast:  Have questions? Ask away! Gemini Nano can analyze text and provide relevant answers.

• Write with confidence:  Gemini Nano helps you polish your writing with features like grammar correction, proofreading, and writing suggestions. It can even generate smart replies based on the context.

• Analyze emotions:  Understand the sentiment behind text.  Gemini Nano can detect the overall mood or feeling expressed in writing.

• Built-in privacy:  Use powerful AI features without compromising your data.  Gemini Nano is designed with privacy in mind.

Already on Pixel:  Several Google Pixel apps, like Voice Recorder and Gboard, leverage the power of AICore to enhance your experience.