অ্যাপ স্ট্যান্ডবাই বাকেট

Android 9 (API লেভেল ২৮) এবং তার পরবর্তী ভার্সনে অ্যাপ স্ট্যান্ডবাই বাকেট কাজ করে। অ্যাপ স্ট্যান্ডবাই কত সম্প্রতি এবং কত ঘনঘন অ্যাপ ব্যবহার করা হয়েছে তার ভিত্তিতে সিস্টেমকে অ্যাপের রিসোর্স সংক্রান্ত অনুরোধকে অগ্রাধিকার দিতে বাকেট সাহায্য করে। অ্যাপ ব্যবহারের প্যাটার্নের উপর ভিত্তি করে, প্রতিটি অ্যাপকে পাঁচটি অগ্রাধিকার বাকেটের মধ্যে একটিতে রাখা হয়। অ্যাপটি কোন বাকেটে আছে তার উপর ভিত্তি করে সিস্টেম প্রতিটি অ্যাপের জন্য উপলভ্য ডিভাইস রিসোর্স সীমিত করে।

অগ্রাধিকার বাকেট

সিস্টেম ডায়নামিকভাবে প্রতিটি অ্যাপকে একটি প্রায়োরিটি বাকেটে অ্যাসাইন করে, প্রয়োজন অনুযায়ী অ্যাপগুলিকে আবার অ্যাসাইন করে। সিস্টেমটি এমন একটি প্রিলোড করা অ্যাপের উপর নির্ভর করতে পারে যা মেশিন লার্নিং ব্যবহার করে প্রতিটি অ্যাপ ব্যবহার করার সম্ভাবনা নির্ধারণ করে এবং উপযুক্ত বাকেটে অ্যাপগুলি অ্যাসাইন করে।

কোনও ডিভাইসে সিস্টেম অ্যাপ না থাকলে, সিস্টেম ডিফল্ট হিসেবে অ্যাপগুলি সম্প্রতি কতবার ব্যবহার করা হয়েছে তার ভিত্তিতে সাজায়। যেসব অ্যাপ বেশি অ্যাক্টিভ থাকে, সেগুলিকে এমন বাকেটে অ্যাসাইন করা হয় যেগুলি বেশি অগ্রাধিকার পায়, যার ফলে অ্যাপের জন্য আরও বেশি সিস্টেম রিসোর্স উপলভ্য হয়। বিশেষ করে, বাকেট নির্ধারণ করে যে কত ঘন ঘন অ্যাপের কাজ রান করে এবং কত ঘন ঘন অ্যাপ অ্যালার্ম ট্রিগার করতে পারে। এইসব বিধিনিষেধ শুধুমাত্র ডিভাইস ব্যাটারির চার্জে চলার সময় প্রযোজ্য হয়। ডিভাইস চার্জ করার সময়, সিস্টেম এইসব বিধিনিষেধ আরোপ করে না।

অগ্রাধিকারের ভিত্তিতে তৈরি করা বাকেটগুলি হল:

• অ্যাক্টিভ: অ্যাপ ব্যবহার করা হচ্ছে বা খুব সম্প্রতি ব্যবহার করা হয়েছে।
• ওয়ার্কিং সেট: অ্যাপ নিয়মিত ব্যবহার করা হয়।
• ঘনঘন: অ্যাপটি প্রায়ই ব্যবহার করা হয়, তবে প্রতিদিন নয়।
• বিরল: অ্যাপটি প্রায়শই ব্যবহার করা হয় না।
• সীমাবদ্ধ: অ্যাপটি প্রচুর সিস্টেম রিসোর্স ব্যবহার করে বা অবাঞ্ছিত আচরণ প্রদর্শন করতে পারে।

এইসব প্রায়োরিটি বাকেটের পাশাপাশি, ইনস্টল করা হয়েছে কিন্তু কখনও চালানো হয়নি এমন অ্যাপের জন্য একটি বিশেষ কখনও নয় বাকেট আছে। সিস্টেম এইসব অ্যাপের উপর কঠোর বিধিনিষেধ আরোপ করে।

