AndroidManifest Permissions: βασικές έννοιες, δήλωση και τύποι αδειών

Τι είναι τα AndroidManifest Permissions;

Τα AndroidManifest Permissions είναι ο μηχανισμός ασφαλείας του Android που ελέγχει την πρόσβαση των εφαρμογών σε προστατευμένα δεδομένα και λειτουργίες συστήματος. Κάθε εφαρμογή πρέπει να δηλώνει τις απαιτούμενες άδειες στο αρχείο AndroidManifest.xml χρησιμοποιώντας το στοιχείο <uses-permission>. Χωρίς δήλωση, η κλήση του αντίστοιχου API θα αποτύχει με σφάλμα ασφαλείας SecurityException.

Το μοντέλο αδειών του Android έχει περάσει από διάφορα στάδια εξέλιξης. Πριν από το Android 6.0 (API 23), όλες οι άδειες χορηγούνταν κατά την εγκατάσταση — ο χρήστης έβλεπε την πλήρη λίστα και αποδεχόταν ή απέρριπτε την εγκατάσταση της εφαρμογής. Από το Android 6.0, οι άδειες επιπέδου dangerous ζητούνται κατά την εκτέλεση (Runtime Permissions), δίνοντας στον χρήστη πιο ευέλικτο έλεγχο.

Οι άδειες χωρίζονται σε τέσσερα επίπεδα προστασίας: normal (χορηγούνται αυτόματα κατά την εγκατάσταση), dangerous (απαιτούν αίτημα κατά την εκτέλεση), signature (διαθέσιμες μόνο σε εφαρμογές υπογεγραμμένες με το ίδιο πιστοποιητικό) και special (απαιτούν ξεχωριστή ενεργοποίηση στις ρυθμίσεις). Κάθε επίπεδο έχει τον δικό του μηχανισμό χορήγησης και ανάκλησης.

Σύμφωνα με το Google I/O 2024, στο Android 15 σχεδιάζεται η εισαγωγή πιο λεπτομερών αδειών — ο χρήστης θα μπορεί να παρέχει πρόσβαση μόνο σε συγκεκριμένα αρχεία στην πολυμεσική βιβλιοθήκη, όχι σε ολόκληρη τη βιβλιοθήκη. Αυτό συνεχίζει την τάση του Android για ελαχιστοποίηση του όγκου των δεδομένων που παρέχονται προεπιλεγμένα.

Διαφορά από το μοντέλο αδειών iOS

Σε αντίθεση με το iOS, όπου όλες οι άδειες ζητούνται κατά την εκτέλεση (runtime), το Android χωρίζει τις άδειες σε εγκατάστασης (install-time) και εκτέλεσης (runtime). Το επίπεδο normal χορηγείται αυτόματα κατά την εγκατάσταση χωρίς ειδοποίηση του χρήστη. Το επίπεδο dangerous απαιτεί ρητό διάλογο, όπως στο iOS.

Μια άλλη διαφορά: στο Android, οι άδειες ομαδοποιούνται σε ομάδες (permission groups). Αν ο χρήστης αποδέχθηκε την πρόσβαση στην κάμερα, η εφαρμογή αποκτά αυτόματα πρόσβαση στο μικρόφωνο — βρίσκονται στην ίδια ομάδα MICROPHONE. Στο iOS, κάθε άδεια ζητείται ξεχωριστά, ανεξάρτητα από την ομάδα.

Εξέλιξη αδειών ανά έκδοση Android

Ποιοι τύποι αδειών υπάρχουν

Το Android ορίζει τέσσερα επίπεδα προστασίας (protection levels) για τις άδειες, το καθένα με δικούς του κανόνες χορήγησης. Ας εξετάσουμε κάθε επίπεδο λεπτομερώς.

Normal Permissions (install-time)

Οι normal άδειες χορηγούνται αυτόματα κατά την εγκατάσταση της εφαρμογής χωρίς ειδοποίηση ή αίτημα από τον χρήστη. Καλύπτουν πρόσβαση σε λειτουργίες χαμηλού κινδύνου που δεν απειλούν το απόρρητο του χρήστη: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. Ο χρήστης δεν βλέπει διάλογο συγκατάθεσης — η άδεια θεωρείται χορηγημένη με την εγκατάσταση.

