If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/yanzhenjie/AndPermission shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 6 active contributors
• Apache-2.0 licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Single-maintainer risk — top contributor 82% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live yanzhenjie/AndPermission repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/yanzhenjie/AndPermission.

What it runs against: a local clone of yanzhenjie/AndPermission — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in yanzhenjie/AndPermission | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 885 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of yanzhenjie/AndPermission. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/yanzhenjie/AndPermission.git
#   cd AndPermission
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of yanzhenjie/AndPermission and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "yanzhenjie/AndPermission(\\.git)?\\b" \\
  && ok "origin remote is yanzhenjie/AndPermission" \\
  || miss "origin remote is not yanzhenjie/AndPermission (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "permission/src/main/java/com/yanzhenjie/permission/AndPermission.java" \\
  && ok "permission/src/main/java/com/yanzhenjie/permission/AndPermission.java" \\
  || miss "missing critical file: permission/src/main/java/com/yanzhenjie/permission/AndPermission.java"
test -f "permission/src/main/java/com/yanzhenjie/permission/runtime/PermissionRequest.java" \\
  && ok "permission/src/main/java/com/yanzhenjie/permission/runtime/PermissionRequest.java" \\
  || miss "missing critical file: permission/src/main/java/com/yanzhenjie/permission/runtime/PermissionRequest.java"
test -f "permission/src/main/java/com/yanzhenjie/permission/bridge/BridgeActivity.java" \\
  && ok "permission/src/main/java/com/yanzhenjie/permission/bridge/BridgeActivity.java" \\
  || miss "missing critical file: permission/src/main/java/com/yanzhenjie/permission/bridge/BridgeActivity.java"
test -f "permission/src/main/java/com/yanzhenjie/permission/checker/PermissionChecker.java" \\
  && ok "permission/src/main/java/com/yanzhenjie/permission/checker/PermissionChecker.java" \\
  || miss "missing critical file: permission/src/main/java/com/yanzhenjie/permission/checker/PermissionChecker.java"
test -f "permission/src/main/java/com/yanzhenjie/permission/runtime/Permission.java" \\
  && ok "permission/src/main/java/com/yanzhenjie/permission/runtime/Permission.java" \\
  || miss "missing critical file: permission/src/main/java/com/yanzhenjie/permission/runtime/Permission.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 885 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~855d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/yanzhenjie/AndPermission"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

AndPermission is an Android runtime permissions manager (API 14+) that wraps Android's permission request flow with a fluent API, supporting both standard runtime permissions (storage, camera, location) and special permissions (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES). It provides callbacks for granted/denied states and handles permission rationale dialogs transparently through a bridge activity/service pattern. Single-module monorepo: permission/src/main/java contains the core (AndPermission.java entry point, Boot.java initialization, RequestExecutor.java request handler). The bridge/ package wraps requests via BridgeActivity and BridgeService for API <23 compatibility, while checker/ package contains 15+ PermissionTest implementations for actual permission verification. AIDL interface IBridge.aidl enables inter-process communication.

Android app developers targeting androidx who need to request runtime permissions (Android 6.0+) and special system permissions without boilerplate, and who want a chainable, callback-based API instead of managing onRequestPermissionsResult() themselves.

Active but stable: version 2.0.3 published, using modern gradle tooling (3.5.1), androidx requirement shows recent maintenance. No visible test suite in the file list, which is a gap. Last update timing is unclear from repo data, but the codebase is well-organized and production-ready for its scope.

Single-maintainer library (yanzhenjie) with no visible CI/CD in the file list and no automated test suite shown, raising sustainability risk. The bridge pattern via AIDL (IBridge.aidl) adds complexity; any Android OS changes affecting permission flows could break it. Dependency on custom PermissionChecker classes means behavior correctness depends entirely on these checker implementations being correct.

No active development signals visible from the provided file list. Version 2.0.3 is published; the codebase appears stable/maintenance mode. Specific PRs or recent commits are not shown in the available data.

git clone https://github.com/yanzhenjie/AndPermission.git
cd AndPermission
./gradlew build

Daily commands: This is a library (not an app). To test: ./gradlew permission:build builds the AAR. To integrate: add implementation 'com.yanzhenjie:permission:2.0.3' to your app's build.gradle, then call AndPermission.with(activity).runtime().permission(...).onGranted(...).start() in your Activity.

