Runtime Permission: có những loại nào và nguyên lý hoạt động trong Android

Runtime Permission là gì?

Runtime Permission là mô hình bảo mật Android trong đó ứng dụng yêu cầu truy cập vào dữ liệu nhạy cảm tại thời điểm chức năng đó thực sự cần thiết cho người dùng. Trước Android 6.0, tất cả các quyền được cấp khi cài đặt ứng dụng và người dùng không thể thu hồi chúng nếu không gỡ cài đặt hoàn toàn ứng dụng.

Sự phát triển của mô hình quyền Android

Trước Android 6.0, người dùng thấy danh sách tất cả các quyền khi cài đặt và có thể chấp nhận tất cả hoặc từ chối cài đặt. Một nghiên cứu năm 2015 cho thấy 87% người dùng không đọc danh sách quyền khi cài đặt. Android 6.0 đã giới thiệu runtime permissions, chia quyền thành thông thường (tự động) và nguy hiểm (cần yêu cầu). Android 11 đã thêm quyền một lần — tự động thu hồi khi đóng ứng dụng. Android 13 đã giới thiệu Trình chọn ảnh và thông báo đẩy như các runtime permissions riêng biệt.

iOS sử dụng mô hình tương tự từ iOS 10, nơi quyền truy cập máy ảnh, micrô và vị trí địa lý được yêu cầu khi sử dụng lần đầu. Tuy nhiên, iOS không có khái niệm “quyền thông thường” — mỗi quyền được yêu cầu một cách rõ ràng và việc từ chối vẫn tồn tại cho đến khi nhà phát triển yêu cầu lại thông qua cài đặt hệ thống.

Runtime Permission hoạt động như thế nào trong Android?

Runtime Permission hoạt động thông qua hộp thoại hệ thống được gọi bởi phương thức requestPermissions() (AndroidX — ActivityResultLauncher). Hệ thống hiển thị hộp thoại tiêu chuẩn với lời giải thích và người dùng chọn “Cho phép” hoặc “Từ chối”. Sau phản hồi, một callback được kích hoạt nơi ứng dụng xử lý quyết định của người dùng.

Yêu cầu quyền qua ActivityResultLauncher

private lateinit var requestPermissionLauncher: ActivityResultLauncher<String>

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
            if (isGranted) {
                startCamera()
            } else {
                showPermissionDeniedDialog()
            }
        }
}

private fun checkCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA)
                == PackageManager.PERMISSION_GRANTED -> {
            startCamera()
        }
        ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA) -> {
            showRationaleDialog { requestPermissionLauncher.launch(Manifest.permission.CAMERA) }
        }
        else -> {
            requestPermissionLauncher.launch(Manifest.permission.CAMERA)
        }
    }
}

Phương thức shouldShowRequestPermissionRationale trả về true nếu người dùng đã từ chối yêu cầu một lần. Trong trường hợp này, nên hiển thị hộp thoại giải thích lý do ứng dụng cần quyền và chỉ sau đó mới yêu cầu lại. Điều này tăng khả năng đồng ý của người dùng lên 30–40% (dữ liệu Google I/O 2024).

Các loại quyền trong Android

Android phân loại tất cả các quyền thành nhiều cấp độ bảo vệ: thông thường, nguy hiểm, chữ ký và đặc biệt. Quyền thông thường được cấp tự động khi cài đặt. Quyền nguy hiểm yêu cầu yêu cầu runtime. Quyền chữ ký chỉ khả dụng cho các ứng dụng được ký bằng cùng một chứng chỉ.

Các nhóm quyền nguy hiểm

Quyền đặc biệt (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) yêu cầu điều hướng bổ sung đến cài đặt hệ thống qua Settings.ACTION_MANAGE_OVERLAY_PERMISSION. Các quyền này không thể được yêu cầu qua hộp thoại hệ thống tiêu chuẩn và yêu cầu hành động rõ ràng của người dùng trên màn hình cài đặt.

Yêu cầu quyền trong Android 12+

Android 12 đã giới thiệu những thay đổi đáng kể trong mô hình runtime permissions. Quyền một lần cho phép cấp quyền truy cập máy ảnh, micrô hoặc vị trí địa lý chỉ cho một phiên. Khi người dùng đóng ứng dụng, quyền sẽ tự động bị thu hồi. Chỉ báo quyền riêng tư là các chỉ báo màu xanh lá cây trên thanh trạng thái hiển thị khi ứng dụng đang sử dụng máy ảnh hoặc micrô.

Xử lý quyền một lần

// Android 12+ — xử lý quyền vị trí một lần
private fun checkLocationPermission() {
    val permissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->

        val fineLocationGranted = permissions[Manifest.permission.ACCESS_FINE_LOCATION]
        val coarseLocationGranted = permissions[Manifest.permission.ACCESS_COARSE_LOCATION]

        if (fineLocationGranted == true) {
            showUserLocation()
        } else {
            showLocationDisabledDialog()
        }
    }

    permissionLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION
        )
    )
}

