Module 18: Android Security (Permissions, Authentication, Encryption & Secure App Design)

Learning Objectives

By the end of this module, you’ll understand:

• Android security architecture
• Linux sandbox
• Application signing
• Permissions
• Runtime permissions
• Authentication vs Authorization
• Tokens
• JWT basics
• OAuth concepts
• Android Keystore
• Encryption fundamentals
• Symmetric vs Asymmetric encryption
• Hashing
• Digital signatures
• HTTPS & TLS internals
• Certificate pinning
• Secure storage
• Biometric authentication
• Root detection concepts
• Reverse engineering
• Obfuscation
• OWASP Mobile Top 10
• Security best practices

---

Part 1 — Security Starts With the Operating System

Android was designed with security in mind.

Every application runs inside its own isolated environment.

Conceptually:

Android Device
│
├── App A
│     └── Private Storage
│
├── App B
│     └── Private Storage
│
└── App C
      └── Private Storage

By default:

• App A cannot directly access App B’s files.
• Each app runs as its own Linux user.

This is called the Application Sandbox.

---

Why Sandbox?

Imagine there were no sandbox.

A malicious flashlight app could read:

• WhatsApp messages
• Banking data
• Photos
• Passwords

The sandbox prevents this by default.

---

Application UID

Every installed application receives its own Linux User ID.

Conceptually:

Instagram

↓

UID 10051

WhatsApp

↓

UID 10074

Bank App

↓

UID 10083

Different users.

Different permissions.

Different storage.

---

Part 2 — APK Signing

Every Android application must be digitally signed.

Signing provides:

• Developer identity
• Integrity
• Update verification

Imagine:

APK

↓

Signed

↓

Installed

When updating:

New APK

↓

Same Signature?

↓

Yes

↓

Install Update

Different signature?

Installation fails.

---

Why?

Suppose:

Someone modifies your APK.

Adds malware.

Signs it with another key.

Android refuses to install it as an update to your app because the signatures don’t match.

---

Part 3 — Permissions

Apps should not automatically access sensitive resources.

Instead:

Camera

↓

Permission

↓

Granted?

Only then:

Access allowed.

---

Permission categories include:

• Camera
• Microphone
• Contacts
• Location
• Notifications
• Calendar
• Nearby devices
• Bluetooth (modern Android)

---

Runtime Permissions

Older Android versions:

Permission granted at installation.

Modern Android:

User Clicks Feature

↓

Permission Dialog

↓

Allow?

↓

Continue

This improves transparency and user control.

---

Principle of Least Privilege

One of the most important security principles.

Request:

Only the permissions you actually need.

Bad:

Notes App

↓

Camera

↓

Location

↓

Contacts

↓

SMS

Why?

Unnecessary permissions:

• Increase attack surface
• Reduce user trust

---

Part 4 — Authentication vs Authorization

Often confused.

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Example:

Login

↓

Authentication

↓

Receive Token

↓

Authorization

↓

Access Resources

---

Example:

Alice logs in.

Authentication succeeds.

But:

Can Alice access the admin panel?

That’s authorization.

---

Part 5 — Tokens

Most modern Android apps don’t repeatedly send passwords.

Instead:

Login

↓

Server

↓

Access Token

↓

Subsequent Requests

Password used once.

Token used afterward.

---

JWT (JSON Web Token)

A JWT is a compact token format commonly used for authentication.

Conceptually:

Header

↓

Payload

↓

Signature

Important:

The payload is encoded, not encrypted.

Never store secrets inside the payload itself.

---

Access Tokens vs Refresh Tokens

Access Token

↓

Short Lifetime

Refresh Token

↓

Long Lifetime

If the access token expires:

401

↓

Refresh Token

↓

New Access Token

The refresh token typically has stricter protection because it can be exchanged for new access tokens.

---

Part 6 — Secure Storage

Where should tokens be stored?

Not:

Plain Text File

Not:

Logs

Not:

Hardcoded Constants

Instead:

Use secure platform mechanisms.

---

Android Keystore

One of Android’s most important security features.

The Keystore stores cryptographic keys, not arbitrary app data.

Conceptually:

App

↓

Android Keystore

↓

Hardware / Secure Storage

Keys can often be protected by hardware-backed security on supported devices.

The application uses the key.

It never directly reads the secret key material.

---

Encrypted Storage

For sensitive app data:

• EncryptedSharedPreferences (legacy Jetpack Security usage)
• Encrypted files
• Data encrypted with keys managed by Android Keystore

The idea:

