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۔ ہر سطح متعین کرتی ہے کہ بیک گراؤنڈ سرگرمی کتنی محدود ہے۔ سطحوں کے درمیان منتقلی ایپ کے استعمال کے نمونوں کی بنیاد پر خودکار طور پر ہوتی ہے: صارف اسے کتنی بار کھولتا ہے، نوٹیفکیشنز وصول کرتا ہے، ویجٹ کے ساتھ تعامل کرتا ہے۔

App Standby Doze Mode کے ساتھ مل کر کام کرتا ہے، لیکن اسے تبدیل نہیں کرتا۔ اگر Doze ڈیوائس کے غیر فعال ہونے پر تمام ایپس کی بیک گراؤنڈ سرگرمی کو محدود کرتا ہے، تو App Standby ڈیوائس کی حالت سے آزادانہ طور پر مخصوص ایپس کو محدود کرتا ہے۔ Rare سطح والی ایپ فون کے فعال استعمال کے دوران بھی محدود رہے گی، اگر صارف نے اسے کئی دنوں سے نہ کھولا ہو۔

Android 9+ میں Bucket

Android 9 (API 28) سے شروع کرتے ہوئے، Google نے App Standby Buckets — عددی اقدار کے ساتھ رسمی درجہ بندی — متعارف کرائی۔ سسٹم ایپ کے اگلے لانچ کی پیش گوئی کرنے کے لیے مشین لرننگ استعمال کرتا ہے۔ اگر ماڈل پیش گوئی کرتا ہے کہ ایپ اگلے چند گھنٹوں میں کھولی جائے گی، تو اسے Active bucket ملتا ہے۔ اگر پیش گوئی نایاب استعمال کی نشاندہی کرتی ہے — تو Rare مقرر کیا جاتا ہے۔

App Standby کیسے کام کرتا ہے

App Standby bucket متعین کرنے کے لیے کئی عوامل کا تجزیہ کرتا ہے: صارف کے ذریعے ایپ کو آخری بار کھولنے کا وقت، تعامل کی تعدد (فی دن/ہفتہ لانچ کی تعداد)، FCM نوٹیفکیشنز کی وصولی، ڈیسک ٹاپ پر فعال ویجٹ کی موجودگی اور 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 — وہ ایپ جس کے ساتھ صارف نے حال ہی میں تعامل کیا (لانچ کیا، نوٹیفکیشن وصول کیا یا ویجٹ استعمال کیا)۔ اس bucket میں کوئی پابندی نہیں: JobScheduler فوری طور پر چلتا ہے، نیٹ ورک دستیاب ہے، AlarmManager درست طریقے سے کام کرتا ہے۔ ایپ Active میں اس وقت تک رہتی ہے جب تک صارف کئی گھنٹوں تک اس کے ساتھ تعامل بند نہ کرے۔

Working Set اور Frequent

Working Set — ایپ باقاعدگی سے استعمال ہوتی ہے (ہفتے میں کئی بار)۔ بیک گراؤنڈ کاموں میں 2 گھنٹے تک تاخیر۔ Frequent — ایپ مہینے میں کئی بار استعمال ہوتی ہے۔ 4 گھنٹے تک تاخیر۔ دونوں سطحوں میں نیٹ ورک صرف سروس ونڈو میں دستیاب ہے، اور AlarmManager میں تاخیر ہو سکتی ہے۔ JobScheduler قریب ترین ونڈو میں کام کرتا ہے۔

Rare — کم استعمال شدہ

Rare — سب سے سخت سطح، ان ایپس کے لیے مقرر کی جاتی ہے جنہیں صارف نے 30 دنوں سے زیادہ عرصے سے نہ کھولا ہو۔ بیک گراؤنڈ کاموں میں 24 گھنٹے تک تاخیر۔ سروس ونڈو کے باہر نیٹ ورک مکمل طور پر مسدود ہوتا ہے، AlarmManager صرف setAndAllowWhileIdle() جھنڈے کے ساتھ 9 منٹ میں 1 بار کی حد کے ساتھ کام کرتا ہے۔ 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 پر منحصر نہیں ہوتا۔

نیٹ ورک کی پابندیاں

