Android Permissions and Security Essentials Quiz Quiz

Enhance your understanding of Android permissions and security essentials with this easy quiz, designed to cover key concepts such as runtime permissions, permission protection levels, and best practices for handling sensitive data in Android apps. Explore crucial topics to help safeguard user privacy and develop secure mobile applications.

  1. Identifying the Need for Permissions

    Which permission would an Android app require to access the user's current geographic location for displaying nearby weather?

    1. INTERNETT_ACCESS
    2. READ_PHONE_STATE
    3. ACCESS_MEDIA_LOCATION
    4. ACCESS_FINE_LOCATION

    Explanation: ACCESS_FINE_LOCATION allows apps to request precise location updates from the device. READ_PHONE_STATE is used for reading phone status and identity and does not provide location data. INTERNETT_ACCESS is a misspelling; the correct permission to access the internet is INTERNET. ACCESS_MEDIA_LOCATION gives access to location information embedded in media files, not the device’s real-time location.

  2. Understanding Permission Protection Levels

    What is the protection level of a permission that allows access to highly sensitive user data, such as contacts or camera?

    1. Normal_Dangerous
    2. Dangerous
    3. SignatureOnly
    4. Normal

    Explanation: Dangerous permissions affect user privacy and require explicit user approval at runtime. Normal permissions pose minimal risk and are automatically granted. Normal_Dangerous is not a valid protection level. SignatureOnly is a mistaken form; the actual level is Signature, which is for permissions granted only to apps with the same certificate.

  3. Requesting Permissions at Runtime

    When targeting Android 6.0 (API level 23) or higher, what must an app do before accessing the device microphone for audio recording?

    1. Enable microphone in device settings
    2. Request the RECORD_AUDIO permission at runtime
    3. Add the permission to resources.xml
    4. Declare the permission in the manifest only

    Explanation: On Android 6.0 and above, dangerous permissions like RECORD_AUDIO require both declaration in the manifest and explicit user approval at runtime. Declaring only in the manifest is insufficient. Enabling the microphone in settings is a user, not app action. Adding permissions to resources.xml is not valid for Android permissions.

  4. Best Practice with Sensitive Data

    Which is the recommended practice when handling sensitive user data such as addresses or passwords in your Android app?

    1. Log sensitive data for debugging
    2. Encrypt data before storing or transmitting
    3. Store data in external storage
    4. Send data over unencrypted HTTP

    Explanation: Encryption protects sensitive information even if a device is lost or data is intercepted in transit. Storing on external storage is insecure since other apps may access it. Sending data over unencrypted HTTP exposes it to interception. Logging sensitive data can lead to unintentional data leaks.

  5. Describing a Permission in the Manifest

    What manifest tag is used to request access to device features such as the camera or contacts?

    1. u003Cuser-permissionu003E
    2. u003CusesSecurityu003E
    3. u003Cuses-featureu003E
    4. u003Cuses-permissionu003E

    Explanation: u003Cuses-permissionu003E requests permission to access protected features from the user. u003Cuses-featureu003E declares hardware or software features used, but not permissions. u003Cuser-permissionu003E is a typo and not recognized. u003CusesSecurityu003E is not a valid tag in permission declarations.

  6. Default Granting of Permissions

    Which type of Android permission is granted automatically by the system without user approval?

    1. Dangerous
    2. Normal
    3. Internal
    4. Custom

    Explanation: Normal permissions are considered safe and are granted automatically upon installation. Dangerous permissions require explicit user consent. Custom is a category set by app developers but does not determine grant behavior. Internal is not an official permission level.

  7. Handling Permission Denial

    If a user denies a permission request for accessing their contacts, what is the expected behavior from the app?

    1. Proceed to access contacts anyway
    2. Automatically close the app
    3. Disable all app features
    4. Show a rational explanation and ask again if needed

    Explanation: Apps should respect the user’s decision and can provide a rationale explaining why the permission is needed before re-requesting. Ignoring denial and accessing anyway violates system security. Closing the app or disabling all features is unnecessarily drastic when a single feature is affected.

  8. Granting Permissions to Broadcast Receivers

    How can a specific permission be enforced when sending a broadcast that only receivers with that permission can receive?

    1. Add a permission argument to sendBroadcast()
    2. Request via user prompt
    3. Declare in Android manifest only
    4. Place permission in build.gradle

    Explanation: By using the permission parameter with sendBroadcast(), only receivers with the specified permission can receive the broadcast. Manifest declaration alone does not restrict broadcast receipt. Permissions in build.gradle do not affect runtime behavior. Prompting users is not relevant to controlling broadcast receivers.

  9. Identifying a Security Threat

    Which scenario best describes a threat known as 'phishing' in the context of Android security?

    1. App uses strong encryption for data storage
    2. App requests excessive permissions for no clear reason
    3. User receives a fake login screen to steal credentials
    4. App prompts for updates through official store only

    Explanation: Phishing tricks users into giving away sensitive information via deceptive interfaces like fake login screens. Requesting unnecessary permissions reflects poor app design or privacy concerns but is not phishing. Using strong encryption is a security best practice. Official update prompts are legitimate.

  10. Managing Permission Groups

    If an app has already been granted the READ_CONTACTS permission, what will happen if it later requests the WRITE_CONTACTS permission from the same group?

    1. System auto-grants WRITE_CONTACTS without prompt
    2. Both permissions are revoked
    3. App crashes immediately
    4. User must grant WRITE_CONTACTS separately

    Explanation: Even though READ_CONTACTS and WRITE_CONTACTS are from the same group, each dangerous permission must be granted individually by the user. Permissions are not auto-granted just because a user previously accepted another from the same group. Revocation or app crashes do not occur in this scenario.