নিম্নলিখিত বিবরণগুলি নন-প্রেডিক্টিভ কেসের জন্য। অন্যদিকে, যখন প্রেডিকশন, আচরণ অনুমান করার জন্য মেশিন লার্নিং ব্যবহার করে, তখন সাম্প্রতিক ব্যবহারের উপর ভিত্তি করে নয়, বরং ব্যবহারকারীর পরবর্তী অ্যাকশনের প্রত্যাশায় বাকেট বেছে নেওয়া হয়। যেমন, সম্প্রতি ব্যবহার করা কোনও অ্যাপ বিরল বালতিতে শেষ হতে পারে কারণ মেশিন লার্নিং অনুমান করে যে অ্যাপটি কয়েক ঘণ্টা ব্যবহার নাও হতে পারে।

অ্যাক্টিভ

কোনও অ্যাপ ব্যবহার করা হলে, খুব সম্প্রতি ব্যবহার করা হলে অথবা নিম্নলিখিত কোনও কাজ করলে, সেটি অ্যাক্টিভ বাকেটে থাকে:

• অ্যাক্টিভিটি লঞ্চ করে।
• দীর্ঘ সময় ধরে চলা ফোরগ্রাউন্ড পরিষেবা রান করে।
• ব্যবহারকারী কোনও বিজ্ঞপ্তিতে ট্যাপ করেছেন।

কোনও অ্যাপ অ্যাক্টিভ বাকেটে থাকলে, সিস্টেম অ্যাপের কাজ বা অ্যালার্মের উপর ন্যূনতম বিধিনিষেধ আরোপ করে:

• Android 16 (API লেভেল 36) থেকে শুরু করে, ব্যাকগ্রাউন্ড জবের ক্ষেত্রে রানটাইম কোটা অনেক বেশি থাকে, যদি সেগুলি অ্যাক্টিভ বাকেটে থাকা কোনও অ্যাপের মাধ্যমে শুরু করা হয়। এর মধ্যে JobScheduler-এর মাধ্যমে সরাসরি শিডিউল করা কাজ এবং WorkManager বা DownloadManager-এর মতো অন্যান্য লাইব্রেরির মাধ্যমে তৈরি করা কাজ অন্তর্ভুক্ত।

ব্যবহারকারীর ইন্টার‍্যাকশন অ্যাপকে অ্যাক্টিভ হিসেবে অ্যাসাইন করে

Android 9 (API লেভেল ২৮) এবং তার পরবর্তী ভার্সনে, ব্যবহারকারী নির্দিষ্ট উপায়ে আপনার অ্যাপের সাথে ইন্টার‍্যাক্ট করলে, সিস্টেম সাময়িকভাবে আপনার অ্যাপকে অ্যাক্টিভ বাকেটে রাখে। ব্যবহারকারী আপনার অ্যাপের সাথে ইন্টার‍্যাক্ট করা বন্ধ করে দিলে, সিস্টেম ব্যবহারের ইতিহাসের উপর ভিত্তি করে এটিকে একটি বাকেটে রাখে।

নিম্নলিখিত উদাহরণগুলি হল এমন ইন্টার‍্যাকশন যা এই সিস্টেমের আচরণকে ট্রিগার করে:

• ব্যবহারকারী আপনার অ্যাপের পাঠানো বিজ্ঞপ্তিতে ট্যাপ করেন।

• ব্যবহারকারী আপনার অ্যাপে মিডিয়া বোতাম ট্যাপ করে ফোরগ্রাউন্ড পরিষেবার সাথে ইন্টার‍্যাক্ট করেন।

• Android Automotive OS-এর সাথে ইন্টার‍্যাক্ট করার সময় ব্যবহারকারী আপনার অ্যাপের সাথে কানেক্ট করেন, যেখানে আপনার অ্যাপ ফোরগ্রাউন্ড সার্ভিস অথবা CONNECTION_TYPE_PROJECTION ব্যবহার করে।

ওয়ার্কিং সেট

