Android app development: A Practical 2026 Guide

TL;DR: Android app development in 2026 starts with Kotlin, Jetpack Compose and Android Studio. Build a small native app, keep permissions to a minimum, test on several screen sizes and target at least Android 16, API 36, for upcoming Google Play submissions. You do not need root or an unlocked bootloader.

By the PrivacyPortal team

Last updated August 2026

For most new projects, use Kotlin for logic and Jetpack Compose for the interface. Keep data on the device unless a feature truly needs a server. Use a layered design so screens, business rules and storage remain separate. Android 17 is stable, but API 37 is not yet the minimum Google Play target. From 31 August 2026, new mobile apps and updates must target Android 16, API 36, or later.

Back up any test device before changing its software. Normal app development does not require bootloader unlocking or flashing. If you choose to modify your own device, unlocking usually wipes all data. It can also affect security, warranty support, over-the-air updates, banking apps and Play Integrity.

What Android app development looks like in 2026

Modern Android app development is centred on Kotlin and Jetpack Compose. Kotlin is the main language used for new native apps. Compose is Android’s declarative user-interface toolkit. You describe the current screen state, and Compose updates the visible elements.

Android Studio remains the standard development environment. Install its current stable release and let it create the project’s compatible build-tool versions. Avoid copying an old combination of Kotlin, Compose and the Android Gradle Plugin from a tutorial.

Use JDK 17 where required by the project’s Android Gradle Plugin. For the August 2026 Play deadline, set targetSdk to at least 36. You may compile against Android 17, API 37, when your libraries support it. Test API 37 behaviour changes before raising targetSdk.

Google Play requires new mobile apps and app updates to target Android 16, API 36, or later from 31 August 2026.

Check the official Google Play target API requirements before each release. Deadlines and exceptions can change.

Caption: Android Studio showing a Kotlin and Jetpack Compose project with its app, test and Gradle files.

Choose the right development approach

Native Kotlin is the safest default for an Android-first product. It gives direct access to platform security, background work and adaptive layouts. Other approaches remain useful when code sharing matters more than complete platform control.

Approach	Best fit	Main advantage	Main trade-off
Kotlin and Compose	Android-first apps	Direct platform access and strong tooling	Android code does not become an iOS app
Compose Multiplatform	Shared Kotlin products	Can share logic and parts of the interface	Platform work is still needed
Flutter	One team serving several platforms	Large shared interface layer	Extra framework and platform bridges
Web wrapper	Simple existing web services	Fast reuse of web work	Weaker platform fit and offline support

A decision rule helps. Choose native Kotlin when the app uses Bluetooth, secure storage, background tasks or detailed accessibility support. Consider cross-platform code for a simple service with matching Android and iOS screens. Use a web wrapper only when the product is genuinely web-led.

How to build and run a private notes app

This tutorial creates Permission Notes, a small offline Compose app with no requested Android permissions.

1. Install the current stable Android Studio release. Add the Android 16, API 36, SDK platform through SDK Manager.
2. Select New Project, then Empty Activity. Name the app Permission Notes and choose Kotlin.
3. Set a practical minimum SDK, such as API 26, unless your users or dependencies need another level. Set targetSdk to at least 36.
4. Keep MainActivity.kt as the app entry point. Create PermissionNote.kt for the note model.
5. Create PermissionNotesScreen.kt. Add a text field, a save button and a list of saved notes using Compose components.
6. Create PermissionNotesViewModel.kt. Hold screen state there instead of placing app logic inside the activity.
7. Create PermissionNotesRepository.kt. Store notes locally with Room rather than sending them to a server.
8. Check AndroidManifest.xml. Remove permissions that the app does not need, including network access if every feature is offline.
9. Add a ViewModel unit test and a Compose interface test. Test an empty note, a saved note and state after rotation.
10. Run the debug build on an emulator and one physical device. Reinstall it once to confirm the database opens cleanly.

Prerequisites and project settings

You need Android Studio, its bundled or supported JDK, the Android SDK and about 10 GB of free space. Hardware virtualisation makes the emulator much faster. A physical phone is useful but not required.

Use the versions generated by the current stable project template. Keep them in the Gradle version catalogue. This avoids a common failure where Compose, Kotlin and compiler plug-ins do not match.

Room is the Jetpack database layer used in this example. Add its runtime and compiler dependencies through the project’s normal dependency system. Use the stable versions recommended by Android Studio or the official Android documentation.

The “Modules, apps & files to try” section supplied with this guide contains the relevant downloads where available. Verify package names and release signatures before installing anything.

How to verify the finished app

A successful build is only the first check. Save a note, close the app and open it again. The note should remain because Room writes it to local storage.

Rotate the device and resize the emulator. Text should remain readable, and controls should not overlap. Turn on a large system font. Confirm that labels still fit or wrap.

Open the system App info screen and inspect Permissions. Permission Notes should request none. Android may still show standard system information, such as storage used by the app.

Finally, run all unit and instrumented tests. A clean result gives you a repeatable baseline for later changes.

Use a layered architecture that stays understandable

A small app does not need dozens of modules. It does need clear ownership of state and data. Start with three layers and split them only when the project grows.

• UI layer: Compose screens, navigation and ViewModels.
• Domain layer: optional use cases for important business rules.
• Data layer: repositories, Room databases and network clients.

The ViewModel exposes screen state. The screen sends user actions back to it. A repository decides whether data comes from Room, a service or both. This flow makes tests easier and limits accidental coupling.

In practice, trouble starts when a Composable writes directly to a database or starts uncontrolled network work. Recomposition can run interface code many times. Side effects must use the lifecycle-aware Compose APIs built for them.

Do not create a domain layer filled with one-line wrappers. Add it when rules are shared, sensitive or hard to test through the interface.

