CEH · M17

Mobile permissions: purpose, timing and behavior after denial

Permissions connect an application to restricted data or actions. Start with the user’s current task, identify the minimum access and check graceful behavior after denial.

After this lesson, you can
  • Distinguish declaring a permission from obtaining runtime permission.
  • Use a feature matrix to assess excessive requests and behavior after revocation.

Prerequisites: Identity and privilege: what can you do after login?

Make the permission-dependent feature explicit

Android uses install-time, runtime and special-permission mechanisms. Declaring a permission does not mean the user granted it. Check before access and follow the platform request flow. Android and target SDK versions can affect behavior.

First ask whether the feature can work with less data. Selecting one photo may have a narrower system-picker route than reading an entire media library. Tie a request to the current feature so the user can understand its purpose.

Further reading: Android Developers: Permissions overview

Denial and revocation are normal states

Users can deny, revoke or grant access only in certain circumstances. An app should recheck state and provide understandable alternatives, such as typed input when recording is denied. It should not repeatedly pressure users for unrelated access.

A permission list shows potential capabilities, not proof that data was transmitted. Establishing actual data flow requires authorized evidence about operations, storage and transmission.

Example: a text note requests microphone access

A fictional note app requests microphone access at launch while the user only wants to type and has not selected recording.

The timing does not match the current feature. A reasonable flow explains and requests access when recording is selected and preserves typing after denial. The inappropriate request alone does not prove audio transmission.

Conclusion: Identify the least-privilege and context problem while keeping data transmission unknown.

Tabletop exercise: map features to permissions

Analyze a fictional app without changing phone settings or installing software.

  1. List typed notes, audio notes and choosing one photo.
  2. Write the required capability and request timing for each.
  3. Add a usable path after denial or revocation.

Expected result

Typing does not depend on microphone access; recording needs the corresponding capability; photo selection should first consider the narrowest system mechanism.

Check your work

What evidence separates declaring microphone permission from recording and transmitting audio?

Finish and clean up

Save the matrix; no device settings require restoration.

Q&A · Check your reasoning

Choose an answer and confidence, then read every explanation. Answers stay in this browser.

ceh-m17-permission-q1 · Original practice

Does declaring a runtime permission mean the user granted it?

Does declaring a runtime permission mean the user granted it?
ceh-m17-permission-q2 · Original practice

If microphone access is denied, what should happen to typed notes?

If microphone access is denied, what should happen to typed notes?

Connect the next idea

Terms: Mobile permission·Least privilege

Sources & scope

These sources support the technical principles. Examples, questions and exercises are original to this series.