কোনও অ্যাপ প্রায়শই রান করলেও অ্যাক্টিভ না থাকলে সেটি ওয়ার্কিং সেট বাকেটে থাকে। যেমন, ব্যবহারকারী প্রায় প্রতিদিন চালু করেন এমন সোশ্যাল মিডিয়া অ্যাপ ওয়ার্কিং সেটে থাকার সম্ভাবনা বেশি। অ্যাপগুলি পরোক্ষভাবে ব্যবহার করা হলে, সেগুলিকেও ওয়ার্কিং সেট বাকেটে প্রোমোট করা হয়।

কোনও অ্যাপ ওয়ার্কিং সেটে থাকলে, সিস্টেম তার কাজ চালানো এবং অ্যালার্ম ট্রিগার করার ক্ষমতার উপর সামান্য বিধিনিষেধ আরোপ করে। আরও জানতে, পাওয়ার ম্যানেজমেন্ট রিসোর্স সংক্রান্ত সীমাবদ্ধতা দেখুন।

প্রায়শই

কোনও অ্যাপ নিয়মিত ব্যবহার করা হলেও প্রতিদিন ব্যবহার করা না হলে, সেটি ঘন ঘন বাকেটে থাকে। যেমন, ব্যবহারকারী জিমে যে ওয়ার্কআউট-ট্র্যাকিং অ্যাপ ব্যবহার করেন সেটি ঘন ঘন ব্যবহার করা অ্যাপের বাকেটে থাকতে পারে।

কোনও অ্যাপ ঘন ঘন ব্যবহার করা অ্যাপের বাকেটে থাকলে, সিস্টেম সেটির কাজ চালানো এবং অ্যালার্ম ট্রিগার করার ক্ষমতার উপর আরও কঠোর বিধিনিষেধ আরোপ করে। আরও জানতে, পাওয়ার ম্যানেজমেন্ট রিসোর্স সংক্রান্ত সীমাবদ্ধতা দেখুন।

বিরল

কোনও অ্যাপ ঘন ঘন ব্যবহার করা না হলে সেটি বিরল বাকেটে থাকে। যেমন, কোনও হোটেলের অ্যাপ যা ব্যবহারকারী শুধুমাত্র সেই হোটেলে থাকার সময় ব্যবহার করেন, সেটি বিরল বালতিতে থাকতে পারে।

কোনও অ্যাপ বিরল বালতিতে থাকলে, সিস্টেম তার কাজ চালানো এবং অ্যালার্ম ট্রিগার করার ক্ষমতার উপর কঠোর বিধিনিষেধ আরোপ করে। এছাড়াও, সিস্টেম অ্যাপের ইন্টারনেটে কানেক্ট করার ক্ষমতা সীমিত করে। আরও জানতে, পাওয়ার ম্যানেজমেন্ট রিসোর্স সংক্রান্ত সীমাবদ্ধতা দেখুন।

বিধিনিষেধযুক্ত

Android ১২ (API লেভেল ৩১)-এ যোগ করা এই বাকেটের অগ্রাধিকার সবচেয়ে কম এবং সব বাকেটের মধ্যে সবচেয়ে বেশি বিধিনিষেধ রয়েছে। আপনার অ্যাপকে সীমাবদ্ধ বাকেটে রাখা হবে কিনা তা সিদ্ধান্ত নিতে, সিস্টেম আপনার অ্যাপের আচরণ বিবেচনা করে, যেমন ব্যবহারকারী কত ঘনঘন এটির সাথে ইন্টার‍্যাক্ট করে।

Android 13 (API লেভেল 33) এবং তার পরবর্তী যেকোনও ভার্সনে, আপনার অ্যাপ ছাড় পাওয়ার উপযুক্ত না হলে, নিম্নলিখিত পরিস্থিতিতে সিস্টেম আপনার অ্যাপকে সীমাবদ্ধ বাকেটে রাখে:

