App Standby — τι είναι, επίπεδα αναμονής και αρχή λειτουργίας

Τι είναι το App Standby

App Standby είναι ένα στοιχείο του συστήματος διαχείρισης ενέργειας Android, που εισήχθη στο Android 6.0 (API 23) και ανασχεδιάστηκε σημαντικά στο Android 9 (API 28). Ο σκοπός του είναι να καθορίσει ποιες εφαρμογές χρησιμοποιούνται σπάνια από τον χρήστη και να περιορίσει τη δραστηριότητα παρασκηνίου τους: αιτήματα δικτύου, συγχρονισμό, JobScheduler και AlarmManager. Σε αντίθεση με το Doze, το App Standby δεν εξαρτάται από την κατάσταση οθόνης ή την κίνηση της συσκευής.

Το σύστημα ταξινομεί τις εφαρμογές σε τέσσερα bucket (επίπεδα): Active, Working Set, Frequent και Rare. Κάθε επίπεδο καθορίζει πόσο περιορίζεται η δραστηριότητα παρασκηνίου. Η μετάβαση μεταξύ επιπέδων γίνεται αυτόματα βάσει προτύπων χρήσης της εφαρμογής: πόσο συχνά την ανοίγει ο χρήστης, λαμβάνει ειδοποιήσεις, αλληλεπιδρά με widget.

Το App Standby λειτουργεί παράλληλα με το Doze Mode, αλλά δεν το αντικαθιστά. Εάν το Doze περιορίζει τη δραστηριότητα παρασκηνίου όλων των εφαρμογών όταν η συσκευή είναι ανενεργή, το App Standby περιορίζει συγκεκριμένες εφαρμογές ανεξάρτητα από την κατάσταση της συσκευής. Μια εφαρμογή με επίπεδο Rare θα έχει περιορισμούς ακόμη και κατά την ενεργή χρήση του τηλεφώνου, εάν ο χρήστης δεν την έχει ανοίξει για αρκετές ημέρες.

Bucket σε Android 9+

Από Android 9 (API 28) και μετά, η Google εισήγαγε τα App Standby Buckets — μια επίσημη ταξινόμηση με αριθμητικές τιμές. Το σύστημα χρησιμοποιεί μηχανική μάθηση για να προβλέψει την επόμενη εκκίνηση της εφαρμογής. Εάν το μοντέλο προβλέπει ότι η εφαρμογή θα ανοίξει τις επόμενες ώρες, λαμβάνει bucket Active. Εάν η πρόβλεψη υποδεικνύει σπάνια χρήση — εκχωρείται Rare.

Πώς λειτουργεί το App Standby

App Standby αναλύει διάφορους παράγοντες για τον καθορισμό του bucket: χρόνος από το τελευταίο άνοιγμα της εφαρμογής από τον χρήστη, συχνότητα αλληλεπίδρασης (αριθμός εκκινήσεων ανά ημέρα/εβδομάδα), λήψη ειδοποιήσεων FCM, παρουσία ενεργών widget στην αρχική οθόνη και συνδρομή στο AlarmManager. Όσο περισσότερο δεν χρησιμοποιείται μια εφαρμογή, τόσο χαμηλότερο είναι το bucket της και τόσο αυστηρότεροι οι περιορισμοί.

Η υπηρεσία συστήματος UsageStatsManager συλλέγει στατιστικά χρήσης εφαρμογών και τα μεταφέρει στο StandbyController — ένα στοιχείο πλαισίου που υπολογίζει το bucket για κάθε εφαρμογή. Το StandbyController λαμβάνει επίσης υπόψη συμβάντα συστήματος: μετά την ενημέρωση της εφαρμογής, το bucket της επαναφέρεται σε Active για λίγες ημέρες, ώστε ο χρήστης να μπορεί να αξιολογήσει νέες λειτουργίες.

Σημαντικό χαρακτηριστικό: App Standby δεν σκοτώνει τη διαδικασία της εφαρμογής, αλλά περιορίζει τις δυνατότητες παρασκηνίου της. Η εφαρμογή συνεχίζει να λειτουργεί εάν ο χρήστης αλληλεπιδρά με αυτήν (bucket Active). Μόλις ο χρήστης ελαχιστοποιήσει την εφαρμογή και δεν επιστρέψει σε αυτήν, το σύστημα αρχίζει να μετρά τον χρόνο αδράνειας και μπορεί να μειώσει το bucket σε Working Set ή Frequent.

Επίδραση του FCM στο bucket

