Mobile app development basics

In short

Mobile app development is the building of software that runs on handheld devices — Android and iOS phones and tablets — covering the UI, the device APIs (camera, GPS, sensors, storage), the network layer that talks to a server, and the store release process. India has over 80 crore smartphone users and almost every service (banking, UPI payments, ticketing, government ID, food delivery, learning) ships as an app first, so this is the single largest employer of BCA graduates among application-development roles. University syllabi (AICTE/CBCS "Mobile Application Development" or "Android Programming" papers) examine the Android architecture, the Activity lifecycle, layouts, Intents, SQLite/Room persistence and the publishing cycle. Placement rounds ask lifecycle sequences, native-versus-hybrid trade-offs, permission handling and one small coding task; exact SDK versions and store policies change every year, so treat version numbers as indicative and check the current Android/Play documentation.

Explained

Platforms, app types and how they differ

• Native app: written for one platform with its own SDK — Android (Kotlin/Java, Android Studio) or iOS (Swift/Objective-C, Xcode). Best performance, full device access, platform-native look.
• Cross-platform (compiled): one codebase, near-native output — Flutter (Dart, draws its own widgets via the Skia/Impeller engine), React Native (JavaScript/TypeScript, maps to native views), .NET MAUI, Kotlin Multiplatform (shares business logic, native UI).
• Hybrid (WebView): HTML/CSS/JS packaged in a native shell — Apache Cordova, Ionic, Capacitor. Cheapest, weakest performance for animation and heavy lists.
• Progressive Web App (PWA): a website with a service worker and manifest that installs to the home screen, works offline and sends push (limited on iOS). No store needed; no deep device access.
• Instant/lite apps: Android App Bundle feature modules or a small "Lite" build — important in India for low-RAM phones and costly data (Flipkart Lite, Facebook Lite style builds).
• Choice rule of thumb: heavy graphics/AR/device-level work → native; a form-and-list business app on both platforms with one small team → Flutter or React Native; content-only → PWA.

Android platform architecture and project anatomy

• Stack (bottom-up): Linux kernel (drivers, power, security) → hardware abstraction layer (HAL) → native C/C++ libraries + ART (Android Runtime, ahead-of-time compiling DEX bytecode; replaced Dalvik) → Java API framework (Activity Manager, Window Manager, Content Providers, Resource Manager, Notification Manager) → system and user apps.
• Build flow: Kotlin/Java source → .class → D8/R8 → DEX → packaged with resources into APK; for the Play Store you upload an AAB (Android App Bundle) and Google generates device-specific APKs (split by density, ABI, language) — AAB is mandatory for new apps on Play.
• Gradle is the build system; build.gradle(.kts) declares compileSdk, minSdk, targetSdk, versionCode, versionName and dependencies. versionCode is an integer that must increase with every upload.
• Project folders: java/ or kotlin/ (code), res/layout (XML layouts), res/values (strings.xml, colors, themes), res/drawable, res/mipmap (icons), res/menu, and AndroidManifest.xml.
• AndroidManifest.xml declares the package, every component (activities, services, receivers, providers), permissions, the launcher intent-filter, hardware features and SDK levels. A component not declared here cannot run.
• Resource qualifiers give alternative resources by configuration: values-hi (Hindi), layout-land, drawable-xxhdpi, values-night. Densities: ldpi/mdpi/hdpi/xhdpi/xxhdpi/xxxhdpi — mdpi (160 dpi) is the baseline where 1 dp = 1 px.

The four app components, Intents and the lifecycle

• Activity: one screen with a UI. Service: long-running background work with no UI (now usually a foreground service with a notification, or WorkManager for deferrable jobs). Broadcast Receiver: responds to system or app-wide events (boot completed, connectivity change). Content Provider: exposes structured data to other apps via a content:// URI (contacts, media store).
• Fragment: a reusable portion of UI hosted inside an Activity, with its own lifecycle; the basis of the single-Activity + Navigation component architecture.
• Intent: the message object that starts components. Explicit names the target class (Intent(this, SecondActivity::class.java)); implicit names an action and lets the system resolve it (ACTION_VIEW, ACTION_DIAL, ACTION_SEND) — the system shows a chooser if several apps match the intent-filter.
• Data travels in extras (putExtra/getStringExtra); results come back through the Activity Result API (registerForActivityResult), which replaced startActivityForResult/onActivityResult.
• Activity lifecycle callbacks in order on launch: onCreate → onStart → onResume (running). On partial obscuring: onPause. On going fully hidden: onStop. On return: onRestart → onStart → onResume. On finish or system kill: onDestroy.
• Configuration change (rotation) destroys and recreates the Activity: onPause → onStop → onSaveInstanceState → onDestroy → onCreate(bundle) → onStart → onRestoreInstanceState → onResume. Transient UI state goes in the Bundle; real state belongs in a ViewModel (survives rotation) or a database.
• Task and back stack: activities stack within a task; launch modes standard, singleTop, singleTask, singleInstance control reuse.