• ব্যবহারকারী নির্দিষ্ট সংখ্যক দিন ধরে আপনার অ্যাপের সাথে ইন্টার‍্যাক্ট করেননি। Android ১২ (API লেভেল ৩১) এবং ১২L (API লেভেল ৩২) ভার্সনে, দিনের সংখ্যা হল ৪৫। Android 13-এ দিনের সংখ্যা কমিয়ে ৮ করা হয়েছে।

• আপনার অ্যাপ ২৪ ঘণ্টার মধ্যে অত্যধিক সংখ্যক ব্রডকাস্ট বা বাইন্ডিং ইনভোক করে।

সিস্টেম যদি আপনার অ্যাপকে সীমাবদ্ধ বাকেটে রাখে, তাহলে নিম্নলিখিত বিধিনিষেধ প্রযোজ্য হয়:

• আপনি ১০ মিনিটের ব্যাচ সেশনে প্রতিদিন একবার জব রান করতে পারবেন। এই সেশন চলাকালীন, সিস্টেম আপনার অ্যাপের কাজকে অন্যান্য অ্যাপের কাজের সাথে গ্রুপ করে।
  • বিধিনিষেধযুক্ত কাজ নিজে থেকে রান করে না। একই সময়ে অন্তত একটি অন্য কাজ চলতে বা বাকি থাকতে হবে, যার মধ্যে অন্য যেকোনও কাজ অন্তর্ভুক্ত থাকতে পারে।
• সিস্টেম আপনার অ্যাপকে কম বিধিনিষেধযুক্ত বাকেটে রাখলে, আপনার অ্যাপ আরও কম জরুরি ভিত্তিক কাজ রান করতে পারবে।
• আপনার অ্যাপ প্রতিদিন একটি অ্যালার্ম চালু করতে পারবে। এই অ্যালার্ম এক্স্যাক্ট অ্যালার্ম অথবা ইনএক্স্যাক্ট অ্যালার্ম হতে পারে।

বিধিনিষেধযুক্ত বাকেট থেকে ছাড়

নিম্নলিখিত ধরনের অ্যাপকে বিধিনিষেধযুক্ত বাকেটে প্রবেশ করা থেকে অব্যাহতি দেওয়া হয় এবং Android ১২ এবং তার পরবর্তী ভার্সনেও ইনঅ্যাক্টিভিটি ট্রিগার বাইপাস করে:

• কম্প্যানিয়ন ডিভাইস অ্যাপ
• ডেমো মোডে ডিভাইসে চলা অ্যাপ
• ডিভাইসের মালিক অ্যাপ
• প্রোফাইলের মালিক অ্যাপ
• পারসিস্টেন্ট অ্যাপ
• VPN অ্যাপ
• ROLE_DIALER ভূমিকা আছে এমন অ্যাপ
• ব্যবহারকারী সিস্টেম সেটিংসে "সীমাহীন" কার্যকারিতা প্রদান করার জন্য স্পষ্টভাবে মনোনীত করেছেন এমন অ্যাপ
• অ্যাক্টিভ উইজেট সহ অ্যাপ
• যেসব অ্যাপকে নিম্নলিখিত অনুমতিগুলির মধ্যে অন্তত একটি দেওয়া হয়েছে:
  • USE_EXACT_ALARM
  • ACCESS_BACKGROUND_LOCATION

অগ্রাধিকারের ভিত্তিতে বাকেট মূল্যায়ন করুন

আপনার অ্যাপ কোন বাকেটে অ্যাসাইন করা হয়েছে তা চেক করতে, নিম্নলিখিত যেকোনও একটি কাজ করুন:

• getAppStandbyBucket() নম্বরে কল করুন।

• টার্মিনাল উইন্ডোতে নিম্নলিখিত কমান্ড রান করুন:

  adb shell am get-standby-bucket PACKAGE_NAME

অ্যাপ স্ট্যান্ডবাই বাকেটে অ্যাপটি রাখা হলে সিস্টেম সেটির পারফর্ম্যান্স থ্রটল করে যার ভ্যালু STANDBY_BUCKET_ACTIVE (১০)-এর বেশি।