Η λήψη ενός μηνύματος FCM high-priority μπορεί προσωρινά να αυξήσει το bucket της εφαρμογής σε Active. Αυτό δίνει στην εφαρμογή τη δυνατότητα να εκτελέσει μια εργασία (επεξεργασία μηνύματος, συγχρονισμό δεδομένων) χωρίς περιορισμούς. Ωστόσο, μετά την ολοκλήρωση της επεξεργασίας, το bucket επιστρέφει στην αρχική τιμή. Η Google συνιστά τη χρήση αυτού του μηχανισμού για την παράδοση σημαντικών ειδοποιήσεων, όχι για τη διατήρηση της εφαρμογής “ζωντανής”.

Επίπεδα App Standby

App Standby χρησιμοποιεί τέσσερα επίπεδα (bucket) για την ταξινόμηση εφαρμογών. Κάθε επίπεδο καθορίζει τον χρόνο καθυστέρησης για εργασίες παρασκηνίου: όσο χαμηλότερο το επίπεδο, τόσο μεγαλύτερη η καθυστέρηση. Το σύστημα μετακινεί αυτόματα την εφαρμογή μεταξύ επιπέδων βάσει στατιστικών χρήσης που συλλέχθηκαν τις τελευταίες 7–14 ημέρες.

Active — ενεργή εφαρμογή

Active — η εφαρμογή με την οποία ο χρήστης αλληλεπίδρασε πρόσφατα (εκκίνησε, έλαβε ειδοποίηση ή χρησιμοποίησε widget). Σε αυτό το bucket δεν υπάρχουν περιορισμοί: το JobScheduler ξεκινά αμέσως, το δίκτυο είναι διαθέσιμο, το AlarmManager λειτουργεί με ακρίβεια. Η εφαρμογή παραμένει σε Active έως ότου ο χρήστης σταματήσει να αλληλεπιδρά με αυτήν για αρκετές ώρες.

Working Set και Frequent

Working Set — η εφαρμογή χρησιμοποιείται τακτικά (αρκετές φορές την εβδομάδα). Καθυστέρηση εργασιών παρασκηνίου έως 2 ώρες. Frequent — η εφαρμογή χρησιμοποιείται αρκετές φορές τον μήνα. Καθυστέρηση έως 4 ώρες. Και στα δύο επίπεδα, το δίκτυο είναι διαθέσιμο μόνο σε παράθυρα συντήρησης και το AlarmManager μπορεί να καθυστερήσει. Το JobScheduler εκτελεί εργασίες στο πλησιέστερο παράθυρο.

Rare — σπάνια χρησιμοποιούμενη

Rare — το αυστηρότερο επίπεδο, που εκχωρείται σε εφαρμογές που ο χρήστης δεν έχει ανοίξει για περισσότερες από 30 ημέρες. Η καθυστέρηση εργασιών παρασκηνίου φτάνει τις 24 ώρες. Το δίκτυο είναι εντελώς αποκλεισμένο εκτός παραθύρων συντήρησης, το AlarmManager λειτουργεί μόνο με σημαίες setAndAllowWhileIdle() με περιορισμό 1 φορά κάθε 9 λεπτά. Οι ειδοποιήσεις FCM high-priority εξακολουθούν να παραδίδονται, αλλά δεν μπορούν να αυξήσουν το bucket.

Περιορισμοί στο App Standby

App Standby επιβάλλει περιορισμούς σε διάφορες κατηγορίες λειτουργιών παρασκηνίου. Σε αντίθεση με το Doze, οι περιορισμοί του App Standby λειτουργούν ανεξάρτητα από την κατάσταση οθόνης και τον φορτιστή. Ο προγραμματιστής πρέπει να σχεδιάζει την εφαρμογή λαμβάνοντας υπόψη αυτούς τους περιορισμούς, ειδικά εάν το κοινό-στόχος χρησιμοποιεί την εφαρμογή ακανόνιστα.

JobScheduler και WorkManager

JobScheduler — το κύριο API στο οποίο το App Standby έχει επίδραση. Ανάλογα με το bucket, η καθυστέρηση εκτέλεσης εργασιών κυμαίνεται από 2 έως 24 ώρες. Το WorkManager, που χρησιμοποιεί το JobScheduler κάτω από το καπό (σε API 23+), υπόκειται επίσης σε αυτές τις καθυστερήσεις. Για χρονικά κρίσιμες εργασίες, χρησιμοποιήστε το Expedited Work, που εκκινεί μια Foreground Service κάτω από το καπό και δεν εξαρτάται από το bucket.

Περιορισμοί δικτύου