Ο προγραμματιστής δεν χρειάζεται να επεξεργαστεί αίτημα στον κώδικα για normal άδειες — αρκεί να τις δηλώσει στο manifest. Ωστόσο, στο Android 12+ κατά την εγκατάσταση από το Google Play, ο χρήστης βλέπει την καρτέλα “Άδειες” με λίστα όλων των normal αδειών, αυξάνοντας τη διαφάνεια. Σύμφωνα με το Statista (2024), πάνω από το 90% των εφαρμογών στο Google Play χρησιμοποιούν το INTERNET ως την πιο κοινή normal άδεια.

Dangerous Permissions (runtime)

Οι dangerous άδειες καλύπτουν πρόσβαση σε δεδομένα και λειτουργίες που μπορούν να παραβιάσουν το απόρρητο: κάμερα, μικρόφωνο, γεωτοποθεσία, επαφές, SMS, τηλέφωνο, ημερολόγιο, αισθητήρες σώματος. Αυτές οι άδειες απαιτούν δύο σταδίων μηχανισμό: δήλωση στο manifest + αίτημα κατά την εκτέλεση μέσω ActivityCompat.requestPermissions().

Ο χρήστης μπορεί να αρνηθεί τη χορήγηση dangerous άδειας, και η εφαρμογή πρέπει να χειριστεί σωστά αυτό το σενάριο. Στο Android 11+, αν ο χρήστης αρνήθηκε δύο φορές, τα επόμενα αιτήματα δεν εμφανίζουν τον διάλογο συστήματος — το σύστημα επιστρέφει αυτόματα DENIED. Σε αυτή την περίπτωση, πρέπει να κατευθύνετε τον χρήστη στις ρυθμίσεις.

Signature και Special Permissions

Το επίπεδο signature — η άδεια χορηγείται αυτόματα αν η εφαρμογή είναι υπογεγραμμένη με το ίδιο πιστοποιητικό με το σύστημα ή άλλη εφαρμογή που όρισε την άδεια. Χρησιμοποιείται για εφαρμογές συστήματος και εταιρικές εφαρμογές. Παράδειγμα: BIND_ACCESSIBILITY_SERVICE — διαθέσιμο μόνο σε εφαρμογές συστήματος.

Το επίπεδο special (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — απαιτεί ξεχωριστή ενέργεια του χρήστη μέσω ρυθμίσεων συστήματος. Η εφαρμογή μπορεί να ανοίξει τη σελίδα ρυθμίσεων με Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION). Το Google Play περιορίζει τη χρήση special αδειών και απαιτεί αιτιολόγηση στη φόρμα κατά τη δημοσίευση.

Runtime Permission: εργασία με dangerous άδειες

Από το Android 6.0, όλες οι dangerous άδειες απαιτούν αίτημα κατά την εκτέλεση. Ας εξετάσουμε τον πλήρη κύκλο εργασίας με runtime permissions στο Kotlin.

Έλεγχος και αίτημα άδειας

Πριν καλέσετε ένα API που απαιτεί dangerous άδεια, ελέγχετε πάντα την τρέχουσα κατάσταση μέσω ContextCompat.checkSelfPermission(). Αν η κατάσταση είναι PERMISSION_GRANTED — το API μπορεί να κληθεί. Αν είναι PERMISSION_DENIED — η άδεια πρέπει να ζητηθεί μέσω ActivityResultContract RequestPermission (AndroidX) ή του παρωχημένου requestPermissions().

Συνιστάται η χρήση του ActivityResultContracts.RequestMultiplePermissions για ταυτόχρονη αίτηση πολλαπλών αδειών. Η Google συνιστά την ομαδοποίηση σχετικών αδειών (π.χ. κάμερα + μικρόφωνο για εγγραφή βίντεο) σε έναν διάλογο, ώστε ο χρήστης να βλέπει το πλήρες πλαίσιο του αιτήματος.

import android.Manifest
import android.content.pm.PackageManager
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

class CameraActivity : AppCompatActivity() {
    private val requestPermissionLauncher =
        registerForActivityResult(
            ActivityResultContracts.RequestPermission()
        ) { isGranted: Boolean ->
            if (isGranted) {
                openCamera()
            } else {
                explainWhyPermissionNeeded()
            }
        }

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

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

Χειρισμός άρνησης “Don’t ask again”

Αν ο χρήστης αρνήθηκε την άδεια δύο φορές, το Android μεταφέρει το αίτημα σε κατάσταση “Never ask again”. Σε αυτή την περίπτωση, η shouldShowRequestPermissionRationale() επιστρέφει false, και ο διάλογος συστήματος δεν θα εμφανιστεί. Η εφαρμογή πρέπει να κατευθύνει τον χρήστη στις ρυθμίσεις συστήματος μέσω Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).

