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-এ কমিয়ে দিতে পারে।

Bucket-এ FCM-এর প্রভাব

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

# সব bucket Active-এ রিসেট করা
$ adb shell dumpsys usagestats clear

# সিস্টেমের সব bucket দেখা
$ 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-এ অ্যাপ