My progress
Menu

Mobile App Developer · Focus area 2: Mobile architecture

MA8: Device features, permissions, background work and privacy

Goal: use the phone's features through tested modules, ask for permissions only when needed and handle "no" gracefully, work within the limits Android and iOS set on background work, send notifications people want, and protect the data an app keeps.

You'll need: MA3, MA4, MA5, Module 77 (Encryption and Secrets), Module 79 (Privacy and Data Protection), and the KhetNote practice kit (app.json, store/, tests/release.test.js).

Where this is used: cameras for scanning, location for deliveries, notifications for messages, background sync for mail. Each comes with rules from the platform, the store and privacy law, and with users who can say no.

How it differs: a website asks the browser for a few features. A mobile app can reach much more of the phone, so the platforms and stores watch closely what it asks for, when and why.

Time: reading about 2½ hours · practice (the Try it tasks) about 2½ hours · assignment about 3 hours.

Lessons

  1. 1Using the phone's featuresReading 15–25 minutes, plus practice✓
  2. 2Permissions done rightReading 15–25 minutes, plus practice✓
  3. 3Background work within the rulesReading 15–25 minutes, plus practice✓
  4. 4Notifications people wantReading 15–25 minutes, plus practice✓
  5. 5Privacy and security on the phoneReading 15–25 minutes, plus practice✓

🛠️Assignment: KhetNote's permissions and privacy

  1. Plan one device feature with its availability check and fallback.
  2. Remove the starter's unused permissions, block the risky ones, and remove vague iOS usage texts.
  3. Write KhetNote's sync approach for the background, honestly marking what's not verified.
  4. Plan one notification with its text, channel and when you'd ask for permission.
  5. Write store/listing.md's data safety and privacy policy sections from the code and config.
  6. Run npm run test:release and note which tests pass (2 and 8 at least).

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How should an app use the phone's features while respecting its users?

Show a good answer

A good answer mentions: tested modules for features, availability checks and fallbacks; permissions asked in context with clear reasons, refusals handled, the least access requested and unused permissions removed or blocked; background work within the platforms' limits, with foreground sync first; useful, rare notifications in channels, with permission asked when the value is clear and no sensitive text on the lock screen; and collecting less, protecting tokens, no secrets in code, and privacy answers that match what the app and its SDKs do.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A sign-in feature needs a fingerprint sensor. Some staff phones don't have one. What should the app do?

Why each option is right or wrong

  • “Refuse to open on phones without a sensor” (Incorrect): Staff are locked out.
  • “Ask every staff member to buy a newer phone that has a fingerprint sensor” (Incorrect): Users shouldn't pay for the app's design.
  • “Skip sign-in entirely on those phones” (Incorrect): That removes the protection.
  • “Check for a sensor, and offer a PIN when there isn't one” is correct.

    A fallback keeps everyone able to sign in.

    • Test: on a phone without the sensor.

📖 Revise: Lesson 1: Using the phone's features

Question ID sp-mobile-08-q1 · Report a mistake in this question
2. An adviser refused camera access last week. Today they tap "Add photo" again. What should the app do?

Why each option is right or wrong

  • “Show the system's camera prompt again and again until the adviser agrees to it” (Incorrect): Repeated prompts annoy people, and the system may not show it at all.
  • “Hide the "Add photo" button for good, since the adviser said no once” (Incorrect): People change their minds when they understand the reason.
  • “Stop the visit from saving until a photo is added, so the record is complete” (Incorrect): That blocks the adviser's work over an optional feature.
  • “Explain why the camera helps, and offer a button that opens the app's settings” is correct.

    Once refused, the system may not show its prompt again, so settings is the way back.

    • Also: let the visit save without a photo.

📖 Revise: Lesson 2: Permissions done right

Question ID sp-mobile-08-q2 · Report a mistake in this question
3. A library adds a microphone permission the app doesn't use. How can an Expo app stop it?

Why each option is right or wrong

  • “Open the built app file after each build and delete the permission line from it by hand” (Incorrect): Manual steps get forgotten.
  • “Ask users to refuse it when the prompt appears” (Incorrect): It still shows in the store listing.
  • “Rename the app so the store doesn't notice” (Incorrect): Store review checks the manifest, not the name.
  • “List it in android.blockedPermissions in app.json” is correct.

    Blocked permissions aren't added to the app.

    • Check: the built manifest.

📖 Revise: Lesson 2: Permissions done right

Question ID sp-mobile-08-q3 · Report a mistake in this question
4. A plan says "sync every 15 minutes in the background, so the office sees visits on time". What's the main problem?