UI: layouts, views, lists and Compose

• Classic view system: XML layout inflated into a View hierarchy; access views by View Binding (type-safe, replaces findViewById and the deprecated Kotlin synthetics).
• Layout managers: LinearLayout (row/column with weight), RelativeLayout (legacy, position relative to siblings), **ConstraintLayout** (flat hierarchy, constraints + guidelines — the recommended default), FrameLayout, ScrollView, GridLayout, CoordinatorLayout for scrolling behaviour.
• Common widgets: TextView, EditText, Button, ImageView, CheckBox, RadioGroup, Switch, Spinner, ProgressBar, SeekBar, Toast, Snackbar, AlertDialog, BottomNavigationView, Toolbar, TabLayout + ViewPager2.
• RecyclerView shows long lists efficiently: an Adapter binds data to a ViewHolder (which caches view references), a LayoutManager positions items, and off-screen views are recycled — it replaced ListView, whose convertView recycling was manual.
• Units: use dp for all sizes and margins, sp for text (it scales with the user's font-size setting), never raw px. Use 0dp with constraints or weights to let a view stretch.
• Jetpack Compose is the modern declarative toolkit: @Composable functions describe UI, state lives in remember/mutableStateOf, and recomposition redraws only what changed; no XML. Flutter's widget tree and React Native's JSX follow the same declarative model.
• Material Design 3 gives the component set, theming and dynamic colour; support dark theme, RTL mirroring and TalkBack accessibility (content descriptions, 48 dp touch targets).

Data, networking and background work

• Storage options: SharedPreferences/DataStore (key-value settings), internal app-private files, external/shared storage via MediaStore and Scoped Storage (direct file-path access to other apps' files is blocked from Android 10/11), SQLite (bundled relational DB), Room (an ORM over SQLite with @Entity, @Dao, @Database and compile-time query checking), and cloud (Firebase Firestore, a REST backend).
• Networking: Retrofit over OkHttp for REST + JSON (Gson/Moshi/kotlinx.serialization), or Volley/Ktor. Network calls must never run on the main thread — Android throws NetworkOnMainThreadException.
• Threading: the main (UI) thread must stay free; blocking it beyond ~5 s triggers an ANR. Use Kotlin coroutines (viewModelScope.launch, Dispatchers.IO, suspend), or RxJava/Executors in older code. UI updates happen back on the main dispatcher.
• Deferred/background: WorkManager for guaranteed work with constraints (charging, unmetered network) that survives reboot; AlarmManager for exact-time triggers; foreground service for user-visible ongoing work; Firebase Cloud Messaging (FCM) for push. Doze mode and App Standby restrict background work when the device is idle.
• Architecture: MVVM is the standard — View (Activity/Fragment/Composable) ↔ ViewModel (LiveData/StateFlow, no Android context) ↔ Repository ↔ data sources; MVC and MVP are the exam-level alternatives. Dependency injection via Hilt/Dagger or Koin.

Permissions, security and Indian legal compliance

• Normal permissions (INTERNET, VIBRATE) are granted at install; dangerous permissions (camera, location, contacts, microphone) need a runtime request — checkSelfPermission → requestPermissions/registerForActivityResult(RequestPermission()) → handle grant, denial and "don't ask again". Location can be granted as precise, approximate or only this time.
• Declare the minimum: Play requires a Data safety declaration and special justification for sensitive permissions (all-files access, background location, SMS/call log, AD_ID); Android 13+ needs POST_NOTIFICATIONS.
• Security basics: HTTPS/TLS only (cleartext is blocked by default via the network security config), store tokens in EncryptedSharedPreferences or the Android Keystore, never hardcode API keys or secrets in the APK, validate on the server, enable R8 minification/obfuscation, use Play Integrity API against tampering, and sign with Play App Signing (upload key + Google-held app signing key).
• Indian law and practice: the Digital Personal Data Protection Act, 2023 (DPDP Act) governs personal data in apps — notice in clear language, free and specific consent, purpose limitation, data-principal rights (access, correction, erasure, grievance redressal), a Consent Manager, and stricter handling for children under 18 (verifiable parental consent, no behavioural advertising to children). The DPDP Rules were notified on 13 November 2025 with phased commencement: Consent Manager registration from 13 November 2026, and these app-facing duties and rights from 13 May 2027 (until then IT Act s.43A and the SPDI Rules 2011 govern).
• Payments must use a PCI-DSS-compliant gateway (Razorpay, PayU, Cashfree, CCAvenue) or UPI intent/collect flows under NPCI specifications; RBI rules bar apps from storing full card numbers — use tokenisation (CoF tokens). RBI's digital-lending directions require loan apps to disclose the regulated entity and use only its named apps.
• Other applicable rules: the Information Technology Act, 2000 (Section 43A/72A liability, CERT-In incident reporting directions), TRAI DLT registration for transactional SMS, and Google Play/App Store policy (target API level minimums, in-app billing for digital goods, India-specific provisions on alternative billing). Government apps (DigiLocker, UMANG, Aadhaar eKYC) additionally follow MeitY/UIDAI guidelines and Aadhaar Act limits.

Testing, performance, publishing and monetisation

• Testing pyramid: JUnit + Mockito unit tests → Robolectric/Room in-memory integration tests → Espresso (Android) / Flutter integration_test UI tests → Firebase Test Lab / real-device matrix. Monkey/stress testing for crashes.
• Debug tools: Logcat, Android Studio Profiler (CPU, memory, network, energy), Layout Inspector, StrictMode, LeakCanary for memory leaks, adb (adb install, adb logcat, adb shell).
• Performance for the Indian market: small APK/AAB download size, image compression and WebP/AVIF, lazy loading, caching for offline-first use on 2G/3G edges, graceful behaviour on 2 GB-RAM devices, battery- and data-saver awareness, and support for Indic languages and fonts.
• Release steps: set versionCode/versionName → build signed AAB → create the Play Console listing (title, short/full description, screenshots, 512×512 icon, feature graphic, content rating questionnaire, target audience, data-safety form, privacy policy URL) → internal/closed/open testing track → staged rollout → monitor Android vitals (crash rate, ANR rate) and reviews. Play requires a one-time developer registration fee (about US$25) and iOS an annual Apple Developer Program fee (about US$99) — verify current amounts.
• Monetisation: paid app, in-app purchases/subscriptions through Google Play Billing, ads (AdMob), freemium, or a commission/SaaS backend. GST applies to app and in-app sales in India at the applicable slab (standard services rate 18% under the 5%/18%/40% structure effective 22 September 2025); the platform handles some collections — confirm the current treatment with a tax advisor.

Key points

• Native vs hybrid - native gives best performance and full device APIs; hybrid/cross-platform gives one codebase and lower cost.
• AndroidManifest.xml - declares components, permissions and the launcher activity; undeclared components cannot start.
• Four components - Activity (UI), Service (background), Broadcast Receiver (events), Content Provider (shared data).
• Intent - explicit (named class) or implicit (action resolved by intent-filter); carries data in extras.
• Lifecycle on start - onCreate → onStart → onResume; on exit onPause → onStop → onDestroy.
• Rotation - destroys and recreates the Activity; save transient state in the Bundle, real state in a ViewModel or DB.
• ConstraintLayout - flat, constraint-based layout that is the recommended default over nested LinearLayouts.
• RecyclerView - Adapter + ViewHolder + LayoutManager; recycles off-screen item views for smooth long lists.
• dp and sp - dp for sizes (density-independent, 1 dp = 1 px at 160 dpi), sp for text so it respects user font size.
• ART - ahead-of-time Android Runtime that executes DEX bytecode; replaced Dalvik's JIT-only model.
• APK vs AAB - APK is the installable package; AAB is the Play upload format from which Google builds optimised APKs.
• Room - compile-time-checked ORM over SQLite using @Entity, @Dao and @Database.
• Coroutines - run network and disk work off the main thread; blocking the UI thread about 5 s causes an ANR.
• WorkManager - guaranteed, constraint-aware deferrable background work that survives app death and reboot.
• Runtime permissions - dangerous permissions must be requested at use time and denial handled gracefully.
• DPDP Act, 2023 - requires clear notice, specific consent, purpose limitation and data-principal rights in Indian apps.
• Play App Signing - upload key signs the AAB; Google holds the app signing key; versionCode must always increase.
• MVVM - View ↔ ViewModel (StateFlow/LiveData) ↔ Repository ↔ data source; keeps Android context out of logic.

Formulas and examples

Example 1 — dp to px on an Indian mid-range phone. A phone is 1080 × 2400 px on a 6.5-inch diagonal.

• Diagonal pixels = √(1080² + 2400²) = √(1,166,400 + 5,760,000) = √6,926,400 ≈ 2631.8 px.
• dpi = 2631.8 / 6.5 ≈ 404.9 dpi → nearest bucket xxhdpi (480 dpi nominal, density ≈ 3.0 as reported).
• A 48 dp touch target at the true density = 48 × (404.9/160) = 48 × 2.531 ≈ 121 px; at the xxhdpi bucket value 3.0 it would be 144 px.
• Layout width in dp = 1080 / 3.0 = 360 dp — the standard "small phone" design width.

Example 2 — AAB size saving. A universal APK is 28 MB: 9 MB code for four ABIs (arm64, armeabi-v7a, x86, x86_64 — about 2.25 MB each), 10 MB drawables across six densities, 9 MB other assets. An arm64 xxhdpi device needs 2.25 MB of code and roughly 10/6 ≈ 1.67 MB of drawables.

• Delivered split ≈ 2.25 + 1.67 + 9 = 12.92 MB.
• Saving = (28 − 12.92)/28 × 100 ≈ 53.9% smaller download — the reason AAB matters on metered Indian data plans.

Example 3 — lifecycle trace. User opens the app, presses Home, returns, rotates the phone, presses Back:

Example 4 — in-app purchase economics. An app sells a ₹499 (GST-inclusive) annual subscription to 2,000 Indian users; Play commission on subscriptions is 15% from the first sale (one-time in-app purchases are 15% on the first US$1 million of annual earnings, 30% above it; rates and tiers change — verify current terms); GST 18%.

• Gross = 499 × 2,000 = ₹9,98,000.
• Net of 18% GST: 9,98,000 / 1.18 = ₹8,45,762 (GST component ₹1,52,238).
• Less 15% store fee on the gross: 0.15 × 9,98,000 = ₹1,49,700 → developer retains ≈ 8,45,762 − 1,49,700 = ₹6,96,062 before income tax and hosting.

Example 5 — minimal Android code. Launching a second screen with data and a lifecycle hook:

class MainActivity : AppCompatActivity() {
    private lateinit var b: ActivityMainBinding
    override fun onCreate(s: Bundle?) {
        super.onCreate(s)
        b = ActivityMainBinding.inflate(layoutInflater)
        setContentView(b.root)
        b.btnNext.setOnClickListener {
            startActivity(Intent(this, DetailActivity::class.java)
                .putExtra("rollNo", b.etRoll.text.toString()))
        }
    }
    override fun onPause() { super.onPause(); Log.d("LIFE", "paused") }
}
// DetailActivity: val roll = intent.getStringExtra("rollNo") ?: "-"

<!-- AndroidManifest.xml essentials -->
<uses-permission android:name="android.permission.INTERNET"/>
<activity android:name=".MainActivity" android:exported="true">
  <intent-filter>
    <action android:name="android.intent.action.MAIN"/>
    <category android:name="android.intent.category.LAUNCHER"/>
  </intent-filter>
</activity>
<activity android:name=".DetailActivity"/>

Where it is used

• Fintech and payments: UPI apps and wallets (PhonePe, Paytm, BHIM-based apps), bank apps (SBI YONO, HDFC, ICICI iMobile) — Android/iOS native with tokenisation, device binding and SMS/UPI intent flows.
• Commerce, travel and delivery: Flipkart, Myntra, Zomato, Swiggy, IRCTC Rail Connect, Ola/Uber — maps, location permissions, offline caching and lite builds for low-end devices.
• Government and public services: UMANG, DigiLocker, mAadhaar, CoWIN-style health apps, state police and transport apps — built by NIC/MeitY or vendors under UIDAI/MeitY guidelines.
• Edtech and health: BYJU'S, Unacademy, PhysicsWallah, Practo, teleconsultation and ABDM-linked apps — video streaming, downloads for offline study, DPDP-compliant consent.
• Enterprise and field apps: sales-force, attendance, logistics, meter-reading and microfinance collection apps built in Flutter or React Native by IT services firms (TCS, Infosys, Wipro, Cognizant, Accenture, LTIMindtree) and GCCs.
• Job roles: Android Developer (Kotlin), iOS Developer (Swift), Flutter/React Native Developer, Mobile QA/Automation Engineer, Mobile App Support, Mobile UI/UX Designer, and freelance app development for local businesses.

Interview questions

• Q: What is the difference between an Activity and a Fragment? A: An Activity is an independent screen with its own entry in the manifest and task stack; a Fragment is a reusable UI portion with its own lifecycle that must be hosted inside an Activity.
• Q: Give the Activity lifecycle callbacks when the device is rotated. A: onPause → onStop → onSaveInstanceState → onDestroy → onCreate → onStart → onRestoreInstanceState → onResume, because the Activity is destroyed and recreated for the new configuration.
• Q: Explicit versus implicit Intent? A: An explicit Intent names the exact component class to start; an implicit Intent states an action and data, and the system picks a matching app through intent-filters, showing a chooser if several match.
• Q: Why is RecyclerView preferred over ListView? A: It enforces the ViewHolder pattern, recycles off-screen views automatically, separates positioning into a pluggable LayoutManager, and supports item animations and DiffUtil updates.
• Q: What causes an ANR and how do you avoid it? A: Blocking the main thread for roughly 5 seconds (or a broadcast beyond about 10 seconds); avoid it by moving network, database and file work to coroutines or background executors.
• Q: Difference between dp and sp? A: Both are density-independent, but sp additionally scales with the user's font-size accessibility setting — so use sp only for text and dp for everything else.
• Q: APK or AAB — which do you upload to Play and why? A: An AAB; Google Play generates optimised split APKs per device density, ABI and language, which cuts the download size substantially, and AAB is mandatory for new apps.
• Q: How do you request a dangerous permission correctly? A: Check with checkSelfPermission, request at the point of use with the Activity Result permission contract, explain why with a rationale if previously denied, and keep the feature degraded-but-usable if permission is refused.
• Q: Where should an API key or auth token be kept in an Android app? A: Never hardcoded in source or committed — keep secrets on the server, proxy sensitive calls, and store issued tokens in EncryptedSharedPreferences or the Android Keystore.
• Q: What does the DPDP Act, 2023 require of a consumer app in India? A: A clear, itemised notice and free, specific, informed consent before processing personal data, use limited to the stated purpose, security safeguards, breach notification, a grievance channel, and rights of access, correction and erasure for users - in force from 13 May 2027 under the DPDP Rules 2025.
• Q: When would you choose Flutter over native Android? A: When one small team must ship a largely form-and-list app to both Android and iOS quickly with a consistent UI; native is better when the app is driven by platform SDKs, heavy graphics, or newest OS features.
• Q: What is WorkManager and how does it differ from a Service? A: WorkManager schedules deferrable, guaranteed work with constraints that persists across process death and reboot; a foreground Service runs immediate, user-visible work now with a mandatory notification.
• Q: How does a ViewModel survive rotation when the Activity does not? A: It is retained by the ViewModelStore scoped to the Activity's lifecycle owner, which outlives configuration-change recreation and is cleared only when the Activity finishes for good.

Common mistakes

• Writing lifecycle callbacks in the wrong order in exams — forgetting onRestart on return, or omitting onSaveInstanceState in the rotation sequence.
• Doing network or SQLite work on the main thread, then blaming the framework for the crash or ANR.
• Forgetting to declare an activity, service or permission in AndroidManifest.xml, or missing android:exported on components with intent-filters (mandatory from Android 12).
• Using px instead of dp/sp, and testing on one emulator only — layouts then break on small, large and high-density screens.
• Keeping state in Activity fields and losing it on rotation, or holding a Context/Activity reference inside a ViewModel or static field, causing memory leaks.
• Declaring every permission "just in case" and requesting them all at launch — users deny them and Play may reject the listing or data-safety form.
• Hardcoding API keys, test credentials or server URLs in the APK, and uploading an unsigned or non-incremented versionCode build to Play.
• Claiming to have handled the permission-denied path in interviews without having written the "don't ask again" branch.

Related topics

REST APIs · Front-end frameworks: React basics · Web fundamentals: HTML, CSS and JavaScript · Cloud computing basics · E-commerce systems · Database management with SQL