//pragmatic leaders

App Development: Android Mobile Apps

Reading time
5 min
Section
Technology for Product Manager
5 min left0%
app development: android mobile apps0%
5 min left
Understanding the technology behind your product is not optional. It is what separates a PM who manages timelines from a PM who owns outcomes.
Talvinder Singh, from a Pragmatic Leaders session on mobile product management

Building an Android mobile app is a complex process involving multiple layers of technology and design decisions. As a product manager, your actual job is to understand these layers well enough to make informed trade-offs and align your roadmap with what engineering can realistically deliver.

The stakes are high. If you treat mobile app development as a black box, you risk unrealistic timelines, poor user experience, and costly rework. This lesson breaks down the Android app development ecosystem with the clarity you need to own the product outcomes confidently.

The Android app architecture stack

Android apps are built on a layered architecture, each with distinct responsibilities:

  • Application layer: The UI, user interactions, and app logic you see and use.
  • Framework layer: The APIs and services Android provides to apps.
  • Runtime: The Android Runtime (ART) executes app code.
  • Linux kernel: The foundation handling hardware access, security, and process management.

Understanding these layers helps you grasp where performance bottlenecks or security issues originate. For example, a sluggish UI might be due to inefficient app logic, or it might stem from slow API calls in the framework layer.

// scene:

Sprint planning at a Bangalore-based fintech startup

Engineering Lead: “The new payment flow is lagging on older Android devices. We suspect the ART garbage collector is triggering too often.”

You (PM): “What options do we have? Can we simplify the flow or optimize memory usage?”

Engineering Lead: “Yes, but it means dropping some animations and caching fewer objects. It will improve performance but the experience will be less polished.”

You (PM): “Let's prioritize performance for now. We can revisit animations in the next release.”

The PM balances user experience with technical feasibility, making a call no one else can.

// tension:

Balancing smooth user experience against device limitations and engineering effort

Key Android development tools and languages

Android development primarily uses:

  • Kotlin and Java: The official languages for writing Android apps. Kotlin is now preferred due to its succinct syntax and modern features.
  • Android Studio: The integrated development environment (IDE) with debugging, profiling, and UI design tools.
  • Gradle: The build system managing dependencies and packaging.
  • Emulators and physical devices: For testing across versions and hardware profiles.

As a PM, knowing these tools helps in understanding developer velocity and risks. For example, a team new to Kotlin might move slower initially, impacting your roadmap.

The app lifecycle and state management

Android apps have a defined lifecycle with states like created, started, resumed, paused, stopped, and destroyed. Managing state transitions correctly is critical for smooth user experience and avoiding crashes.

Your engineering team will handle this, but you must understand the implications:

  • Backgrounding: When a user switches apps, your app may be paused or stopped. Features like downloads or notifications must handle these transitions gracefully.
  • Configuration changes: Rotating the device or changing language triggers activity recreation. UI and data must be preserved correctly.

Mismanaging lifecycle events leads to bugs that frustrate users and increase support costs.

Trade-offs in mobile app development you must own

Mobile development is full of trade-offs between:

  • Performance vs. battery life: Heavy background processing drains battery but can provide better real-time updates.
  • Feature richness vs. app size: More features increase download size and memory usage, impacting users on low-end devices.
  • Native vs. cross-platform: Native Android apps offer better performance but require separate codebases for iOS. Cross-platform frameworks like Flutter speed up development but can introduce platform-specific bugs.

Your job is to evaluate these trade-offs in the context of your user base and business goals.

// thread: #mobile-product — Feature trade-off discussion
Neha (PM)Our analytics show 40% of users are on devices with less than 2GB RAM. Should we cut the AR feature to improve performance?
Raj (Engineering)Removing AR reduces app size by 15% and improves launch time by 30%. But AR is a key differentiator.
Meera (Design)Can we keep a lightweight AR mode with fewer effects?
You (PM)Let's prototype the lightweight mode and test with a subset of users in Pune and Hyderabad before deciding.

Testing and quality assurance in Android apps

Testing mobile apps is challenging due to device fragmentation across Android versions, screen sizes, hardware capabilities, and manufacturer customizations.

Your team will implement:

  • Unit tests for code correctness.
  • UI tests using frameworks like Espresso.
  • Beta testing with real users on platforms like Google Play Console.
  • Crash and performance monitoring with tools like Firebase Crashlytics.

You must ensure testing is part of the definition of done and that quality metrics are part of your release criteria. Shipping buggy apps erodes user trust and retention.

Releasing and updating Android apps

Android apps are distributed via the Google Play Store, with a review process that usually takes a few hours to a couple of days. Key considerations:

  • Versioning: Semantic versioning helps users and support teams track releases.
  • Staged rollouts: Gradually releasing updates to a percentage of users helps catch issues early.
  • Backward compatibility: New app versions must continue working on older devices your users have.

Release cadence is a planning input for your roadmap. Frequent small updates reduce risk but increase overhead; infrequent large updates increase risk of regressions.

The Indian mobile ecosystem context

India's Android users are diverse:

  • Device capabilities range from flagship phones in Mumbai to entry-level devices in tier-3 towns.
  • Network conditions vary widely, with many users on 2G or 3G.
  • App size and data usage are critical concerns.
  • Multilingual support is essential for adoption beyond metros.

Companies like Swiggy and Razorpay succeed by optimizing for this diversity — small app size, offline modes, vernacular languages.

// exercise: · 15 min
Map your user device profile
  1. Analyze your app's existing user data or market research to create a profile of device types, Android versions, and network conditions your users have.
  2. Identify the lowest common denominator device your app must support.
  3. List features that might need to be disabled or optimized for low-end devices.
  4. Propose a testing plan that covers these critical device segments.

Collaborating with engineering teams effectively

Your role is not to code but to understand enough to:

  • Prioritize technical debt and infrastructure work alongside features.
  • Understand engineering estimates and trade-offs.
  • Translate user needs into clear acceptance criteria.
  • Facilitate communication between design, QA, and engineering.

Building trust with your engineering lead means respecting their expertise while holding them accountable to product outcomes.

Test yourself: The feature freeze dilemma

// learn the judgment

You are PM at a Series A healthtech startup in Bangalore. Engineering reports that a critical bug affecting app stability on low-end Android phones will delay the new symptom checker feature by two weeks. The CEO wants the feature launched next week for an investor demo.

The call: How do you handle this conflict between quality and launch timeline?

Your reasoning:

// practice

You are PM at a Series A healthtech startup in Bangalore. Engineering reports that a critical bug affecting app stability on low-end Android phones will delay the new symptom checker feature by two weeks. The CEO wants the feature launched next week for an investor demo.

Your task: How do you handle this conflict between quality and launch timeline?

your reasoning:

0 chars (min 80)

Where to go next