Why each option is right or wrong

  • “Fifteen minutes is too often for any sync” (Incorrect): The issue is who controls the timing.
  • “Background sync isn't allowed on Android phones, so the task is being silently dropped each time” (Incorrect): It is allowed, within limits.
  • “The office should sync with the phones instead” (Incorrect): Phones start the sync.
  • “The system decides when background tasks run, so timing isn't up to the app” is correct.

    Background work is limited to save battery.

    • Better: sync on saves and reconnects, background as a bonus.

📖 Revise: Lesson 3: Background work within the rules

Question ID sp-mobile-08-q4 · Report a mistake in this question
5. Where should an offline field app do most of its syncing?

Why each option is right or wrong

  • “Only in the background, at night, while the phone charges” (Incorrect): The office would wait until the next day.
  • “Only when the user presses a "Sync now" button” (Incorrect): People forget, and changes wait.
  • “Every second, as long as the app is installed” (Incorrect): That drains the battery and isn't allowed.
  • “In the foreground: on open, after saves and on reconnect” is correct.

    The app controls these moments.

    • Plus: background tasks when the system allows.

📖 Revise: Lesson 3: Background work within the rules

Question ID sp-mobile-08-q5 · Report a mistake in this question
6. When is the best moment for KhetNote to ask for notification permission?

Why each option is right or wrong

  • “The first time the app opens, before the adviser has seen any screen or feature” (Incorrect): People don't yet know why they'd want them.
  • “After the adviser has used the app for a full year” (Incorrect): They'd miss reminders all year.
  • “Not at all, because a farm app has no real reason to send a notification” (Incorrect): Follow-up reminders are useful, and Android allows them with permission.
  • “When the adviser first sets a follow-up date for a visit” is correct.

    The value is clear at that moment.

    • Then: a local reminder on that date.

📖 Revise: Lesson 4: Notifications people want

Question ID sp-mobile-08-q6 · Report a mistake in this question
7. A clinic's reminder shows the patient's condition on the lock screen. What should change?

Why each option is right or wrong

  • “Send the full reminder, with the farmer's name and phone number, by email instead” (Incorrect): That spreads the personal details further, not less.
  • “Remove reminders completely” (Incorrect): Patients lose a useful service.
  • “Make the notification text smaller” (Incorrect): It's still readable.
  • “Keep details inside the app and show only the time on the lock screen” is correct.

    Lock screens can be seen by others.

    • Example: "You have an appointment tomorrow at 10:00".

📖 Revise: Lesson 4: Notifications people want

Question ID sp-mobile-08-q7 · Report a mistake in this question
8. An app declares it collects no location, but an analytics SDK it includes sends location. What's the right response?

Why each option is right or wrong

  • “Keep the old answers, since the team's own code doesn't collect it and only the SDK does” (Incorrect): SDKs are part of the app.
  • “Remove the data safety section from the listing” (Incorrect): It's required.
  • “Hide the SDK's code so reviewers can't find it” (Incorrect): That's deceptive and against store rules.
  • “Check every SDK's data use, and update the answers or the SDK settings” is correct.

    Answers must match what the app and its SDKs do.

    • Then: an update before the store acts.

📖 Revise: Lesson 5: Privacy and security on the phone

Question ID sp-mobile-08-q8 · Report a mistake in this question
9. Why shouldn't an app include a secret API key in its code?

Why each option is right or wrong

  • “Keys make the code bundle much larger” (Incorrect): They're tiny.
  • “Phones can't send keys over the network” (Incorrect): They can; that's not the issue.
  • “Stores charge extra for apps with keys” (Incorrect): There's no such charge.
  • “The app can be unpacked and the key read and misused” is correct.

    Keys stay on servers; apps get short-lived tokens.

    • Kit: the sync address comes from EXPO_PUBLIC_SYNC_URL, which isn't secret.

📖 Revise: Lesson 5: Privacy and security on the phone

Question ID sp-mobile-08-q9 · Report a mistake in this question
10. How should KhetNote's data safety answers be written?

Why each option is right or wrong

  • “From memory, by the person who knows the app best” (Incorrect): Memory misses things.
  • “Copied from a similar, popular app's listing so the wording matches what reviewers expect” (Incorrect): Another app collects different data.
  • “As short as possible, saying "no data collected"” (Incorrect): It's untrue: visit records are collected.
  • “From the code, app.json and every SDK, then checked against them” is correct.

    Answers must match the app's real behaviour.

    • Kit: test 8 checks the permissions are listed.

📖 Revise: Lesson 5: Privacy and security on the phone

Question ID sp-mobile-08-q10 · Report a mistake in this question

ProLearners Assist