Android SDK 36

Last reviewed Sep 6, 2026

Export as PDF

Prompt Details

Prompt Composition

2prompts
  1. Kotlin 2.4116 lines · 3.7K tokens
  2. Android SDK 3655 lines · 1.4K tokens
Total171 lines · 5K tokens

CWE Coverage

  • 20
  • 22
  • 59
  • 78
  • 79
  • 88
  • 89
  • 94
  • 117
  • 201
  • 208
  • 209
  • 212
  • 250
  • 287
  • 295
  • 297
  • 319
  • 321
  • 323
  • 327
  • 338
  • 346
  • 362
  • 367
  • 378
  • 470
  • 471
  • 476
  • 489
  • 494
  • 502
  • 532
  • 540
  • 611
  • 732
  • 770
  • 772
  • 807
  • 829
  • 862
  • 863
  • 915
  • 916
  • 918
  • 922
  • 923
  • 926
  • 927
  • 1333

Prompt Preview

Apply the Kotlin 2.4 baseline first. These rules cover Android SDK 36 components, intents, permissions, storage, cryptography, networking, WebView, authentication, logging, build configuration, and release.

Components and intents

  • Set android:exported explicitly on every component with an intent filter and export only the components that another app must invoke.
  • Protect exported components with android:permission at signature protection level or verify the component's system-provided caller identity before touching protected data.
  • Opt API 36 receiving components into android:intentMatchingFlags="enforceIntentFilter"; safer intent matching is not yet the default and none disables it per component.
  • Use explicit intents for privileged calls and validate action, categories, normalized data URI, extras, component-specific caller identity, and granted URI permissions at receipt; getCallingPackage() is nullable and identifies an activity's result recipient.
  • Create PendingIntents with FLAG_IMMUTABLE; if mutability is essential, make the base intent explicit and prevent fill-in fields from redirecting the operation.
  • Validate nested intents before forwarding them and keep Android 16's launch protection enabled; do not call removeLaunchSecurityProtection() on untrusted intents.

Permissions and identity

  • Request the minimum runtime permissions at the moment of need and handle denial without insecure fallback.
  • Do not use device identifiers, package names, referrer data, or intent extras as proof of user identity.
  • Recheck authorization for each