Design adaptive and accessible Compose screens

Android apps now run across phones, tablets, foldables, desktop windows and cars. Do not assume one portrait phone width. Use window size information to choose a layout.

A compact window may show one list or detail pane. A wider window can show both. This is more reliable than checking for a device name. Follow the official adaptive Compose layout guidance for current components and patterns.

Android adaptive layouts respond to the available window, not a fixed label such as “tablet”.

Every control needs a clear text label or accessibility description. Keep touch targets large enough. Support system font scaling, keyboard navigation and dark mode. Test colour contrast rather than judging it by eye.

Compose previews help with quick checks. They do not replace an emulator, a real device or accessibility testing.

Caption: The same Permission Notes screen adapting from a compact phone layout to a wide two-pane window.

Make privacy part of the architecture

Privacy is easiest to protect before data collection begins. Write down every data item the app handles. Record why it exists, where it goes and when it is deleted.

• Request a permission only when the related feature is used.
• Keep data on the device when cloud storage adds no user value.
• Use encrypted transport for every remote connection.
• Do not place secrets, tokens or personal data in logs.
• Give users clear export and deletion controls.
• Review third-party software development kits before adding them.

An analytics library may collect device identifiers, crash details or network metadata. Its default settings may exceed your needs. Read its data policy and inspect actual network traffic from a test build.

Android’s Keystore can protect cryptographic keys. It does not make an unsafe design private. A secret displayed by the app can still be captured on a compromised device.

For more device context, see our guide to Android app permissions.

Test behaviour, not just screenshots

A useful test plan has several levels. Local unit tests cover formatters, validation and business rules. Repository tests cover storage and error handling. Compose tests cover user actions and visible state.

Test the cases users actually meet:

• No network, slow network and a connection that stops mid-request.
• An empty database and a database created by an older app version.
• Process death, rotation and a resized multi-window session.
• Large fonts, dark mode and a screen reader.
• Denied permissions and permissions removed later in Settings.
• Low storage and a full device.

Use an emulator matrix rather than every possible model. Cover your minimum API, API 36 and API 37. Include compact and expanded windows. Add one real device because sensors, vendor power controls and performance can differ.

A passing test suite does not prove that an app is secure. Review dependencies, exported components and network rules before each release.

Understand device modification and app testing risks

You can build, sideload and debug an Android app without rooting a phone. Enable developer options and USB debugging only on a test device. Revoke computer authorisations when testing ends.

Rooted devices and custom ROMs can be useful research environments. They are not a substitute for testing on a normal locked device. Some apps change behaviour when they detect an unlocked bootloader or altered verified boot state.

Back up first if you modify your own test device. Bootloader unlocking normally wipes user data. A wrong boot, init_boot or vbmeta image can stop the device from starting. Images must match the exact device, region and installed firmware.

Modification may disrupt OTA updates, warranty support, banking apps and Play Integrity. No root module or property change can be promised to defeat a specific app’s checks. Bypassing checks can also hide faults that ordinary users will see.

If you want a privacy-led test environment, our GrapheneOS installation guide explains the separate risks and device limits.

Prepare for Google Play without confusing API levels

compileSdk controls which Android APIs the code can compile against. targetSdk tells Android which platform behaviour level the app has tested. minSdk sets the oldest Android version that can install it.

Android 17 being stable does not make API 37 the August 2026 Play minimum. The published mobile submission threshold is API 36. Targeting API 37 may still be sensible after dependency and behaviour testing.

Android 17 is stable as of 14 August 2026, while the imminent Google Play mobile submission threshold remains Android 16, API 36.

Before release, create a signed Android App Bundle. Keep the upload key outside the repository and back it up securely. Test the release build because shrinking can expose faults hidden in debug builds.

Complete Google Play’s data safety details from observed app behaviour. Check every bundled library. The official Android 17 documentation lists platform changes that may affect testing.

Caption: A release checklist separating compile SDK, target SDK, minimum SDK, signing and privacy declarations.

Common failures and what actually fixes them

The project stops after a tool update

Read the first meaningful Gradle error. Check Java, Kotlin, Compose and Android Gradle Plugin compatibility. Restore the last working version catalogue before changing several versions at once.

The app works until the screen rotates

Important state probably lives only inside a screen or activity. Put durable screen state in a ViewModel. Save process-critical values with Room or saved state support.

The release build crashes but debug works

Code shrinking may have removed classes reached through reflection. Reproduce the fault with the release configuration. Add narrow keep rules for the affected library, not a rule that disables shrinking everywhere.

The app asks for an unexpected permission

A dependency may merge its own permission into AndroidManifest.xml. Inspect the merged manifest. Remove the dependency or override the entry when the feature is not used.

Frequently asked questions

Is Kotlin still the best language for Android app development?

Yes, for most new native projects. Kotlin has strong Android tooling and works directly with Jetpack Compose. Java remains supported and is common in older codebases.

Do I need a rooted phone to develop Android apps?

No. Android Studio, an emulator and a normal device with USB debugging are enough. Root testing is optional and can produce results that do not match ordinary user devices.

Should a new app target Android 17 or API 36?

For the August 2026 Google Play mobile requirement, target at least API 36. You can target API 37 when the app and its dependencies have passed Android 17 behaviour tests.

Can I develop an Android app without publishing it?

Yes. You can run a debug build on an emulator or your own authorised device. Sideloaded builds do not have the same signing, distribution or Play Integrity context as a Play-installed release.

How long does Android app development take to learn?

A small local app can be built within days. A secure production app takes longer because testing, accessibility, data handling, updates and store compliance are part of the work.

Does Play Integrity prove that an app or device is secure?

No. It provides signals about an app and device environment. It does not replace secure design, code review or testing. Never promise that a technique will satisfy a particular bank or app.