Working Set, Frequent اور Rare bucket والی ایپس کسی بھی وقت صوابدیدی نیٹ ورک درخواستیں نہیں کر سکتیں۔ سسٹم صرف سروس ونڈو میں نیٹ ورک تک رسائی کی اجازت دیتا ہے، جو Doze کے ساتھ مطابقت رکھتی ہیں۔ اہم ڈیٹا بھیجنے کے لیے FCM high-priority استعمال کریں، اس کے بعد سروس ونڈو میں مطابقت پذیری کریں۔

AlarmManager

AlarmManager App Standby میں Doze جیسے ہی اصولوں کی پیروی کرتا ہے: درست الارم (setExact()) میں تاخیر ہوتی ہے، اور setAndAllowWhileIdle() 9 منٹ میں 1 بار چالو ہونے تک محدود ہے۔ Rare bucket کے لیے تاخیر 24 گھنٹے تک پہنچ سکتی ہے، جو کم استعمال شدہ ایپس میں درست کام کی منصوبہ بندی کے لیے AlarmManager کو نا مناسب بناتی ہے۔

• JobScheduler — کام bucket کی بنیاد پر 2–24 گھنٹے تک تاخیر کا شکار
• نیٹ ورک — Working Set اور نیچے کے لیے صرف سروس ونڈو میں رسائی
• AlarmManager — درست الارم میں تاخیر، setAndAllowWhileIdle — 1/9 منٹ
• SyncManager — اکاؤنٹ کی مطابقت پذیری سروس ونڈو تک تاخیر کا شکار
• Widget updates — ویجٹ اپ ڈیٹ کی تعدد کم ہو سکتی ہے

استثنیٰ کیسے حاصل کریں

استثنیٰ App Standby سے دو طریقوں سے حاصل کیا جا سکتا ہے: صارف کی بیٹری سیٹنگز (دستی Whitelist) کے ذریعے یا سسٹم Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS کے ذریعے۔ تاہم، Google استثنیٰ تک رسائی کو سختی سے منظم کرتا ہے — جن ایپس کے پاس استثنیٰ کی معقول وجہ نہیں، انہیں Google Play میں مسترد کیے جانے کا خطرہ ہے۔

صارف ترتیبات → ایپس → [ایپ] → بیٹری → اصلاح → اصلاح نہ کریں کے ذریعے کسی مخصوص ایپ کے لیے دستی طور پر پابندیاں ہٹا سکتا ہے۔ یہ منتخب کردہ ایپ کے لیے App Standby اور Doze کی پابندیوں کو مکمل طور پر ہٹا دیتا ہے۔ ڈویلپر صارف کو ہدایات یا سسٹم ڈائیلاگ دکھا سکتا ہے، لیکن زبردستی ایپ کو استثنیٰ میں شامل نہیں کر سکتا۔

Foreground Service نوٹیفکیشن کے ساتھ خودکار طور پر App Standby سے عارضی استثنیٰ حاصل کرتا ہے۔ جب تک سروس چلتی ہے اور نوٹیفکیشن دکھاتی ہے، ایپ اس کی حقیقی سطح سے آزادانہ طور پر Active bucket میں منتقل ہو جاتی ہے۔ سروس رکنے کے بعد bucket اپنی اصل قیمت پر واپس آ جاتا ہے۔ سسٹم استثنیٰ کی درخواست کیے بغیر بیک گراؤنڈ کام کو یقینی بنانے کا یہ سب سے قابل اعتماد طریقہ ہے۔

استثنیٰ کی درخواست کب کریں

Whitelist کی درخواست صرف ان ایپس کے لیے معنی رکھتی ہے جن میں اہم بیک گراؤنڈ فعالیت ہو: ریئل ٹائم نیویگیشن، صحت کی نگرانی، VoIP کالز، ڈیوائس سیکیورٹی۔ زیادہ تر ایپس کے لیے Foreground Service یا WorkManager استعمال کرنا کافی ہے۔ Google Play اشاعت کو مسترد کر سکتا ہے اگر ایپ واضح ضرورت کے بغیر استثنیٰ کی درخواست کرے۔

// ایپ اسٹینڈبائی سے استثنیٰ کی درخواست
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 کی جانچ

جانچ ADB کے ذریعے App Standby کی آپ کو ایپ کو کسی بھی 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 کے ذریعے ایپ کی طویل غیرفعالیت کا تخیل کرنے کی بھی اجازت دیتا ہے۔

