Permissions, Publishing & the Play Store

What you'll learn

You can build a complete, tested app — the final step is getting it into people's hands. This module covers the last professional essentials: asking for runtime permissionsrespectfully, preparing a signed release build, and publishing through the Google Play Console.

By the end you'll be able to:

• Request runtime permissions in Compose
• Understand app signing and build types
• Prepare a shrunk, signed release bundle
• Navigate the Play Console and ship a quality listing

Runtime permissions

Sensitive capabilities — camera, location, contacts — require the user's explicit consent at runtime, not just a manifest entry. You declare the permission in the manifest, then ask for it when the feature is used:

<!-- AndroidManifest.xml — declare what the app needs -->
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.INTERNET" />

In Compose, request it with rememberLauncherForActivityResult and the RequestPermission contract, which shows the system dialog and gives you the result:

@Composable
fun CameraButton(onGranted: () -> Unit) {
    val launcher = rememberLauncherForActivityResult(
        ActivityResultContracts.RequestPermission(),
    ) { granted ->
        if (granted) onGranted()
        // else: keep the screen usable and offer a non-camera fallback.
    }

    Button(onClick = { launcher.launch(Manifest.permission.CAMERA) }) {
        Text("Take photo")
    }
}

App signing & build types

Every Android app is digitally signed — the signature proves updates come from the same developer. Projects have two build types: debug (auto-signed, used while developing) and release (the optimized build you ship). For publishing, Google recommends Play App Signing: you upload with your own key, and Google manages the final signing key securely.

Preparing a release

Configure the release build to enable R8, which shrinks and obfuscates your code, with resource shrinking to remove unused resources — a smaller, faster, harder-to-reverse-engineer app. Then you build an Android App Bundle (.aab), the format Play requires (Google generates optimized APKs per device from it):

// build.gradle (app) — the release build type
android {
    buildTypes {
        release {
            isMinifyEnabled = true            // shrink & obfuscate with R8
            isShrinkResources = true          // drop unused resources
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro",
            )
        }
    }
}
// Build the upload artifact:  ./gradlew bundleRelease  →  app-release.aab

The Play Console

The Google Play Console is where you manage your app. A one-time developer account registration is required. The path to live:

1. Create the app and complete the content questionnaires (privacy policy, data safety, content rating, target audience).
2. Upload your .aab to a testing track first — internal, then closed/open testing — to catch issues with real users.
3. Fill in the store listing (below).
4. Roll out to production — optionally a staged rollout to a percentage of users first.

Quality & store listing

Your store listing is your storefront: a clear title and description, a compelling icon, screenshots (and ideally a short video), and a feature graphic. First impressions decide installs. Beyond the listing, aim for genuine quality — follow Material guidelines, support dark mode and different screen sizes, handle errors and offline states, respect the user's data, and keep the app fast. That's everything this course has been building toward.

Practice: one small working feature

Prepare a release checklist covering permissions, signing, versioning, and a smoke test.

Check your result

The app handles a denied permission, builds a signed release artifact, and installs as an update during your own checks.

Recap & quick check

Review Android Security & Privacy, then prepare the Phase 6 tested score calculator capstone. Demonstrate its numerical unit tests and Compose user-flow test before building the final Study Tasks app. Signing a release can be a separate follow-up exercise.