অ্যাপ হাইবারনেশন

একজন সাধারণ Android ব্যবহারকারী তার ডিভাইসে ৫০টির বেশি অ্যাপ ইনস্টল করেন (ডিভাইসের RAM-টিয়ার যত বেশি হয়, এই সংখ্যা তত বেড়ে যায়)। তবে, এই অ্যাপগুলির মধ্যে বেশ কিছু অ্যাপ ব্যবহারকারী দীর্ঘ সময় ধরে ব্যবহার করেন না।

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

OEM প্ল্যাটফর্ম পরিবর্তন করলে তা অ্যাপ হাইবারনেশন প্রয়োগ করার ক্ষেত্রে সমস্যা তৈরি করতে পারে। যেমন

  • অ্যাপ ব্যবহারের সংজ্ঞা পরিবর্তন করা বা AOSP-তে নেই এমন কোনও অ্যাপকে সক্রিয় করার উপায় চালু করলে, অ্যাপ হাইবারনেশনের নির্ভুলতা ব্যাহত হতে পারে
  • অ্যাপ হাইবারনেশনের মতো OEM-এর মালিকানাধীন বিধিনিষেধ মেকানিজম একই ধরনের উদ্দেশ্য পূরণ করতে পারে। দুটিই থাকতে পারে, তবে কিছু ওভারল্যাপ হতে পারে।

CDD-তে অ্যাপ ব্যবহারের উপর ভিত্তি করে করা পরিবর্তনের জন্য নতুন প্রয়োজনীয়তার একটি সেট উল্লেখ করা হয়েছে, এটি বর্তমান ৩.৫.১ প্রয়োজনীয়তার মতোই। অ্যাপ হাইবারনেশন এইসব প্রয়োজনীয়তা মেনে চলে।

ফ্রেমওয়ার্ক কোড এখানে থাকে:

নীতি সংক্রান্ত লজিক এখানে থাকে:

  • repo: platform/packages/modules/Permission
  • directory: PermissionController/src/com/android/permissioncontroller/hibernation

হাই-লেভেল আর্কিটেকচার

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

  • অটোমেটিক অনুমতি প্রত্যাহার করা
  • অ্যাপটি জোর করে বন্ধ করুন
  • ODEX ও VDEX ফাইল মুছে দিন
  • অ্যাপ ক্যাশে মুছে দিন

আমাদের লক্ষ্য হল, হাইবারনেশনকে একটি রিভার্সিবল অ্যাকশন হিসেবে প্রয়োগ করা যাতে অ্যাপ ডেটা অপরিবর্তিত রেখে লঞ্চার ও অন্যান্য সারফেসের মাধ্যমে অ্যাপটি ব্যবহারকারীর কাছে উপলভ্য থাকে। অ্যাপ লঞ্চ করার পরে, আমরা এটিকে ফোর্স-স্টপ স্টেট থেকে রিস্টোর করব এবং ODEX ও VDEX ফাইল তৈরি করার প্রসেস যথারীতি চালিয়ে যাব।

পরিকল্পিত ডিজাইন দুটি প্রধান অংশকে কেন্দ্র করে তৈরি করা হয়েছে:

  • কোনও প্যাকেজ কখন হাইবারনেট করা উচিত তা নির্ধারণ করা হচ্ছে
  • হাইবারনেট করা প্যাকেজ অপ্টিমাইজ করা

একটি নতুন সিস্টেম পরিষেবা, AppHibernationService এবং একটি জব পরিষেবা, AppHibernationJobService, PermissionController-এর মধ্যে থাকা সামগ্রিক সিদ্ধান্ত গ্রহণ ও যুক্তিকে নিয়ন্ত্রণ করে।

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

প্যাকেজ অপ্টিমাইজ করার মাধ্যমে আসল সেভিংস ও অপ্টিমাইজেশন করা হয়। প্যাকেজ বন্ধ করতে, ক্যাশে ডেটা মুছে ফেলতে, ART আর্টিফ্যাক্ট মুছে ফেলতে এবং আরও অনেক কিছু করতে AppHibernationService সিস্টেমের বিভিন্ন অংশের সাথে যোগাযোগ করে। Android 11 ও তার আগের যেকোনও ভার্সনে অটোমেটিক প্রত্যাহার করার সুবিধা বজায় রাখতে, AppHibernationJobService থেকে সরাসরি অনুমতি প্রত্যাহার করা হয়।