# ایپ کے لیے Rare bucket سیٹ کرنا
$ adb shell am set-standby-bucket com.example.app rare

# موجودہ bucket دیکھنا
$ adb shell am get-standby-bucket com.example.app

# تمام buckets کو Active پر ری سیٹ کرنا
$ adb shell dumpsys usagestats clear

# سسٹم کے تمام buckets دیکھنا
$ adb shell dumpsys usagestats

کیا جانچیں

Rare bucket سیٹ کرنے کے بعد جانچیں: کیا WorkManager کام 24 گھنٹوں میں انجام پاتا ہے، کیا AlarmManager چالو ہوتا ہے، کیا FCM نوٹیفکیشنز پہنچائی جاتی ہیں، کیا Foreground Service بغیر پابندیوں کے کام کرتا ہے۔ WorkManager Expedited Work پالیسی کے ساتھ Rare bucket میں بھی فوری طور پر انجام پانا چاہیے، کیونکہ یہ Foreground Service استعمال کرتا ہے۔ عام WorkManager کام bucket کے مطابق تاخیر کا شکار ہوں گے۔

بہترین طریقہ کار

App Standby کے لیے برداشت والی ایپ تیار کرنے کے لیے بیک گراؤنڈ کاموں کے لیے ایک باشعور نقطہ نظر کی ضرورت ہوتی ہے۔ بنیادی اصول: یہ نہ سمجھیں کہ ایپ ہمیشہ Active bucket میں ہے۔ بیک گراؤنڈ کام کو اس طرح ڈیزائن کریں کہ وہ Frequent اور Rare bucket کی مخصوص تاخیروں کے ساتھ صحیح طریقے سے انجام پائے۔

WorkManager کو Expedited Work کے ساتھ استعمال کریں

Expedited Work (WorkManager 2.7+) اندرونی طور پر Foreground Service چلاتا ہے، جو کام کو bucket سے آزادانہ طور پر فوری انجام دینے کی اجازت دیتا ہے۔ یہ ان کاموں کے لیے بہترین انتخاب ہے جن میں تاخیر نہیں ہو سکتی: پیغام بھیجنا، ادائیگی کے بعد مطابقت پذیری، آنے والی کال پر کارروائی۔ عام WorkManager کام bucket کو مدنظر رکھتے ہوئے سروس ونڈو میں انجام پاتے ہیں۔

دوبارہ فعال کرنے کے لیے FCM

App Standby سے ایپ کو جگانے کے لیے FCM high-priority پیغامات استعمال کریں۔ جب ایپ ایسا پیغام وصول کرتی ہے، اس کا bucket عارضی طور پر Active تک بڑھ جاتا ہے، اور یہ ضروری کام (مطابقت پذیری، ڈیٹا اپ ڈیٹ) کر سکتی ہے۔ کارروائی مکمل ہونے کے بعد bucket اپنی اصل سطح پر واپس آ جاتا ہے۔

میموری میں مستقل رہنے سے گریز کریں

مستقل بیک گراؤنڈ سروسز، WakeLock یا متواتر FCM پیغامات سے App Standby کو نظرانداز کرنے کی کوشش نہ کریں۔ Google اس طرح کے طریقوں کے خلاف فعال طور پر لڑتا ہے — ایپ کو توانائی خرچ کرنے والی قرار دیا جا سکتا ہے اور مزید سختی سے محدود کیا جا سکتا ہے۔ متواتر کاموں کے لیے WorkManager استعمال کریں اور Foreground Service صرف اس وقت جب کام واقعی صارف کو نظر آتا ہو۔

• WorkManager — ترجیحی API؛ Expedited Work بغیر تاخیر کے کام انجام دیتا ہے
• FCM high-priority — پیغام پر کارروائی کے لیے عارضی طور پر bucket کو Active تک بڑھاتا ہے
• نظرانداز نہ کریں App Standby — اس کے نتیجے میں سسٹم ایپ کو بلاک کر دیتا ہے
• Foreground Service — کام کی مدت کے لیے عارضی طور پر ایپ کو Active میں لاتا ہے
• جانچیں ہر ریلیز سے پہلے ADB کے ذریعے Rare اور Frequent bucket میں ایپ کو