পেশাদার পদ্ধতি

আপনার অ্যাপ যদি Doze এবং অ্যাপ স্ট্যান্ডবাইয়ের জন্য পেশাদার পদ্ধতি অনুসরণ করে, তাহলে পরবর্তী পাওয়ার ম্যানেজমেন্ট ফিচারগুলি কঠিন নয়। তবে, কিছু অ্যাপের আচরণ যা আগে ভাল কাজ করত তা সমস্যা সৃষ্টি করতে পারে।

• আপনার অ্যাপকে নির্দিষ্ট কোনও বাকেটে রাখার জন্য সিস্টেমকে ম্যানিপুলেট করার চেষ্টা করবেন না। সিস্টেমের অগ্রাধিকার দেওয়ার পদ্ধতি পরিবর্তন হতে পারে এবং প্রতিটি ডিভাইস প্রস্তুতকারক নিজস্ব অ্যালগরিদম সহ নিজস্ব বাকেটিং অ্যাপ লেখার সিদ্ধান্ত নিতে পারে। পরিবর্তে, আপনার অ্যাপটি যে বাকেটেই থাকুক না কেন, সেটি যেন সঠিকভাবে কাজ করে তা নিশ্চিত করুন।
• কোনও অ্যাপে লঞ্চার অ্যাক্টিভিটি না থাকলে, এটি কখনও অ্যাক্টিভ বাকেটে প্রোমোট করা নাও হতে পারে। এই ধরনের অ্যাক্টিভিটি যাতে থাকে তার জন্য আপনার অ্যাপ নতুন করে ডিজাইন করার কথা বিবেচনা করুন।

• ব্যবহারকারী অ্যাপ বিজ্ঞপ্তির সাথে ইন্টার‍্যাক্ট করতে না পারলে, তিনি অ্যাপের প্রোমোশনকে অ্যাক্টিভ বাকেটে ট্রিগার করতে পারবেন না। এই ক্ষেত্রে, কিছু বিজ্ঞপ্তি নতুন করে ডিজাইন করার কথা বিবেচনা করুন যা ব্যবহারকারীদের ইন্টার‍্যাক্ট করতে দেয়। কিছু নির্দেশিকার জন্য, মেটেরিয়াল ডিজাইন বিজ্ঞপ্তি ডিজাইন প্যাটার্ন দেখুন।

• RemoteNotification Firebase Cloud Messaging (FCM) মেসেজ পাওয়ার পরে অ্যাপটি কোনও বিজ্ঞপ্তি না দেখালে, ব্যবহারকারী অ্যাপের সাথে ইন্টার‍্যাক্ট করতে পারবেন না এবং তাই এটি অ্যাক্টিভ বাকেটে প্রোমোট করতে পারবেন না। আসলে, RemoteNotification-এর একমাত্র উদ্দেশ্য হল ব্যবহারকারীকে বিজ্ঞপ্তি পুশ করা, তাই এই পরিস্থিতি যেন না ঘটে। এই ধরনের মেসেজ ব্যবহারের জন্য একটি নীতি এনফোর্সমেন্ট আছে: ২০-সেকেন্ডের এক্সিকিউশন উইন্ডো যা আসল বিজ্ঞপ্তিতে ফিরে যায়। অ্যাপ ফোরগ্রাউন্ডে থাকলে বা ব্যবহারকারী ব্যাকগ্রাউন্ডে চালানোর অনুমতি দিলে কোনও এনফোর্সমেন্ট করা হয় না।

• অ্যাপ একাধিক প্যাকেজে স্প্লিট করা থাকলে, সেইসব প্যাকেজ আলাদা আলাদা বাকেটে থাকতে পারে এবং সেগুলির অ্যাক্সেস লেভেলও আলাদা হতে পারে। অ্যাপটি সঠিকভাবে কাজ করছে কিনা তা নিশ্চিত করতে বিভিন্ন বাকেটে অ্যাসাইন করা প্যাকেজ সহ এই অ্যাপগুলি পরীক্ষা করুন।