• permission/src/main/java/com/yanzhenjie/permission/AndPermission.java — Primary public API entry point—all permission requests flow through this class; understanding its request building chain is fundamental
• permission/src/main/java/com/yanzhenjie/permission/runtime/PermissionRequest.java — Core runtime permission request abstraction; defines the callback interface (onGranted/onDenied) used across all permission types
• permission/src/main/java/com/yanzhenjie/permission/bridge/BridgeActivity.java — Transparent bridge activity that actually triggers Android's requestPermissions() dialog; critical for understanding permission grant flow
• permission/src/main/java/com/yanzhenjie/permission/checker/PermissionChecker.java — Abstract permission checker that validates whether a permission is granted; every permission type delegates through this
• permission/src/main/java/com/yanzhenjie/permission/runtime/Permission.java — Defines all permission groups (STORAGE, CAMERA, LOCATION, etc.); essential reference for understanding available permission types
• permission/src/main/java/com/yanzhenjie/permission/Boot.java — Initialization logic that sets up version-specific request factories; required to understand how the library adapts to Android API levels
• permission/src/main/aidl/com/yanzhenjie/permission/bridge/IBridge.aidl — IPC interface for cross-process permission requests; explains why a BridgeService exists and how remote permission requests are handled

Add a new runtime permission group

1. Define the permission constant in Permission.java (e.g., public static final String BLUETOOTH = "android.permission.BLUETOOTH";) (permission/src/main/java/com/yanzhenjie/permission/runtime/Permission.java)
2. Create a PermissionTest implementation for functional validation (e.g., BluetoothTest extends PermissionTest) (permission/src/main/java/com/yanzhenjie/permission/checker/BluetoothTest.java)
3. Register the test in DoubleChecker.getTest(String permission) method (permission/src/main/java/com/yanzhenjie/permission/checker/DoubleChecker.java)
4. Add test to AndroidManifest.xml if it requires specific intents or features to be tested (permission/src/main/AndroidManifest.xml)

Add a new special permission type (e.g., a new dangerous permission like NEARBY_WIFI_DEVICES)

1. Create a new request class extending BaseRequest in a new package (e.g., permission/src/main/java/com/yanzhenjie/permission/nearby/) (permission/src/main/java/com/yanzhenjie/permission/overlay/BaseRequest.java)
2. Create version-specific implementations (NRequest for Android N+, ORequest for Android O+) with isGranted() logic (permission/src/main/java/com/yanzhenjie/permission/notify/NRequest.java)
3. Create corresponding request factories (NRequestFactory, ORequestFactory) that Boot.java will wire up (permission/src/main/java/com/yanzhenjie/permission/notify/NRequestFactory.java)
4. Add a public method to AndPermission.java (e.g., .nearby()) and wire the factory in Boot.java (permission/src/main/java/com/yanzhenjie/permission/AndPermission.java)

Implement a rationale callback (show explanation before requesting permission)

1. Implement Rationale interface in a callback class (permission/src/main/java/com/yanzhenjie/permission/Rationale.java)
2. Chain .rationale(rationale) onto your runtime permission request before .start() (permission/src/main/java/com/yanzhenjie/permission/runtime/PermissionRequest.java)
3. The Rationale.showRationale() is called before requestPermissions() to explain why permission is needed (permission/src/main/java/com/yanzhenjie/permission/runtime/MRequest.java)

Add support for a new Android API level (e.g., Android 15+)

1. Create PRequest class extending BaseRequest for the new API level, implementing version-specific behavior (permission/src/main/java/com/yanzhenjie/permission/runtime/MRequest.java)
2. Create PRequestFactory implementing RequestExecutor to instantiate PRequest (permission/src/main/java/com/yanzhenjie/permission/runtime/MRequestFactory.java)
3. Register the factory in Boot.java with condition Build.VERSION.SDK_INT >= Build.VERSION_CODES.P (or higher level) (permission/src/main/java/com/yanzhenjie/permission/Boot.java)

BridgeActivity must be in AndroidManifest.xml: forgetting to merge manifests from the AAR will cause permission requests to crash silently. PermissionTest checkers are permission-specific: e.g., LocationFineTest actually tries to query LocationManager; if a permission isn't properly implemented in checker/, isGranted() will return false even if the manifest declares it. AIDL serialization overhead: using BridgeService incurs inter-process overhead; rapid permission requests may queue. FileProvider initialization: the custom FileProvider.java suggests file-sharing features; misconfiguring paths in FileProvider meta-data will break file sharing on certain APIs.