Sensitive Data

↓

Encrypt

↓

Store

---

Part 7 — Encryption

Encryption converts:

Readable Data

↓

Ciphertext

Without the key:

Unreadable.

---

Symmetric Encryption

One key.

Encrypt

↓

Secret Key

↓

Decrypt

Fast.

Common for encrypting stored data.

Examples:

AES

---

Asymmetric Encryption

Two keys.

Public Key

↓

Encrypt

↓

Private Key

↓

Decrypt

Useful for:

• Key exchange
• Digital signatures
• Identity verification

Example:

RSA (conceptually), though modern protocols often use Elliptic Curve Cryptography.

---

Part 8 — Hashing

Hashing is not encryption.

Encryption:

Can be reversed with the proper key.

Hashing:

Cannot practically be reversed.

Example:

Password

↓

Hash

↓

Store Hash

During login:

Entered Password

↓

Hash

↓

Compare

Servers should store password hashes, not plaintext passwords.

Modern password hashing uses algorithms like Argon2, bcrypt, or scrypt rather than general-purpose hashes.

---

Part 9 — Digital Signatures

Digital signatures prove:

• Authenticity
• Integrity

Flow:

Developer

↓

Private Key

↓

Sign APK

↓

Android

↓

Verify Using Public Key

If the APK changes after signing:

Verification fails.

---

Part 10 — HTTPS & TLS

Module 13 explained HTTPS.

Now let’s look deeper.

TLS provides:

• Encryption
• Integrity
• Authentication

Conceptually:

Phone

↓

TLS Handshake

↓

Secure Session

↓

Encrypted Communication

---

During the handshake:

• Certificates are exchanged
• Identity is verified
• Session keys are negotiated

After that:

Communication is encrypted.

---

Certificates

A certificate proves:

“This server really is who it claims to be.”

Without certificates:

An attacker could pretend to be:

bank.com

and steal credentials.

---

Certificate Pinning

Normally:

Android trusts many Certificate Authorities.

Pinning says:

Only Trust

This Certificate

Benefits:

Protects against certain compromised or malicious certificate scenarios.

Trade-off:

Certificate rotation becomes more complex.

Pinning should be used carefully.

---

Part 11 — Biometrics

Instead of:

Password

Use:

• Fingerprint
• Face recognition
• Device credential (PIN/pattern/password)

Android provides the BiometricPrompt API to integrate securely with platform authentication.

Important:

Biometrics authenticate the user.

They do not replace backend authorization.

---

Part 12 — Reverse Engineering

APK files can be decompiled.

Attackers may inspect:

• Strings
• Resources
• Logic
• API endpoints

Never assume APK contents are secret.

---

Hardcoded Secrets

Bad:

const val API_KEY = "super-secret-key"

Attackers can often recover this.

Applications should avoid embedding secrets that grant privileged access.

---

Obfuscation

R8 can rename:

UserRepository

↓

a

Harder to understand.

Obfuscation slows reverse engineering but does not prevent it.

---

Root Detection (Conceptual)

Rooted devices bypass many normal security restrictions.

Some sensitive apps:

• Banking
• Corporate security
• DRM-protected apps

may detect signs of rooting and reduce functionality.

Important:

Root detection is not foolproof.

Treat it as one signal, not absolute protection.

---

Play Integrity API

Google provides the Play Integrity API to help determine whether:

• The app appears genuine.
• The install comes from Google Play (depending on integrity level).
• The device meets certain integrity checks.

Servers can use these signals when making trust decisions.

It is not a replacement for authentication or authorization.

---

Part 13 — OWASP Mobile Top 10

OWASP identifies common mobile risks.

Examples include:

• Improper credential handling
• Insecure authentication
• Insecure communication
• Insufficient cryptography
• Code tampering
• Reverse engineering
• Insecure local storage

Senior Android engineers should be familiar with these categories.

---

Part 14 — Secure Coding

Never:

Log Passwords

Log Tokens

Log OTPs

Even debug logs can leak information.

---

Validate all data.

Never trust:

• User input
• Intent extras
• Deep links
• Network responses

Always validate before using.

---

Principle of Defense in Depth

Imagine:

Password

↓

HTTPS

↓

Authentication

↓

Authorization

↓

Encryption

↓

Keystore

↓

Server Validation

Multiple layers.

If one fails:

Others still provide protection.

---

Complete Secure Login Flow

User Login
      │
      ▼
HTTPS Request
      │
      ▼
Authentication
      │
      ▼
Access Token
      │
      ▼