// Kiểm tra xem quyền đã bị hệ thống thu hồi chưa (Android 12+)
class PermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_PERMISSION_REVOCATION) {
            handleRevokedPermission(intent.getStringExtra(Intent.EXTRA_REVOKED_PERMISSION))
        }
    }
}

Android 13 đã thêm quyền POST_NOTIFICATIONS vào nhóm nguy hiểm, yêu cầu yêu cầu rõ ràng để gửi thông báo đẩy. Android 14 đã đưa ra các hạn chế đối với vị trí địa lý nền: ứng dụng phải nhận được sự chấp thuận rõ ràng của người dùng mỗi khi yêu cầu vị trí nền. Trình chọn ảnh (API 33+) đã thay thế nhu cầu sử dụng READ_EXTERNAL_STORAGE để chọn ảnh.

Xử lý từ chối của người dùng

Từ chối của người dùng đối với yêu cầu quyền là tình huống bình thường cần được xử lý đúng cách. Có hai loại từ chối: một lần (người dùng nhấn “Từ chối”) và vĩnh viễn (người dùng chọn “Không hỏi lại”). Trong trường hợp thứ hai, hộp thoại hệ thống sẽ không xuất hiện nữa và ứng dụng phải chuyển hướng người dùng đến cài đặt hệ thống.

Chiến lược xử lý từ chối

Sau lần từ chối đầu tiên, ứng dụng nên hiển thị hộp thoại giải thích lý do — lời giải thích riêng về lý do cần quyền. Nếu người dùng từ chối lại, ứng dụng nên chuyển hướng đến màn hình cài đặt ứng dụng qua Settings.ACTION_APPLICATION_DETAILS_SETTINGS. Material 3 khuyến nghị sử dụng PermissionRequestBottomSheet để có UX tự nhiên hơn.

Điều quan trọng là không chặn hoàn toàn chức năng của ứng dụng khi bị từ chối. Ví dụ: nếu người dùng từ chối vị trí địa lý, ứng dụng nên cung cấp tùy chọn nhập địa chỉ thủ công. Đối với máy ảnh, cho phép tải ảnh lên từ thư viện. Google khuyến nghị luôn cung cấp cơ chế dự phòng cho tất cả các runtime permissions.

Khuyến nghị bảo mật

Runtime permissions không chỉ là cơ chế kỹ thuật mà còn là yếu tố tạo dựng niềm tin của người dùng vào ứng dụng. Yêu cầu quyền vào thời điểm không phù hợp (ví dụ: khi khởi chạy lần đầu) làm giảm đáng kể khả năng đồng ý. Google Play Store phân tích tần suất và bối cảnh của các yêu cầu quyền: các ứng dụng có yêu cầu quá mức nhận được thứ hạng tìm kiếm thấp hơn.

Quy tắc yêu cầu quyền

Bối cảnh — yêu cầu quyền ngay trước khi thực hiện hành động cần quyền đó. Tối thiểu — chỉ yêu cầu những quyền thực sự cần thiết cho chức năng hoạt động. Minh bạch — giải thích cho người dùng lý do cần quyền trước hộp thoại hệ thống. Thu hồi — đăng ký ACTION_PERMISSION_REVOCATION để xử lý chính xác việc thu hồi quyền trong thời gian chạy.

Để kiểm tra runtime permissions, sử dụng lệnh adb: adb shell pm revoke <package> android.permission.CAMERA cho phép mô phỏng thu hồi quyền mà không cần cài đặt lại ứng dụng. Espresso và UiAutomator hỗ trợ kiểm tra hộp thoại quyền thông qua GrantPermissionRule. Việc tích hợp các công cụ này vào quy trình CI/CD là bắt buộc đối với các ứng dụng có runtime permissions.

Kiểm toán quyền trong Google Play Console

Google Play Console cung cấp phần kiểm toán quyền, nơi nhà phát triển có thể thấy tần suất quyền được yêu cầu, phần trăm người dùng cấp quyền truy cập và quyền nào đã bị thu hồi. Phân tích dữ liệu này giúp xác định các yêu cầu không hiệu quả và tối ưu hóa UX. Ví dụ: nếu dưới 40% người dùng cấp quyền vị trí địa lý, hãy xem xét lại thời điểm yêu cầu và thêm lời giải thích thuyết phục hơn.

Việc sử dụng Android Vitals để giám sát ANR (Ứng dụng không phản hồi) liên quan đến quyền cũng rất quan trọng. Nếu yêu cầu quyền được thực thi trên luồng chính hoặc hộp thoại hệ thống chặn giao diện người dùng, điều này có thể gây ra ANR trên các thiết bị chậm. Di chuyển việc kiểm tra và yêu cầu quyền sang một luồng riêng hoặc sử dụng coroutines Kotlin để xử lý bất đồng bộ nhằm tránh chặn giao diện người dùng.