targetSdkVersion: βασικές έννοιες, behavioural changes και Google Play

Τι είναι το targetSdkVersion στο Android;

targetSdkVersion — μια ακέραια παράμετρος στο build.gradle που δηλώνει το επίπεδο API στο οποίο δοκιμάστηκε η εφαρμογή. Το σύστημα Android χρησιμοποιεί αυτήν την παράμετρο για να αποφασίσει ποια behavioural changes θα εφαρμόσει στην εφαρμογή κατά την εκτέλεση. Εάν targetSdkVersion = 33, το Android εφαρμόζει όλα τα behavioural changes που εισήχθησαν έως και το API 33, αλλά δεν εφαρμόζει αλλαγές API 34+. Εάν targetSdkVersion = 34 — εφαρμόζονται αλλαγές έως API 34, και ούτω καθεξής.

Η βασική διαφορά μεταξύ targetSdkVersion και minSdkVersion — ο μηχανισμός δράσης. Το minSdk ελέγχεται μία φορά κατά την εγκατάσταση και μπλοκάρει την εγκατάσταση εάν δεν πληρούται η προϋπόθεση. Το targetSdkVersion επηρεάζει τη συμπεριφορά runtime του συστήματος σε κάθε συσκευή, ανεξάρτητα από την έκδοση Android στην οποία εκτελείται η εφαρμογή. Η ίδια εφαρμογή με targetSdk 31 θα συμπεριφέρεται διαφορετικά σε Android 13, 14 και 15, επειδή τα behavioural changes άνω του 31 είναι απενεργοποιημένα.

Ο μηχανισμός targetSdkVersion — είναι ένα εργαλείο συμβατότητας προς τα πίσω ενσωματωμένο στο Android. Χωρίς αυτόν, κάθε ενημέρωση λειτουργικού συστήματος θα κατέστρεφε χιλιάδες παλιές εφαρμογές. Η Google εισήγαγε αυτόν τον μηχανισμό στο Android 2.1 (API Level 7) και από τότε τον χρησιμοποιεί ως τυπικό τρόπο εισαγωγής νέων κανόνων ασφαλείας, απορρήτου και διαχείρισης πόρων χωρίς να διαταράσσει τη λειτουργία υπαρχουσών εφαρμογών.

// build.gradle.kts — targetSdkVersion στο defaultConfig
android {
    namespace = "com.example.myapp"
    compileSdk = 36

    defaultConfig {
        applicationId = "com.example.myapp"
        minSdk = 26
        targetSdk = 36   // Δοκιμασμένο σε Android 16
        versionCode = 1
        versionName = "1.0.0"
    }
}

// Έλεγχος τρέχοντος targetSdk στον κώδικα
fun isUsingScopedStorage(): Boolean {
    // Context.getApplicationInfo().targetSdkVersion περιέχει το targetSdk της εφαρμογής
    return context.applicationInfo.targetSdkVersion >= VERSION_CODES.Q
}

Στο παράδειγμα, το targetSdk = 36 ενεργοποιεί όλα τα behavioural changes του Android 16. Ο κώδικας ελέγχει το targetSdkVersion μέσω του context.applicationInfo.targetSdkVersion — αυτό επιτρέπει τον δυναμικό προσδιορισμό της ενεργής λειτουργίας συμβατότητας. Η βοηθητική συνάρτηση είναι χρήσιμη για βιβλιοθήκες που πρέπει να προσαρμοστούν στο targetSdk της καλούσας εφαρμογής.

Behavioural Changes: πώς το targetSdk επηρεάζει την εφαρμογή

Behavioural changes — είναι τροποποιήσεις της συμπεριφοράς του συστήματος Android που εφαρμόζονται μόνο σε εφαρμογές με targetSdkVersion >= ένα συγκεκριμένο επίπεδο API. Κάθε νέα κύρια έκδοση Android εισάγει behavioural changes, και εάν η εφαρμογή δεν ενημερώνει το targetSdk, αυτές οι αλλαγές δεν τίθενται σε ισχύ. Ένας τέτοιος μηχανισμός επιτρέπει στους προγραμματιστές να ενημερώνουν την εφαρμογή με τον δικό τους ρυθμό, όχι συγχρονισμένα με την κυκλοφορία μιας νέας έκδοσης λειτουργικού συστήματος.

Scoped Storage (API 29) — μία από τις σημαντικότερες behavioural changes. Οι εφαρμογές με targetSdk 29+ δεν μπορούν να αποκτήσουν άμεση πρόσβαση File στους κοινόχρηστους καταλόγους Pictures, Downloads, Music, Documents. Αντίθετα, χρησιμοποιείται το MediaStore για πολυμέσα, το SAF (Storage Access Framework) για αυθαίρετα αρχεία και το getExternalFilesDir() για δική τους αποθήκευση. Οι παλιές εφαρμογές με targetSdk 28 και κάτω συνεχίζουν να λειτουργούν με την παλιά Πλήρη Πρόσβαση Αποθήκευσης, αλλά αυτό δημιουργεί απειλή ασφαλείας.