Σημαντικό: μην εμφανίζετε διάλογο με πρόταση ανοίγματος των ρυθμίσεων αμέσως μετά την πρώτη άρνηση — αυτό εκλαμβάνεται ως επιθετική συμπεριφορά. Χρησιμοποιήστε τη shouldShowRequestPermissionRationale() για να καθορίσετε αν χρειάζεται να εμφανιστεί εξήγηση. Οι Material Design Guidelines συνιστούν την εμφάνιση οθόνης με εξήγηση της αξίας της πρόσβασης, όχι απλά ένα κουμπί “Άνοιγμα ρυθμίσεων”.

private fun openAppSettings() {
    Intent(
        Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
        Uri.fromParts("package", packageName, null)
    ).also { intent ->
        startActivity(intent)
    }
}

private fun showPermissionSettings() {
    AlertDialog.Builder(this)
        .setTitle("Πρόσβαση στην κάμερα")
        .setMessage("Επιτρέψτε την πρόσβαση στην κάμερα στις Ρυθμίσεις, "
            + "για λήψη φωτογραφίας προφίλ")
        .setPositiveButton("Άνοιγμα ρυθμίσεων") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("Ακύρωση", null)
        .show()
}

Δήλωση αδειών στο AndroidManifest.xml

Το αρχείο AndroidManifest.xml περιέχει το στοιχείο <uses-permission> για κάθε άδεια που χρησιμοποιεί η εφαρμογή. Οι άδειες δηλώνονται στο επίπεδο <manifest> πριν από το στοιχείο <application>.

Σύνταξη δήλωσης

Κάθε άδεια δηλώνεται ως ξεχωριστό στοιχείο <uses-permission> με το χαρακτηριστικό android:name που υποδεικνύει το πλήρες όνομα της άδειας. Για άδειες που εμφανίστηκαν σε συγκεκριμένες εκδόσεις Android, χρησιμοποιήστε το χαρακτηριστικό maxSdkVersion για να περιορίσετε τη δήλωση μόνο στις απαραίτητες εκδόσεις — αυτό βελτιώνει τη συμβατότητα.

Για παράδειγμα, η άδεια WRITE_EXTERNAL_STORAGE δεν χρειάζεται σε Android 10+ (Scoped Storage), οπότε καθορίστε maxSdkVersion=“28” (Android 9). Αυτό αποτρέπει περιττές ερωτήσεις από χρήστες σε νεότερες εκδόσεις. Το Android Studio προειδοποιεί για συνιστώμενες maxSdkVersion μέσω Lint.

<!-- AndroidManifest.xml -->
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions (install-time) -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.ACCESS_NETWORK_STATE" />

    <!-- Dangerous permissions (runtime) -->
    <uses-permission
        android:name="android.permission.CAMERA" />
    <uses-permission
        android:name="android.permission.ACCESS_FINE_LOCATION" />

    <!-- Legacy storage permission limited to API 28 and below -->
    <uses-permission
        android:name="android.permission.WRITE_EXTERNAL_STORAGE"
        android:maxSdkVersion="28" />

    <uses-feature
        android:name="android.hardware.camera"
        android:required="false" />

    <application>
        <!-- ... -->
    </application>
</manifest>

Χρήση <uses-feature> για φιλτράρισμα

Το στοιχείο <uses-feature> καθορίζει ότι η εφαρμογή απαιτεί συγκεκριμένο υλικό (κάμερα, GPS, NFC). Το χαρακτηριστικό android:required=“false” επιτρέπει την εγκατάσταση της εφαρμογής σε συσκευές χωρίς αυτό το υλικό — ο έλεγχος διαθεσιμότητας γίνεται στον κώδικα. Αν required=“true”, το Google Play φιλτράρει την εφαρμογή και αυτή γίνεται μη διαθέσιμη για ακατάλληλες συσκευές.

Συνιστάται για όλες τις λειτουργίες υλικού να καθορίζετε required=“false” και να ελέγχετε τη διαθεσιμότητα προγραμματιστικά μέσω PackageManager.hasSystemFeature(). Αυτό διευρύνει το κοινό της εφαρμογής σας. Η μόνη εξαίρεση είναι όταν η λειτουργία είναι κρίσιμη για τη λειτουργία της εφαρμογής (μια εφαρμογή παραγγελίας ταξί χωρίς GPS δεν έχει νόημα).