Εφαρμογές στο bucket Working Set, Frequent και Rare δεν μπορούν να εκτελούν αυθαίρετα αιτήματα δικτύου ανά πάσα στιγμή. Το σύστημα επιτρέπει πρόσβαση στο δίκτυο μόνο σε παράθυρα συντήρησης που συγχρονίζονται με το Doze. Για αποστολή κρίσιμων δεδομένων, χρησιμοποιήστε FCM high-priority με επακόλουθο συγχρονισμό στο παράθυρο συντήρησης.

AlarmManager

AlarmManager στο App Standby υπόκειται στους ίδιους κανόνες όπως στο Doze: ακριβείς ειδοποιήσεις (setExact()) καθυστερούν και setAndAllowWhileIdle() περιορίζεται σε 1 φορά κάθε 9 λεπτά. Για το bucket Rare, η καθυστέρηση μπορεί να φτάσει τις 24 ώρες, καθιστώντας το AlarmManager ακατάλληλο για ακριβή προγραμματισμό εργασιών σε σπάνια χρησιμοποιούμενες εφαρμογές.

• JobScheduler — οι εργασίες καθυστερούν 2–24 ώρες ανάλογα με το bucket
• Δίκτυο — πρόσβαση μόνο σε παράθυρα συντήρησης για Working Set και κάτω
• AlarmManager — ακριβείς ειδοποιήσεις καθυστερούν· setAndAllowWhileIdle — 1/9 λεπτά
• SyncManager — ο συγχρονισμός λογαριασμών καθυστερεί έως το παράθυρο συντήρησης
• Widget updates — η συχνότητα ενημέρωσης widget μπορεί να μειωθεί

Πώς να λάβετε εξαίρεση

Εξαίρεση από το App Standby μπορεί να ληφθεί με δύο τρόπους: μέσω ρυθμίσεων μπαταρίας χρήστη (χειροκίνητη Whitelist) ή μέσω συστήματος Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS. Ωστόσο, η Google ρυθμίζει αυστηρά την πρόσβαση σε εξαιρέσεις — εφαρμογές που δεν έχουν βάσιμο λόγο για εξαίρεση κινδυνεύουν να απορριφθούν στο Google Play.

Ο χρήστης μπορεί χειροκίνητα να απενεργοποιήσει τους περιορισμούς για μια συγκεκριμένη εφαρμογή μέσω Ρυθμίσεις → Εφαρμογές → [Εφαρμογή] → Μπαταρία → Βελτιστοποίηση → Μην βελτιστοποιείτε. Αυτό αφαιρεί εντελώς τους περιορισμούς App Standby και Doze για την επιλεγμένη εφαρμογή. Ο προγραμματιστής μπορεί να εμφανίσει οδηγίες ή διάλογο συστήματος στον χρήστη, αλλά δεν μπορεί να προσθέσει αναγκαστικά την εφαρμογή σε εξαιρέσεις.

Foreground Service με ειδοποίηση λαμβάνει αυτόματα προσωρινή εξαίρεση από το App Standby. Όσο η υπηρεσία λειτουργεί και εμφανίζει ειδοποίηση, η εφαρμογή μεταφέρεται σε bucket Active ανεξάρτητα από το πραγματικό της επίπεδο. Μετά τη διακοπή της υπηρεσίας, το bucket επιστρέφει στην αρχική τιμή. Αυτός είναι ο πιο αξιόπιστος τρόπος για να εγγυηθεί η εργασία παρασκηνίου χωρίς αίτηση εξαιρέσεων συστήματος.

Πότε να ζητήσετε εξαίρεση

Η αίτηση Whitelist έχει νόημα μόνο για εφαρμογές με κρίσιμη λειτουργικότητα παρασκηνίου: πλοήγηση σε πραγματικό χρόνο, παρακολούθηση υγείας, κλήσεις VoIP, προστασία συσκευής. Για τις περισσότερες εφαρμογές, αρκεί η χρήση Foreground Service ή WorkManager. Το Google Play μπορεί να απορρίψει τη δημοσίευση εάν η εφαρμογή ζητά εξαίρεση χωρίς προφανή ανάγκη.

// Αίτημα εξαίρεσης από το App Standby
val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply {
    data = Uri.parse("package:\${applicationContext.packageName}")
}

// Έλεγχος τρέχουσας κατάστασης
val powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager
val isIgnoring = powerManager.isIgnoringBatteryOptimizations(packageName)

Δοκιμή App Standby

Δοκιμή του App Standby μέσω ADB επιτρέπει την αναγκαστική εκχώρηση οποιουδήποτε bucket στην εφαρμογή και τον έλεγχο της συμπεριφοράς της. Αυτό είναι κρίσιμο για εφαρμογές που βασίζονται σε συγχρονισμό παρασκηνίου, ειδοποιήσεις ή περιοδικές ενημερώσεις. Η δοκιμή πρέπει να διεξάγεται σε φυσική συσκευή ή εξομοιωτή με Android 9+.