POST_NOTIFICATIONS (API 33) — άδεια runtime για αποστολή ειδοποιήσεων. Οι εφαρμογές με targetSdk 33+ πρέπει να ζητούν την άδεια Manifest.permission.POST_NOTIFICATIONS από τον χρήστη μέσω τυπικού διαλόγου. Εάν δεν παραχωρηθεί η άδεια, το NotificationManager.silent() δεν εμφανίζει ειδοποιήσεις στον χρήστη. Σε Android 13+ χωρίς αυτήν την άδεια, οι push ειδοποιήσεις και οι τοπικές ειδοποιήσεις απλά δεν εμφανίζονται, γεγονός που μπορεί να μειώσει σημαντικά την αφοσίωση των χρηστών.

Πώς να ελέγξετε το τρέχον targetSdk

Η τιμή targetSdkVersion της εφαρμογής μπορεί να ληφθεί μέσω ADB: η εντολή adb shell dumpsys package com.example.myapp | grep targetSdk εμφανίζει targetSdk=34. Στον κώδικα, το context.getApplicationInfo().targetSdkVersion επιστρέφει έναν ακέραιο αριθμό. Για ανάλυση, είναι χρήσιμο να καταγράφετε το targetSdk μαζί με το android.os.Build.VERSION.SDK_INT για να κατανοήσετε ποια behavioural changes είναι πραγματικά ενεργά σε κάθε συνεδρία.

Απαιτήσεις Google Play για targetSdkVersion (2026)

Google Play θέτει υποχρεωτικές απαιτήσεις για το targetSdkVersion για όλες τις δημοσιευμένες εφαρμογές. Από τον Αύγουστο 2024, ελάχιστο targetSdk = 33 (Android 13). Από τον Αύγουστο 2025 — targetSdk = 34. Αναμένεται από τον Αύγουστο 2026 η Google να απαιτήσει targetSdk = 35 (Android 15). Νέες εφαρμογές και ενημερώσεις υπαρχουσών εφαρμογών πρέπει να πληρούν αυτές τις απαιτήσεις, διαφορετικά η κονσόλα μπλοκάρει τη δημοσίευση. Αυτή είναι πολιτική του Google Play, όχι περιορισμός του Android Runtime: μια εφαρμογή με targetSdk 34 μπορεί να λειτουργεί σε Android 16, αλλά δεν μπορεί να δημοσιευθεί στο Play Store.

Android App Bundle (AAB) — η υποχρεωτική μορφή δημοσίευσης από τον Αύγουστο 2021. Το APK δεν γίνεται πλέον αποδεκτό στο Google Play (εξαίρεση — εφαρμογές με μέγεθος > 150 MB και ορισμένα legacy έργα). Η μορφή AAB επιτρέπει στην Google να δημιουργεί βελτιστοποιημένα APK για κάθε επίπεδο API και πυκνότητα οθόνης, μειώνοντας το μέγεθος λήψης κατά 15-30%. Για τον έλεγχο του targetSdk, το Google Play αναλύει το manifest AAB και σε περίπτωση μη συμμόρφωσης εμφανίζει σφάλμα με την ελάχιστη απαιτούμενη τιμή.

Η Google Play Console ελέγχει το targetSdkVersion όχι μόνο κατά τη μεταφόρτωση ενός νέου AAB, αλλά και κατά την ενημέρωση μιας υπάρχουσας εφαρμογής. Εάν η εφαρμογή σας έχει targetSdk 33 και η Google αυξήσει το ελάχιστο όριο σε 34 — δεν θα μπορείτε να κυκλοφορήσετε καμία ενημέρωση έως ότου αυξήσετε το targetSdk. Για εφαρμογές που δεν έχουν ενημερωθεί για μεγάλο χρονικό διάστημα, το Google Play μπορεί να τις αφαιρέσει αυτόματα από τη δημοσίευση (unpublish).

Πώς να ενημερώσετε το targetSdkVersion χωρίς σφάλματα

Η ενημέρωση του targetSdkVersion — δεν είναι απλώς αλλαγή ενός αριθμού στο build.gradle. Κάθε behavioural change μπορεί να σπάσει την υπάρχουσα λειτουργικότητα εάν ο κώδικας δεν προετοιμαστεί εκ των προτέρων. Συνιστάται να ξεκινήσετε την προετοιμασία 3-6 μήνες πριν από την προθεσμία του Google Play, ειδικά εάν η εφαρμογή είναι μεγάλη και χρησιμοποιεί πολλά API συστήματος.