ব্যবহারকারীর অভিজ্ঞতা

কোন কোন অ্যাপকে হাইবারনেট করা যাবে সেই বিষয়ে ব্যবহারকারীকে তথ্য ও নিয়ন্ত্রণ উভয়ই প্রদান করা হয়।

অটোমেটিক তুলে নেওয়ার মতোই, কোন কোন অ্যাপ হাইবারনেট করা হয়েছে সেই সম্পর্কে ব্যবহারকারী বিজ্ঞপ্তি পান এবং বিজ্ঞপ্তি থেকে সরাসরি সেটিংসে গিয়ে অ্যাপটি খুলে হাইবারনেশন থেকে বের করে আনা অথবা প্রয়োজন হলে অব্যবহৃত অ্যাপটি মুছে ফেলার বিকল্প পান।

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

পুরনো ভার্সনের সাথে মানানসই

Android 12 থেকে হাইবারনেশন-নির্দিষ্ট ফিচার উপলভ্য। এই ফিচারটি আগের ভার্সনে কাজ করতে পারেনি কারণ প্ল্যাটফর্মের কম্পোনেন্ট (যেমন, নতুন সিস্টেম সার্ভিস) উপলভ্য নেই। আগের OS ভার্সনের জন্য যেভাবে প্রয়োগ করা হয়েছে, অটোমেটিক প্রত্যাহার সেইভাবেই কাজ করে।

Android 12 থেকে শুরু করে, ব্যাকওয়ার্ড কম্প্যাটিবিলিটি নিশ্চিত করতে, সেটিংস-এর মধ্যে অ্যাপ ও বিজ্ঞপ্তি বিকল্পের অধীনে অ্যাপের পৃষ্ঠায় একটি হাইবারনেশন টগল যোগ করা হয়েছে এবং অনুমতি সাব-মেনুর মধ্যে অরিজিনাল অটোমেটিক প্রত্যাহার টগল রাখা হয়েছে। এই টগল অ্যাপের জন্য সামগ্রিক অ্যাপ হাইবারনেশন সিস্টেম ছাড় কন্ট্রোল করে।

কাস্টমাইজেশন

কিছু ইমপ্লিমেন্টেশন মডিউলার সিস্টেম কম্পোনেন্টের অংশ, তাই পার্টনারদের ফিচারটি পরিবর্তন করতে নিরুৎসাহিত করা হয়। পার্টনাররা CDD সংক্রান্ত প্রয়োজনীয়তা মেনে চললে, পরিবর্তে একই ধরনের ফিচার বা ফাংশনালিটি প্রয়োগ করতে পারেন।

Android 11 বা তার পরবর্তী ভার্সনের জন্য টার্গেট করা সব অ্যাপের ক্ষেত্রে অ্যাপ হাইবারনেশন ডিফল্ট হিসেবে চালু থাকতে হবে। এটি অনুমতি অটোমেটিক তুলে নেওয়ার মতোই। সেটিংটি চালু থাকলেও, Android 11 ও Android 12-এর জন্য অ্যাপ হাইবারনেশন প্রয়োগ করার পদ্ধতি আলাদা হতে পারে। আরও নির্দিষ্টভাবে বলতে গেলে, অ্যাপ হাইবারনেশন শুধুমাত্র Android 11-কে টার্গেট করা অ্যাপের জন্য কাজ করে যেখানে এটি মূলত Android 12-কে টার্গেট করা অ্যাপের জন্য অটোমেটিক-প্রত্যাহার।

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

পরীক্ষা করা

অ্যাপ হাইবারনেশন সঠিকভাবে কাজ করছে কিনা তা নিশ্চিত করতে CTS এবং ইউনিট টেস্ট আছে।