• Android Runtime Permissions (Dangerous Permissions) — AndPermission's entire purpose is wrapping the Android 6.0+ runtime permission model; understanding which permissions are 'dangerous' (require user approval at runtime) vs. 'normal' (auto-granted) is foundational
• AIDL (Android Interface Definition Language) — The library uses AIDL (IBridge.aidl) to enable inter-process communication between the app and the BridgeService, allowing permission requests from background threads or services
• Activity Result Contracts (onRequestPermissionsResult callback) — BridgeActivity hooks into Android's onRequestPermissionsResult() to intercept system permission dialogs and funnel results back to the caller via callbacks
• Strategy Pattern (PermissionTest implementations) — The checker/ package uses Strategy pattern: DoubleChecker selects the correct PermissionTest subclass (CameraTest, LocationFineTest, etc.) to verify if a permission is actually granted at runtime
• Manifest Merging — AndPermission's BridgeActivity and BridgeService must be merged into the host app's AndroidManifest.xml from the AAR; misunderstanding gradle manifest merging causes the library to fail silently
• Permission Groups (Permission.Group) — The fluent API (permission(Permission.Group.STORAGE)) groups related permissions; understanding Android's grouping (e.g., STORAGE = READ_EXTERNAL_STORAGE + WRITE_EXTERNAL_STORAGE) is needed to request correctly
• Rationale Dialogs (User Education) — The Rationale.java interface allows apps to show custom dialogs explaining why a permission is needed before the system permission dialog appears, improving UX and approval rates

• permissions-dispatcher/PermissionsDispatcher — Annotation-based alternative for Android runtime permissions; similar problem space but uses code generation instead of fluent API
• tbruyelle/RxPermissions — RxJava-first permissions wrapper for Android; allows composing permission requests with Observable chains instead of callbacks
• google/material-components-android — Companion library; AndPermission often used in Material Design apps, shares androidx dependency and design patterns
• androidx/androidx — Core dependency; androidx.activity, androidx.fragment, and androidx.appcompat are implicit requirements for AndPermission to function

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for PermissionChecker and DoubleChecker classes

The permission/src/main/java/com/yanzhenjie/permission/checker/ directory contains multiple checker implementations (StandardChecker, StrictChecker, DoubleChecker, and specific permission tests) but there are no visible test files in the repo. These checkers are critical for permission validation logic and need unit test coverage to ensure they correctly validate runtime permissions across different Android versions.

• [ ] Create permission/src/test/java/com/yanzhenjie/permission/checker/ directory structure
• [ ] Add unit tests for PermissionChecker.java to verify permission detection logic
• [ ] Add unit tests for DoubleChecker.java to test dual-verification mechanism
• [ ] Add unit tests for StandardChecker and StrictChecker with mocked Context and PackageManager
• [ ] Add unit tests for individual permission test classes (StorageReadTest, CameraTest, LocationFineTest, etc.) to verify they correctly detect granted/denied states
• [ ] Use Mockito or Robolectric to mock Android framework components

Add GitHub Actions CI/CD workflow for automated testing and release

The repository uses Gradle build system with Bintray publishing configuration (gradle-bintray-plugin) but has no visible CI/CD pipeline. Adding a GitHub Actions workflow would automatically run tests on pull requests, ensure build integrity, and automate release processes to Maven/Jcenter, reducing manual work and catching regressions early.

• [ ] Create .github/workflows/build.yml to run ./gradlew build on all PRs targeting main branches
• [ ] Add Android SDK setup step using android-emulator-runner or setup-java action
• [ ] Create .github/workflows/publish.yml to automate release to Bintray when tags are pushed (using stored secrets for credentials)
• [ ] Add workflow status badges to README.md
• [ ] Document release process in CONTRIBUTING.md with instructions for version bumping and tagging

Add missing test cases for bridge components (BridgeActivity, BridgeService, Messenger)

The bridge package (permission/src/main/java/com/yanzhenjie/permission/bridge/) contains complex inter-process communication logic via AIDL and Messenger that lacks visible test coverage. BridgeActivity, BridgeService, and RequestManager handle critical request routing and callback mechanisms that need instrumentation tests to verify proper functioning across different scenarios (granted, denied, user cancellation).

• [ ] Create permission/src/androidTest/java/com/yanzhenjie/permission/bridge/ directory
• [ ] Add instrumentation tests for BridgeActivity.java to verify permission request UI flow and result handling
• [ ] Add instrumentation tests for BridgeService.java and Messenger.java to verify IPC communication
• [ ] Add tests for RequestManager.java to verify request queuing and callback execution
• [ ] Create test scenarios for both granted and denied permission flows
• [ ] Use AndroidX Test libraries (androidx.test) for instrumentation testing