Βήμα προς βήμα: Βήμα 1 — μελετήστε τα behavioural changes για το νέο επίπεδο API στην τεκμηρίωση Android Developers (σελίδα "Behavioural Changes by API Level"). Βήμα 2 — δημιουργήστε έναν κλάδο targetSdk-update και αλλάξτε το targetSdk στη νέα τιμή. Βήμα 3 — εκτελέστε την εφαρμογή σε εξομοιωτή ή συσκευή με το νέο επίπεδο API και ελέγξτε κάθε λειτουργία που σχετίζεται με τις αλλαγές. Βήμα 4 — διορθώστε σφάλματα: προσθέστε άδειες, αλλάξτε τον τρόπο εργασίας με αρχεία, ενημερώστε το manifest.

Βήμα 5 — δοκιμάστε σε παλιές συσκευές. Η αύξηση του targetSdk δεν επηρεάζει συσκευές με επίπεδο API χαμηλότερο από το νέο targetSdk, αλλά τα behavioural changes εφαρμόζονται σε όλες τις συσκευές με API Level >= targetSdk. Εάν αυξήσατε το targetSdk από 33 σε 34, σε συσκευές με API 34+ θα ενεργοποιηθούν τα behavioural changes του API 34. Σε συσκευές με API 33, τίποτα δεν θα αλλάξει.

// Προετοιμασία για targetSdk 35: Privacy Sandbox
import android.os.Build
import android.os.Build.VERSION_CODES
import com.google.android.gms.ads.identifier.AdvertisingIdClient

class AdsManager {

    fun getAdvertisingId(context: android.content.Context): String? {
        // Το Privacy Sandbox περιορίζει το Advertising ID από API 35
        if (Build.VERSION.SDK_INT >= VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+ — το αναγνωριστικό δεν είναι διαθέσιμο, χρησιμοποιούμε MeasurementManager
            return null
        }
        return try {
            val adInfo = AdvertisingIdClient.getAdvertisingIdInfo(context)
            adInfo.getId()
        } catch (e: Exception) {
            null
        }
    }

    // Έλεγχος: ποια behavioural changes είναι ενεργά
    fun getActiveChanges(context: android.content.Context): List<String> {
        val sdkInt = Build.VERSION.SDK_INT
        val targetSdk = context.applicationInfo.targetSdkVersion
        return buildList {
            if (sdkInt >= VERSION_CODES.Q && targetSdk >= VERSION_CODES.Q)
                add("ScopedStorage")
            if (sdkInt >= VERSION_CODES.TIRAMISU && targetSdk >= VERSION_CODES.TIRAMISU)
                add("PostNotifications")
            if (sdkInt >= VERSION_CODES.UPSIDE_DOWN_CAKE && targetSdk >= VERSION_CODES.UPSIDE_DOWN_CAKE)
                add("FgsTypes")
        }
    }
}

Η κλάση AdsManager δείχνει την προετοιμασία για το Privacy Sandbox (API 35). Το Advertising ID παύει να είναι διαθέσιμο από το API 35 με targetSdk 35+. Η συνάρτηση getActiveChanges δείχνει το σωστό μοτίβο ελέγχου behavioural changes: πρέπει να ελέγχετε ταυτόχρονα το SDK_INT της συσκευής και το targetSdk της εφαρμογής. Μόνο όταν πληρούνται και οι δύο προϋποθέσεις, η αλλαγή είναι πραγματικά ενεργή.

Android 15 (API 35): βασικά behavioural changes

Android 15 (API 35, Vanilla Ice Cream) εισάγει πολλά κρίσιμα behavioural changes που οι προγραμματιστές πρέπει να λάβουν υπόψη κατά την ενημέρωση του targetSdk σε 35. Πρώτο — Privacy Sandbox for Android. Αυτή είναι η πρωτοβουλία της Google να αντικαταστήσει το Advertising ID με πιο ιδιωτικά API: Topics API (ενδιαφέροντα χρήστη), Protected Audience (remarketing) και Attribution Reporting (μετατροπές). Από το API 35, το Advertising ID παύει να είναι σταθερό αναγνωριστικό και μπορεί να επιστρέφει μηδενική τιμή.

Δεύτερη αλλαγή — Foreground Service Types (API 34, συνεχίζεται στο API 35). Από το API 34, κάθε εφαρμογή με targetSdk 34+ πρέπει να καθορίζει τον τύπο foreground υπηρεσίας στο manifest: dataSync, systemExempted, shortService, location, mediaPlayback και άλλα. Χωρίς αυτό, το σύστημα δημιουργεί ForegroundServiceTypeNotAllowedException. Στο API 35 προστέθηκε ο νέος τύπος health και αυστηροποιήθηκε ο έλεγχος υπαρχόντων τύπων. Όλες οι foreground υπηρεσίες πρέπει να αναθεωρηθούν.