Βέλτιστες πρακτικές και λάθη

Η σωστή εργασία με άδειες είναι μια βασική πτυχή της ποιότητας της εφαρμογής Android. Ας εξετάσουμε τις κύριες συστάσεις και τα τυπικά λάθη.

Ελαχιστοποίηση των αιτούμενων αδειών

Ζητάτε μόνο τις άδειες που είναι πραγματικά απαραίτητες για τη λειτουργία της εφαρμογής. Κάθε επιπλέον άδεια μειώνει τη μετατροπή εγκαταστάσεων και αυξάνει τον αριθμό των αρνήσεων. Η Google Play Console δείχνει πόσοι χρήστες εγκατέλειψαν την εγκατάσταση λόγω του συνόλου αδειών. Σύμφωνα με το AppBrain (2024), οι εφαρμογές με 10+ dangerous άδειες έχουν 35% λιγότερες εγκαταστάσεις.

Εξετάζετε τακτικά τη λίστα αδειών. Αφαιρείτε τις αχρησιμοποίητες, ειδικά κατά τη μετάβαση σε νεότερες εκδόσεις Android όπου ορισμένες άδειες έγιναν προαιρετικές. Για παράδειγμα, με την εμφάνιση του επιλογέα φωτογραφιών (ActivityResultContracts.PickVisualMedia) στο Android 13+, η πρόσβαση στην πολυμεσική βιβλιοθήκη μπορεί να αποκτηθεί χωρίς την dangerous άδεια READ_MEDIA_IMAGES.

Εμφάνιση αιτιολόγησης πριν από το αίτημα

Πριν ζητήσετε dangerous άδεια, εμφανίστε στον χρήστη μια οθόνη με εξήγηση γιατί χρειάζεται αυτή η άδεια και ποια αξία παρέχει. Το Material Design συνιστά τη χρήση bottom sheet ή διαλόγου με εικονίδιο, σύντομο κείμενο και κουμπί “Συνέχεια”. Η αιτιολόγηση αυξάνει τη συγκατάθεση κατά 20–30% σε σύγκριση με το άμεσο αίτημα.

Ελέγχετε τη shouldShowRequestPermissionRationale() πριν καλέσετε τη launch(). Αν είναι true — εμφανίστε αιτιολόγηση. Αν είναι false — είτε η άδεια έχει ήδη δοθεί είτε ο χρήστης αρνήθηκε οριστικά (never ask again). Στην τελευταία περίπτωση, εμφανίστε ένα κουμπί “Άνοιγμα ρυθμίσεων”, μην επαναλαμβάνετε το αίτημα.

Δοκιμή όλων των σεναρίων αδειών

Δοκιμάστε όλα τα πιθανά σενάρια: χορήγηση άδειας, άρνηση, οριστική άρνηση, ανάκληση άδειας στις ρυθμίσεις, επαναφορά αδειών (Android 11+ auto-reset). Κάθε σενάριο πρέπει να αντιμετωπίζεται χωρίς crash και χωρίς απώλεια δεδομένων. Ο Android Testing Guide συνιστά τη χρήση της βιβλιοθήκης TestPermission για αυτοματοποίηση δοκιμών.

Δώστε ιδιαίτερη προσοχή στο σενάριο όταν ο χρήστης ανακαλεί την άδεια κατά τη λειτουργία της εφαρμογής (ελαχιστοποιημένη εφαρμογή → Ρυθμίσεις → ανάκληση). Κατά την επιστροφή στην εφαρμογή, ελέγξτε ξανά όλες τις άδειες μέσω onResume(). Μην βασίζεστε στην προσωρινή αποθήκευση της κατάστασης αδειών — ο χρήστης μπορεί να τις αλλάξει ανά πάσα στιγμή.

Τυπικά λάθη

• Αίτημα άδειας χωρίς προηγούμενο έλεγχο checkSelfPermission — προκαλεί περιττό διάλογο
• Αγνόηση της shouldShowRequestPermissionRationale — χειροτερεύει την εμπειρία χρήστη μετά την πρώτη άρνηση
• Αίτημα άδειας χωρίς πλαίσιο (μόνο “Να επιτραπεί η πρόσβαση;”) — μειώνει τη συγκατάθεση
• Χρήση WRITE_EXTERNAL_STORAGE σε Android 10+ χωρίς maxSdkVersion — περιττό αίτημα
• Έλλειψη ελέγχου αδειών στο onResume — παράβλεψη ανάκλησης άδειας στις ρυθμίσεις