Για τον αναγκαστικό καθορισμό bucket χρησιμοποιείται η εντολή adb shell am set-standby-bucket [package] [bucket], όπου bucket μπορεί να είναι: active, working_set, frequent ή rare. Για προβολή τρέχοντος bucket — adb shell am get-standby-bucket [package]. Το σύστημα επιτρέπει επίσης προσομοίωση παρατεταμένης αδράνειας της εφαρμογής μέσω της εντολής adb shell dumpsys usagestats.

# Ορισμός bucket Rare για την εφαρμογή
$ adb shell am set-standby-bucket com.example.app rare

# Προβολή τρέχοντος bucket
$ adb shell am get-standby-bucket com.example.app

# Επαναφορά όλων των bucket σε Active
$ adb shell dumpsys usagestats clear

# Προβολή όλων των bucket συστήματος
$ adb shell dumpsys usagestats

Τι να ελέγξετε

Μετά τον καθορισμό του bucket Rare ελέγξτε: εκτελείται η εργασία WorkManager εντός 24 ωρών, ενεργοποιείται το AlarmManager, παραδίδονται οι ειδοποιήσεις FCM, λειτουργεί η Foreground Service χωρίς περιορισμούς. Το WorkManager με πολιτική Expedited Work θα πρέπει να εκτελείται αμέσως ακόμη και σε bucket Rare, επειδή χρησιμοποιεί Foreground Service. Οι συνηθισμένες εργασίες WorkManager θα καθυστερήσουν σύμφωνα με το bucket.

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

Η ανάπτυξη μιας εφαρμογής ανθεκτικής στο App Standby απαιτεί συνειδητή προσέγγιση στις εργασίες παρασκηνίου. Η βασική αρχή: μην υποθέτετε ότι η εφαρμογή βρίσκεται πάντα σε bucket Active. Σχεδιάστε την εργασία παρασκηνίου ώστε να λειτουργεί σωστά με καθυστερήσεις χαρακτηριστικές για τα bucket Frequent και Rare.

Χρησιμοποιήστε το WorkManager με Expedited Work

Expedited Work (WorkManager 2.7+) εκκινεί μια Foreground Service κάτω από το καπό, δίνοντας στην εργασία άμεση εκτέλεση ανεξάρτητα από το bucket. Αυτή είναι η βέλτιστη επιλογή για εργασίες που δεν μπορούν να καθυστερήσουν: αποστολή μηνύματος, συγχρονισμός μετά από πληρωμή, επεξεργασία εισερχόμενης κλήσης. Οι συνηθισμένες εργασίες WorkManager εκτελούνται σε παράθυρα συντήρησης λαμβάνοντας υπόψη το bucket.

FCM για επανενεργοποίηση

Χρησιμοποιήστε μηνύματα FCM high-priority για να αφυπνίσετε την εφαρμογή από το App Standby. Όταν η εφαρμογή λαμβάνει ένα τέτοιο μήνυμα, το bucket της προσωρινά αυξάνεται σε Active και μπορεί να εκτελέσει απαραίτητες εργασίες (συγχρονισμό, ενημέρωση δεδομένων). Μετά την ολοκλήρωση της επεξεργασίας, το bucket επιστρέφει στο αρχικό επίπεδο.

Αποφύγετε τη συνεχή διατήρηση στη μνήμη

Μην επιχειρείτε να παρακάμψετε το App Standby με μόνιμες υπηρεσίες παρασκηνίου, WakeLock ή περιοδικά μηνύματα FCM. Η Google καταπολεμά ενεργά τέτοιες πρακτικές — η εφαρμογή μπορεί να επισημανθεί ως ενεργοβόρα και να περιοριστεί ακόμη πιο αυστηρά. Χρησιμοποιήστε WorkManager για περιοδικές εργασίες και Foreground Service μόνο όταν η εργασία είναι πραγματικά ορατή στον χρήστη.

• WorkManager — προτιμώμενο API· το Expedited Work εκτελεί εργασίες χωρίς καθυστέρηση
• FCM high-priority — προσωρινά αυξάνει το bucket σε Active για επεξεργασία μηνύματος
• Μην παρακάμπτετε το App Standby — αυτό οδηγεί σε αποκλεισμό της εφαρμογής από το σύστημα
• Foreground Service — προσωρινά μεταφέρει την εφαρμογή σε Active κατά τη λειτουργία
• Δοκιμάστε την εφαρμογή σε bucket Rare και Frequent μέσω ADB πριν από κάθε έκδοση