• Add missing PermissionTest implementations for android.permission.ACCESS_MEDIA_LOCATION (MediaStore.getAttributionTags() on API 30+), android.permission.READ_PHONE_STATE (telephonyManager.getImei() requires actual runtime check). See permission/src/main/java/com/yanzhenjie/permission/checker/PhoneStateReadTest.java as template.
• Write unit tests for checker/ package: currently no test files visible. Create permission/src/test/java/com/yanzhenjie/permission/checker/DoubleCheckerTest.java and individual checker tests (CameraTestTest.java, LocationFineTestTest.java) mocking Android Context and Manager APIs.
• Document the AIDL bridge protocol in README.md or a separate docs/ARCHITECTURE.md: explain why BridgeActivity + BridgeService exist, when each is invoked (pre-M vs post-M devices), and IPC flow. Add sequence diagrams for permission request lifecycle.

The AndPermission library demonstrates moderate security concerns, primarily stemming from outdated and deprecated build dependencies. The most critical issues are: (1) Use of outdated Android Gradle Plugin (3.5.1) lacking modern security features and patches, (2) Deprecated Maven repository infrastructure (JCenter, Bintray) increasing supply chain risk, and (3) Outdated plugin dependencies. The codebase itself

• High · Outdated Gradle Build Plugin — build.gradle - classpath 'com.android.tools.build:gradle:3.5.1'. The project uses Android Gradle Plugin version 3.5.1, which is significantly outdated (released in 2019). This version contains multiple known security vulnerabilities and lacks important security fixes and features available in newer versions. Fix: Update to the latest stable Android Gradle Plugin version (currently 8.x). This will include security patches, improved dependency resolution, and better vulnerability detection.
• High · Insecure Maven Repository Configuration — build.gradle - repositories configuration with 'https://maven.aliyun.com/repository/jcenter' and deprecated jcenter(). The build configuration uses HTTP-based Maven repositories (Aliyun JCenter mirror). Additionally, the fallback to jcenter() repository is problematic as JCenter is deprecated and no longer maintained. This increases risk of dependency injection attacks and supply chain compromise. Fix: Replace deprecated jcenter() with Maven Central Repository (mavenCentral()) using HTTPS. Remove or replace the Aliyun mirror with official repositories. Use only well-maintained, official package repositories.
• Medium · Deprecated Bintray Plugin — build.gradle - classpath 'com.jfrog.bintray.gradle:gradle-bintray-plugin:1.8.4'. The build configuration includes gradle-bintray-plugin version 1.8.4. Bintray and JCenter were sunset by JFrog in 2021. Using this plugin may fail or expose the build process to security risks. Fix: Remove or replace the Bintray plugin. Use Maven Central Repository or Sonatype OSSRH for publishing open-source libraries instead.
• Medium · Outdated Android Maven Plugin — build.gradle - classpath 'com.github.dcendents:android-maven-gradle-plugin:2.1'. The android-maven-gradle-plugin version 2.1 is outdated and no longer actively maintained. It may not properly handle modern security configurations and dependency management. Fix: Update to the latest version or consider using the official Gradle publishing plugins (maven-publish) which are better integrated with modern build tools.
• Medium · AIDL Interface Potential Security Risk — permission/src/main/aidl/com/yanzhenjie/permission/bridge/IBridge.aidl and related bridge components. The codebase implements AIDL (Android Interface Definition Language) for inter-process communication via IBridge.aidl. AIDL interfaces can be vulnerable to unauthorized access if not properly secured with permission checks. The bridge service pattern requires strict validation. Fix: Ensure all AIDL service implementations (BridgeService.java) validate caller permissions and identity. Implement proper access control checks and use signature-based permissions for IPC calls.
• Low · FileProvider Usage Requires Proper Configuration — permission/src/main/java/com/yanzhenjie/permission/FileProvider.java. The FileProvider class is present in the codebase. FileProvider is used for secure file sharing but requires proper XML configuration to avoid exposing sensitive files. Fix: Verify that FileProvider is properly configured in AndroidManifest.xml with a restricted file path configuration. Ensure only necessary directories are exposed and follow the principle of least privilege.
• Low · Potential Intent-Based Security Issues — permission/src/main/java/com/yanzhenjie/permission/ - multiple request handler classes. The permission framework handles various intent-based operations (install requests, overlay requests, notification requests). Improper intent validation could lead to intent spoofing or privilege escalation. Fix: Ensure all intents are validated and use explicit intents when possible. Implement proper checks for intent action and data validation. Use StartActivityForResult with proper result code validation.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.