Τρίτη αλλαγή — περιορισμός SCHEDULE_EXACT_ALARM. Από το API 35, εφαρμογές με targetSdk 35+ δεν μπορούν να χρησιμοποιούν SCHEDULE_EXACT_ALARM χωρίς ρητή άδεια του χρήστη. Το σύστημα εμφανίζει έναν διάλογο και ο χρήστης πρέπει να εγκρίνει τον ακριβή προγραμματισμό. Για ξυπνητήρια και χρονοδιακόπτες, αυτό σημαίνει ένα επιπλέον βήμα στο UX. Εναλλακτική — χρήση inexact συναγερμών με περιθώριο 10 λεπτών.

// Android 15 (API 35): έλεγχος SCHEDULE_EXACT_ALARM
import android.app.AlarmManager
import android.os.Build
import android.provider.Settings

class AlarmScheduler {

    fun canScheduleExactAlarms(context: android.content.Context): Boolean {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM) {
            // API 35+: απαιτείται άδεια χρήστη
            val alarmManager = context.getSystemService(
                android.content.Context.ALARM_SERVICE
            ) as AlarmManager
            return alarmManager.canScheduleExactAlarms()
        }
        // Κάτω από API 35 — ακριβείς συναγερμοί διαθέσιμοι χωρίς άδεια
        return true
    }

    fun requestExactAlarmPermission(activity: android.app.Activity) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.VANILLA_ICE_CREAM) {
            val intent = android.content.Intent(
                Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM
            ).apply {
                data = android.net.Uri.fromParts(
                    "package", activity.packageName, null
                )
            }
            activity.startActivity(intent)
        }
    }
}

Privacy Sandbox και περιορισμός συναγερμών — δύο από τα πιο κρίσιμα behavioural changes του API 35. Για διαφημιστικά SDK, θα απαιτηθεί μετανάστευση σε Topics API και Attribution Reporting. Για εφαρμογές με ξυπνητήρια και υπενθυμίσεις — προσαρμογή UX στον διάλογο άδειας. Η αγνόηση αυτών των αλλαγών θα οδηγήσει σε σφάλμα της εφαρμογής σε runtime στο Android 15 ή σε μη λειτουργική διαφημιστική δημιουργία εσόδων.

Διαφορά μεταξύ targetSdk και compileSdk

Η διαφορά μεταξύ targetSdkVersion και compileSdkVersion — ένα από τα πιο συνηθισμένα θέματα σύγχυσης μεταξύ προγραμματιστών Android. Το compileSdkVersion — είναι η έκδοση SDK έναντι της οποίας μεταγλωττίζεται ο κώδικας. Καθορίζει ποια API είναι διαθέσιμα κατά τη μεταγλώττιση, αλλά δεν επηρεάζει τη συμπεριφορά runtime. Το targetSdkVersion — είναι η έκδοση στην οποία δοκιμάστηκε η εφαρμογή, καθορίζει ποια behavioural changes εφαρμόζονται στο runtime. Το compileSdk μπορεί και πρέπει να είναι υψηλότερο ή ίσο με το targetSdk.

Ο κανόνας είναι απλός: compileSdk >= targetSdk >= minSdk. Το compileSdk είναι συνήθως ίσο με το τελευταίο σταθερό επίπεδο API (το 2026 — 36). Το targetSdk πρέπει να είναι όσο το δυνατόν υψηλότερο μεταξύ των εκδόσεων που έχετε δοκιμάσει. Το minSdk πρέπει να είναι όσο το δυνατόν χαμηλότερο για μέγιστη κάλυψη. Η αύξηση του compileSdk δεν απαιτεί δοκιμή behavioural changes — απλώς ανοίγει πρόσβαση σε νέα API για τον μεταγλωττιστή. Η αύξηση του targetSdk απαιτεί πλήρη κύκλο δοκιμής όλων των behavioural changes.

Στην πράξη: εάν θέλετε να χρησιμοποιήσετε ένα νέο API από το Android 16 (API 36), αλλά δεν έχετε δοκιμάσει ακόμα τα behavioural changes του API 36, ορίστε compileSdk = 36, targetSdk = 35. Ο κώδικας θα μεταγλωττιστεί με τα νέα API, αλλά τα behavioural changes του API 36 δεν θα εφαρμοστούν. Μόλις δοκιμάσετε όλες τις αλλαγές — αυξήστε το targetSdk σε 36.