Store Securely
      │
      ▼
Authenticated API Calls
      │
      ▼
401?
      │
      ▼
Refresh Token
      │
      ▼
New Access Token

Notice that:

• Password is not repeatedly transmitted.
• Tokens are managed securely.
• Transport is encrypted.

---

Common Mistakes

❌ Hardcoding API keys or secrets

Assume anything in the APK can eventually be extracted.

---

❌ Storing authentication tokens in plaintext

Protect sensitive data using appropriate encryption and secure key management.

---

❌ Logging sensitive information

Logs may be accessible during debugging or on compromised devices.

---

❌ Requesting unnecessary permissions

Follow the principle of least privilege.

---

❌ Trusting all SSL certificates

Never disable certificate validation in production.

---

❌ Confusing authentication with authorization

Knowing who a user is does not determine what they are allowed to access.

---

❌ Relying only on client-side checks

All critical authorization decisions must be enforced on the server.

---

Mental Model

Imagine entering a high-security office.

Front Door
      │
      ▼
Security Guard
      │
      ▼
Employee Badge
      │
      ▼
Biometric Scanner
      │
      ▼
Restricted Floor Access

Each layer provides additional protection.

If someone bypasses one layer, others still defend the system.

This is defense in depth, and it is the foundation of secure software design.

---

Best Practices

• Request only the permissions your app truly needs.
• Always use HTTPS.
• Store cryptographic keys in the Android Keystore.
• Encrypt sensitive local data.
• Never hardcode secrets into the APK.
• Avoid logging credentials or tokens.
• Validate all external input.
• Design assuming the APK can be inspected.
• Enforce authorization on the server.
• Follow the OWASP Mobile Top 10 as part of your secure development process.

---

Interview Questions

1. What is the Android application sandbox?
2. Why must APKs be digitally signed?
3. Explain the difference between authentication and authorization.
4. What is the Android Keystore, and what is it used for?
5. Compare symmetric encryption, asymmetric encryption, and hashing.
6. What is certificate pinning, and what are its trade-offs?
7. Why shouldn’t API secrets be hardcoded into an APK?
8. What is the purpose of the Play Integrity API?
9. Why is HTTPS alone not sufficient for complete application security?
10. Explain the principle of defense in depth.

---

Module 18 Summary

You now understand the foundations of Android application security:

• Android isolates apps using a Linux-based sandbox.
• APK signing ensures authenticity and trusted updates.
• Permissions protect access to sensitive device capabilities.
• Authentication identifies users, while authorization controls access.
• Access tokens and refresh tokens support secure session management.
• Android Keystore protects cryptographic keys.
• Encryption, hashing, and digital signatures each solve different security problems.
• TLS secures communication in transit.
• Certificate pinning can strengthen trust in specific scenarios.
• Defense in depth is achieved by layering security controls rather than relying on a single mechanism.

Most importantly, you’ve learned that security is not a single feature you add at the end of development. It is an architectural concern that influences storage, networking, authentication, permissions, and backend interactions from the very beginning.

---

Your Progress So Far

You’ve now completed the core Android engineering curriculum:

1. Android Fundamentals
2. Activity & Fragment Lifecycle
3. UI with Views & Jetpack Compose
4. Navigation & Intents
5. State & Lifecycle Management
6. Architecture Components
7. Lists & Lazy Layouts
8. Data Handling Fundamentals
9. Advanced UI & Material Design
10. MVVM & Clean Architecture
11. Coroutines & Flow
12. Dependency Injection (Hilt)
13. Networking (Retrofit & OkHttp)
14. Room & Offline-First Architecture
15. Background Work & WorkManager
16. Testing
17. Performance & Optimization
18. Security

At this point, you’ve covered nearly every foundational subsystem used in modern Android applications.

---

Next Module: Build System, Gradle & Android Project Internals

Module 19 answers another question that every experienced Android developer eventually asks:

What actually happens when I press the “Run” button in Android Studio?

We’ll dive deep into:

• Gradle architecture
• The Android build pipeline
• Gradle lifecycle (Initialization, Configuration, Execution)
• AGP (Android Gradle Plugin)
• Build variants and product flavors
• Manifest merging
• Resource merging
• Annotation processing (KAPT & KSP)
• Code generation (Hilt, Room, Compose)
• APK vs AAB
• DEX, ART, and Multidex
• Build caching
• Dependency resolution
• CI/CD build pipelines
• Build optimization

This is one of the most technically rich modules in the entire roadmap because it explains how Android projects are actually built, not just how they’re written.