In No-Code AI App Builder, native features are capabilities: each one bundles a permission, the code that implements it and a bridge the screens call. You add one by asking for it in a prompt; the builder adds it to the app, requests the permission at the right moment, and the APK and AAB carry only the capabilities the app uses. This guide goes through each capability so you know what to ask for and what it means for your Play listing.
The capability model, briefly
A traditional app template ships every SDK it might ever need, and the manifest asks for everything. That produces scary permission lists and long data-safety forms. A capability-driven builder inverts it: the app lists what it needs, and permissions and native code are derived from that list. Ask for nothing native and the built app asks for nothing native.
Camera and photos
Does: take a photo or pick from the gallery, return it to the screen (for a receipt, a profile picture, an enquiry). Permission: camera; gallery picking needs none on modern Android. Ask when: the user taps the photo button, not at launch. Prompt: "add a photo to each entry from the camera or gallery".
Location
Does: current position for "near me", distance, sunrise times, check-in; optional tracking for run/walk apps. Permission: fine or coarse location; background location is a separate, heavily reviewed permission — avoid it unless the app is genuinely about tracking. Ask when: the user opens the map or taps "use my location". Prompt: "show distance to each store using my location".
Local notifications
Does: reminders and alerts scheduled on the phone — no server. Habit reminders, booking reminders, "order ready" timers, event session alerts. Permission: notifications (Android 13+ asks the user). Ask when: the user sets their first reminder. Prompt: "remind me 1 hour before each booking". Notifications in generated apps are heads-up (they appear on screen) with one channel the user can mute.
Push notifications
Does: messages sent from you to every phone, instantly, even when the app is closed. Needs: a push provider — Firebase or OneSignal — set up in the builder's Push panel; the builder wires the receiving side into the app. Use when: a local "check for new posts" is not fast enough. Most community and event apps do fine with local notifications triggered by new rows in a sheet.
Biometric lock
Does: fingerprint or face to open the app or a screen (owner view, journal, expenses). Falls back to the device PIN. Permission: biometric. Prompt: "lock the Owner tab behind fingerprint".
Barcode and QR scanning
Does: reads barcodes and QR codes with the camera — stock counts, ticket check-in, product lookup, contact exchange. Permission: camera. Prompt: "scan a barcode to find the product". Uses the on-device scanner, no network.
Vibration and haptics
Does: a buzz on completion, on right/wrong answers, at timer transitions. Permission: vibrate (not shown to users). Prompt: "vibrate briefly when a habit is marked done".
Background audio
Does: keeps audio playing when the screen is off — talks, podcasts, guided workouts. Prompt: "play recordings in the background with controls in the notification".
Sharing, calendar, dialer, WhatsApp
These need no permission: the app hands off to the system. "Share results", "add event to calendar", "call the shop", "send the order by WhatsApp" all work out of the box and are the cheapest way to make an app feel connected without a backend.
What the Play listing sees
Only the permissions your capabilities require. The data-safety form then has short, honest answers: a habit tracker with reminders collects nothing and shares nothing; a store app that sends orders by WhatsApp sends order details to you. Install the APK and walk through every feature before you fill in the form.