টাইম জোন সংক্রান্ত নিয়ম

Android 10, APK-ভিত্তিক টাইম জোন ডেটা আপডেট মেকানিজম (Android 8.1 ও Android 9-এ উপলভ্য) বাতিল করে দেয় এবং এর পরিবর্তে APEX-ভিত্তিক মডিউল আপডেট মেকানিজম ব্যবহার করে। AOSP 8.1 থেকে 13-এ এখনও প্ল্যাটফর্ম কোড অন্তর্ভুক্ত থাকে যা OEM-এর জন্য APK-ভিত্তিক আপডেট চালু করার জন্য প্রয়োজনীয়, তাই Android 10-এ আপগ্রেড করা ডিভাইসগুলি এখনও APK-এর মাধ্যমে পার্টনার-প্রদত্ত টাইম জোন ডেটা আপডেট পেতে পারে। তবে, প্রোডাকশন ডিভাইসে APK আপডেট মেকানিজম ব্যবহার করা উচিত নয় যেখানে মডিউল আপডেটও APK-ভিত্তিক আপডেট হিসেবে পাওয়া যায়, কারণ APK-ভিত্তিক আপডেট APEX-ভিত্তিক আপডেটকে (অর্থাৎ, যে ডিভাইস APK আপডেট পেয়েছে সেটি APEX-ভিত্তিক আপডেটকে উপেক্ষা করবে) বাতিল করে দেয়।

টাইম জোন আপডেট (Android 10 ও তার পরবর্তী যেকোনও ভার্সন)

Android 10 এবং তার পরবর্তী ভার্সনে কাজ করে এমন টাইম জোন ডেটা মডিউল, Android ডিভাইসে ডেলাইট সেভিং টাইম (DST) এবং টাইম জোন আপডেট করে, ডেটা স্ট্যান্ডার্ডাইজ করে যা ধর্মীয়, রাজনৈতিক এবং ভূ-রাজনৈতিক কারণে ঘন ঘন পরিবর্তিত হতে পারে।

আপডেট করার জন্য নিম্নলিখিত প্রসেস ব্যবহার করা হয়:

1. IANA এক বা একাধিক সরকার তাদের দেশে টাইম জোন সংক্রান্ত নিয়মে পরিবর্তন করলে, তার উত্তরে টাইম জোন ডেটাবেসে একটি আপডেট প্রকাশ করে।
2. Google বা Android পার্টনার, আপডেট করা টাইম জোন সহ একটি টাইম জোন ডেটা মডিউল আপডেট (APEX ফাইল) প্রস্তুত করে।
3. শেষ ব্যবহারকারীর ডিভাইস আপডেট ডাউনলোড করে, রিবুট করে, তারপর পরিবর্তনগুলি প্রয়োগ করে। এর পরে, ডিভাইসের টাইম জোন ডেটাতে আপডেট থেকে পাওয়া নতুন টাইম জোন ডেটা থাকে।

মডিউল সম্পর্কে আরও জানতে, মডুলার সিস্টেম কম্পোনেন্ট দেখুন।

বন্ধ করা সংক্রান্ত বিজ্ঞপ্তি

Android ১০ টাইম জোন প্যাচ প্রদান করা Android আগস্ট ২০২৬-এ বন্ধ করে দিয়েছে এবং TZDB 2026c ছিল শেষ প্যাচ। OEM-এর কাছে Android 10-এর জন্য সহায়তা চালিয়ে যাওয়ার বিকল্প আছে।

টাইম জোন আপডেট (Android 8.1–9)

মনে রাখবেন: APK-ভিত্তিক টাইম জোন ডেটা আপডেট করার মেকানিজম ফিচারটি Android 14 ও তার পরবর্তী ভার্সন থেকে সম্পূর্ণ সরিয়ে দেওয়া হয়েছে এবং সোর্স কোডে এটি আর খুঁজে পাওয়া যাবে না। পার্টনারদের সম্পূর্ণভাবে টাইম জোন মেইনলাইন মডিউলে মাইগ্রেট করতে হবে।

Android 8.1 এবং Android 9-এ, OEM-রা সিস্টেম আপডেট করার প্রয়োজন ছাড়াই ডিভাইসে আপডেট করা টাইম জোন সংক্রান্ত নিয়ম ডেটা পুশ করতে APK-ভিত্তিক মেকানিজম ব্যবহার করতে পারে। এই মেকানিজম ব্যবহারকারীদের সময়মতো আপডেট পেতে সাহায্য করে (এর ফলে Android ডিভাইসের উপযোগী লাইফটাইম বেড়ে যায়) এবং Android পার্টনারদের সিস্টেম ইমেজ আপডেট থেকে আলাদাভাবে টাইম জোন আপডেট পরীক্ষা করতে সাহায্য করে।

স্টক Android ডিভাইসে টাইম জোন সংক্রান্ত নিয়ম আপডেট করার জন্য Android কোর লাইব্রেরি টিম প্রয়োজনীয় ডেটা ফাইল প্রদান করে। OEM-রা তাদের ডিভাইসের জন্য টাইম জোন আপডেট তৈরি করার সময় এই ডেটা ফাইল ব্যবহার করার বিকল্প বেছে নিতে পারে অথবা চাইলে নিজেদের ডেটা ফাইল তৈরি করতে পারে। সব ক্ষেত্রেই, OEM-এর কাছে কোয়ালিটি অ্যাসিওরেন্স/টেস্টিং, সময় এবং তাদের সাপোর্ট করা ডিভাইসের জন্য টাইম জোন সংক্রান্ত নিয়মের আপডেট লঞ্চ করার কন্ট্রোল থাকে।

Android টাইম জোন সোর্স কোড ও ডেটা

এমনকি এই ফিচার ব্যবহার করে না এমন সব স্টক Android ডিভাইসেরও টাইম জোন নিয়ম সংক্রান্ত ডেটা প্রয়োজন এবং এগুলিকে /system পার্টিশনে টাইম জোন নিয়ম সংক্রান্ত ডেটার ডিফল্ট সেট সহ শিপ করতে হবে। এই ডেটা Android সোর্স ট্রি-তে নিম্নলিখিত লাইব্রেরির কোড ব্যবহার করে:

• libcore/ থেকে ম্যানেজ করা কোড (যেমন, java.util.TimeZone) tzdata এবং tzlookup.xml ফাইল ব্যবহার করে।
• bionic/-এ নেটিভ লাইব্রেরি কোড (যেমন, mktime, localtime সিস্টেম কলের জন্য) tzdata ফাইল ব্যবহার করে।
• external/icu/-এ ICU4J/ICU4C লাইব্রেরি কোড icu .dat ফাইল ব্যবহার করে।

এইসব লাইব্রেরি ওভারলে ফাইলের ট্র্যাক রাখে যা /data/misc/zoneinfo/current ডিরেক্টরিতে থাকতে পারে। ওভারলে ফাইলে উন্নত টাইম জোন সংক্রান্ত নিয়মের ডেটা থাকার কথা, এর ফলে ডিভাইসকে /system পরিবর্তন না করেই আপডেট করা যায়।

Android সিস্টেমের যেসব কম্পোনেন্টকে টাইম জোন সংক্রান্ত নিয়মের ডেটা চেক করতে হয়, সেগুলি প্রথমে নিম্নলিখিত লোকেশন চেক করে:

• libcore/ ও bionic/ কোড tzdata ও tzlookup.xml ফাইলের /data কপি ব্যবহার করে।
• ICU4J/ICU4C কোড /data-এর ফাইল ব্যবহার করে এবং যেসব ডেটা উপস্থিত নেই (যেমন, ফর্ম্যাট, লোকাল স্ট্রিং ইত্যাদি) সেগুলির জন্য /system ফাইলে ফিরে যায়।

ডিস্ট্রো ফাইল

Distro .zip ফাইলে /data/misc/zoneinfo/current ডিরেক্টরি পূরণ করার জন্য প্রয়োজনীয় ডেটা ফাইল থাকে। এছাড়াও, ডিস্ট্রো ফাইলে মেটাডেটা থাকে যা ডিভাইসকে ভার্সনিং সংক্রান্ত সমস্যা শনাক্ত করতে সাহায্য করে।

ডিস্ট্রো ফাইলের ফর্ম্যাট Android-রিলিজের উপর নির্ভর করে কারণ কন্টেন্ট ICU ভার্সন, Android প্ল্যাটফর্মের প্রয়োজনীয়তা এবং অন্যান্য রিলিজ পরিবর্তনের সাথে পরিবর্তিত হয়। Android প্রতিটি IANA আপডেটের জন্য (প্ল্যাটফর্ম সিস্টেম ফাইল আপডেট করার পাশাপাশি) কাজ করে এমন Android রিলিজের জন্য ডিস্ট্রো ফাইল প্রদান করে। OEM-রা তাদের ডিভাইস আপ-টু-ডেট রাখতে, এইসব ডিস্ট্রো ফাইল ব্যবহার করতে পারে অথবা Android সোর্স ট্রি ব্যবহার করে নিজস্ব ডিস্ট্রো ফাইল তৈরি করতে পারে (যেখানে ডিস্ট্রো ফাইল জেনারেট করার জন্য প্রয়োজনীয় স্ক্রিপ্ট ও অন্যান্য ফাইল থাকে)।

টাইম জোন আপডেট করার কম্পোনেন্ট

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

• প্ল্যাটফর্ম পরিষেবা কার্যকারিতা (timezone.RulesManagerService), যা ডিফল্ট হিসেবে বন্ধ করা থাকে। OEM-কে কনফিগারেশনের মাধ্যমে এই কার্যকারিতা চালু করতে হবে। RulesManagerService সিস্টেম সার্ভার প্রসেস ও স্টেজে রান করে /data/misc/zoneinfo/staged-এ লিখে টাইম জোন আপডেট অপারেশন স্টেজিং করে। RulesManagerService আগেই স্টেজ করা অপারেশন পরিবর্তন বা মুছে দিতে পারে।
• TimeZoneUpdater, আপডেট করা যায় না এমন সিস্টেম অ্যাপ (অর্থাৎ আপডেটার অ্যাপ)। যেসব ডিভাইস এই ফিচার ব্যবহার করে, সেগুলির সিস্টেম ইমেজে OEM-কে এই অ্যাপ অন্তর্ভুক্ত করতে হবে ।
• OEM TimeZoneData, একটি আপডেট করা যায় এমন সিস্টেম অ্যাপ (অর্থাৎ ডেটা অ্যাপ) যা ডিভাইসে ডিস্ট্রো ফাইল নিয়ে যায় এবং সেগুলিকে আপডেটার অ্যাপের জন্য উপলভ্য করে তোলে। এই ফিচার ব্যবহার করা ডিভাইসের সিস্টেম ইমেজে OEM-কে অবশ্যই এই অ্যাপ অন্তর্ভুক্ত করতে হবে।
• tzdatacheck, টাইম জোন আপডেট সঠিকভাবে ও নিরাপদে কাজ করার জন্য বুট-টাইম বাইনারি প্রয়োজন।

Android সোর্স ট্রি-তে উপরে উল্লিখিত কম্পোনেন্টগুলির জন্য জেনেরিক সোর্স কোড থাকে, যা OEM পরিবর্তন না করেই ব্যবহার করতে পারে। টেস্ট কোড OEM-কে অটোমেটিক চেক করার সুবিধা দিতে প্রদান করা হয় যে তারা ফিচারটি সঠিকভাবে চালু করেছে কিনা।

ডিস্ট্রো ইনস্টলেশন

ডিস্ট্রো ইনস্টলেশন প্রসেসে নিম্নলিখিত ধাপগুলি অন্তর্ভুক্ত থাকে:

1. অ্যাপ স্টোর থেকে ডাউনলোড বা সাইডলোডের মাধ্যমে ডেটা অ্যাপ আপডেট করা হয়। সিস্টেম সার্ভার প্রসেস (ক্লাসের timezone.RulesManagerServer/timezone.PackageTracker মাধ্যমে) কনফিগার করা, OEM-নির্দিষ্ট, ডেটা অ্যাপ প্যাকেজের নামে হওয়া পরিবর্তন লক্ষ্য করে।
   
   

   ছবি ১. ডেটা অ্যাপ আপডেট।

2. সিস্টেম সার্ভার প্রসেস আপডেট চেক করার প্রসেস ট্রিগার করে। এটি করার জন্য, এটি আপডেট অ্যাপে একটি অনন্য, সিঙ্গল-ইউজ টোকেন সহ একটি টার্গেট করা ইনটেন্ট ব্রডকাস্ট করে। সিস্টেম সার্ভার তার তৈরি করা সবচেয়ে সাম্প্রতিক টোকেন ট্র্যাক করে যাতে এটি নির্ধারণ করতে পারে যে এটি ট্রিগার করা সবচেয়ে সাম্প্রতিক চেক কখন সম্পূর্ণ হয়েছে; অন্য কোনও টোকেন উপেক্ষা করা হয়।
   
   

   ছবি ২. আপডেট চেক করার প্রসেস ট্রিগার করুন।

3. আপডেট চেক করার সময়, Updater অ্যাপ নিম্নলিখিত কাজগুলি করে:
   • RulesManagerService-এ কল করে বর্তমান ডিভাইসের অবস্থা সম্পর্কে কোয়েরি করে।
     
     

     ছবি ৩. ডেটা অ্যাপ আপডেট, calling RulesManagerService.

   • ডিস্ট্রিবিউশন সম্পর্কে তথ্য পেতে, ভালভাবে সংজ্ঞায়িত ContentProvider URL এবং কলাম স্পেক্স কোয়েরি করে Data অ্যাপকে কোয়েরি করে।
     
     

     ছবি ৪. ডেটা অ্যাপ আপডেট, ডিস্ট্রো সম্পর্কে তথ্য পান।

4. Updater অ্যাপ, সেটির কাছে থাকা তথ্যের ভিত্তিতে উপযুক্ত অ্যাকশন নেয়। উপলভ্য অ্যাকশনের মধ্যে এগুলি অন্তর্ভুক্ত:
   • ইনস্টল করার অনুরোধ করুন। Data অ্যাপ থেকে Distro ডেটা পড়া হয় এবং সিস্টেম সার্ভারে RulesManagerService-এ পাঠানো হয়। RulesManagerService আবার কনফার্ম করে যে ডিস্ট্রো ফরম্যাট ভার্সন ও কন্টেন্ট ডিভাইসের জন্য উপযুক্ত এবং ইনস্টল করার জন্য স্টেজ করে।
   • আনইনস্টল করার অনুরোধ করুন (এটি খুব কমই ঘটে)। যেমন, /data-এ আপডেট করা APK বন্ধ বা আনইনস্টল করা হলে এবং ডিভাইসটি /system-এ উপস্থিত ভার্সনে ফিরে গেলে।
   • কিছু করতে হবে না। Data অ্যাপের ডিস্ট্রো ভুল হলে এটি ঘটে।
   সব ক্ষেত্রে, Updater অ্যাপ চেক টোকেন সহ RulesManagerService-কে কল করে যাতে সিস্টেম সার্ভার জানতে পারে যে চেক করার প্রসেস সম্পূর্ণ ও সফল হয়েছে।
   
   

   ছবি ৫. চেক করা হয়ে গেছে।

5. রিবুট ও tzdatacheck. ডিভাইসটি পরেরবার বুট করলে, tzdatacheck বাইনারি কোনও স্টেজিং অপারেশন এক্সিকিউট করে। tzdatacheck বাইনারি নিম্নলিখিত টাস্কগুলি করতে পারে:
   • অন্যান্য সিস্টেম কম্পোনেন্ট খোলার এবং ফাইল ব্যবহার করা শুরু করার আগে, /data/misc/zoneinfo/current ফাইল তৈরি, রিপ্লেস করা এবং/অথবা মুছে দেওয়ার মাধ্যমে স্টেজিং অপারেশন এক্সিকিউট করুন।
   • /data-এ থাকা ফাইলগুলি বর্তমান প্ল্যাটফর্ম ভার্সনের জন্য সঠিক কিনা তা চেক করুন, ডিভাইসটি যদি এইমাত্র একটি সিস্টেম আপডেট পেয়ে থাকে এবং ডিস্ট্রো ফর্ম্যাট ভার্সন পরিবর্তিত হয়ে থাকে, তাহলে এটি নাও হতে পারে।
   • IANA নিয়মের ভার্সনটি /system-এর ভার্সনের সমান বা তার থেকে নতুন কিনা তা নিশ্চিত করুন। এটি সিস্টেম আপডেটকে এমন একটি ডিভাইস ছেড়ে যেতে বাধা দেয় যেটিতে /system ইমেজে উপস্থিত ডেটার চেয়ে পুরনো টাইম জোন নিয়মের ডেটা রয়েছে।

নির্ভরযোগ্যতা

সম্পূর্ণ ইনস্টলেশন প্রসেসটি অ্যাসিঙ্ক্রোনাস এবং তিনটি OS প্রসেস জুড়ে বিভক্ত। ইনস্টলেশন চলাকালীন যেকোনও সময়, ডিভাইসের পাওয়ার চলে যেতে পারে, ডিস্ক স্পেস শেষ হয়ে যেতে পারে অথবা অন্য কোনও সমস্যা হতে পারে, যার ফলে ইনস্টলেশন চেক সম্পূর্ণ হতে পারে না। সবচেয়ে ভালভাবে ব্যর্থ হলে, Updater অ্যাপ সিস্টেম সার্ভারকে জানায় যে এটি ব্যর্থ হয়েছে; সবচেয়ে খারাপভাবে ব্যর্থ হলে, RulesManagerService কোনও কলই পায় না।

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

নিরাপত্তা

চালু করা হলে, সিস্টেম সার্ভারে RulesManagerService কোড বেশ কিছু চেক করে দেখে যাতে সিস্টেমটি নিরাপদে ব্যবহার করা যায়।

• খারাপভাবে কনফিগার করা সিস্টেম ইমেজ নির্দেশ করে এমন সমস্যাগুলি কোনও ডিভাইসকে বুট করা থেকে বাধা দেয়; উদাহরণগুলির মধ্যে একটি খারাপ আপডেটার বা ডেটা অ্যাপ কনফিগারেশন বা আপডেটার বা ডেটা অ্যাপ /system/priv-app-এ না থাকা অন্তর্ভুক্ত।
• খারাপ Data অ্যাপ ইনস্টল করা হয়েছে এমন সমস্যা ডিভাইস বুট করা আটকাতে না পারলেও আপডেট চেক করার প্রসেস ট্রিগার করা আটকাতে পারে; উদাহরণ এর মধ্যে প্রয়োজনীয় সিস্টেম অনুমতির অভাব বা Data অ্যাপ প্রত্যাশিত URI-তে ContentProvider এক্সপোজ না করা অন্তর্ভুক্ত।

/data/misc/zoneinfo ডিরেক্টরির জন্য ফাইল সংক্রান্ত অনুমতি SELinux নিয়ম ব্যবহার করে এনফোর্স করা হয়। যেকোনও APK-র মতো, Data অ্যাপকেও /system/priv-app ভার্সন সাইন করার জন্য ব্যবহৃত একই কী দিয়ে সাইন করতে হবে। Data অ্যাপে OEM-নির্দিষ্ট প্যাকেজের নাম ও কী থাকার কথা।

টাইম জোন সংক্রান্ত আপডেট ইন্টিগ্রেট করুন

টাইম জোন আপডেট ফিচার চালু করতে, OEM সাধারণত:

• তাদের নিজস্ব ডেটা অ্যাপ তৈরি করা।
• সিস্টেম ইমেজ বিল্ডে Updater ও Data অ্যাপ অন্তর্ভুক্ত করুন।
• RulesManagerService চালু করতে সিস্টেম সার্ভার কনফিগার করুন।

প্রস্তুতি

শুরু করার আগে, OEM-এর নিম্নলিখিত নীতি, কোয়ালিটি অ্যাস্যুরেন্স এবং নিরাপত্তা সংক্রান্ত বিষয়গুলি পর্যালোচনা করা উচিত:

• তাদের ডেটা অ্যাপের জন্য অ্যাপ-নির্দিষ্ট সই করার কী তৈরি করুন।
• কোন কোন ডিভাইস আপডেট করা হবে এবং কীভাবে নিশ্চিত করা যাবে যে আপডেট শুধুমাত্র সেইসব ডিভাইসে ইনস্টল করা হবে যেগুলিতে সেগুলি প্রয়োজন, তা বুঝতে টাইম জোন আপডেটের জন্য একটি রিলিজ ও ভার্সনিং কৌশল তৈরি করুন। যেমন, OEM-রা তাদের সব ডিভাইসের জন্য একটি ডেটা অ্যাপ রাখতে চাইতে পারে অথবা বিভিন্ন ডিভাইসের জন্য আলাদা আলাদা ডেটা অ্যাপ রাখার বিকল্প বেছে নিতে পারে। এই সিদ্ধান্তের ফলে প্যাকেজের নাম, সম্ভবত ব্যবহৃত ভার্সন কোড এবং QA স্ট্র্যাটেজি প্রভাবিত হয়।
• তারা AOSP থেকে স্টক Android টাইমজোন ডেটা ব্যবহার করতে চান নাকি নিজেদের ডেটা তৈরি করতে চান তা বুঝুন।

ডেটা অ্যাপ তৈরি করুন

AOSP-তে, packages/apps/TimeZoneData-এ ডেটা অ্যাপ তৈরি করার জন্য প্রয়োজনীয় সব সোর্স কোড ও বিল্ড রুল AndroidManifest.xml-এর জন্য নির্দেশাবলী ও টেমপ্লেটের উদাহরণ এবং packages/apps/TimeZoneData/oem_template-এ থাকা অন্যান্য ফাইল অন্তর্ভুক্ত থাকে। উদাহরণ টেমপ্লেটের মধ্যে রিয়েল ডেটা অ্যাপ APK-এর জন্য বিল্ড টার্গেট এবং ডেটা অ্যাপের টেস্ট ভার্সন তৈরি করার জন্য অতিরিক্ত টার্গেট অন্তর্ভুক্ত।

OEM নিজস্ব আইকন, নাম, অনুবাদ ও অন্যান্য বিবরণ দিয়ে Data অ্যাপ কাস্টমাইজ করতে পারে। তবে, Data অ্যাপ লঞ্চ করা না গেলে, আইকনটি শুধুমাত্র সেটিংস > অ্যাপ স্ক্রিনে দেখা যাবে।

সিস্টেম ইমেজে (প্রাথমিক রিলিজের জন্য) যোগ করার উপযুক্ত APK তৈরি করে এবং অ্যাপ স্টোরের (পরবর্তী আপডেটের জন্য) মাধ্যমে সাইন ও ডিস্ট্রিবিউট করা হয় এমন tapas বিল্ড দিয়ে Data অ্যাপ তৈরি করার পরিকল্পনা করা হয়েছে। tapas ব্যবহার করা সম্পর্কে আরও জানতে, tapas ব্যবহার করে ডেটা অ্যাপ তৈরি করা দেখুন।

OEM-কে অবশ্যই /system/priv-app-এ ডিভাইসের সিস্টেম ইমেজে আগে থেকে তৈরি করা ডেটা অ্যাপ ইনস্টল করতে হবে। সিস্টেম ইমেজে আগে থেকে তৈরি APK (tapas build প্রসেস দ্বারা তৈরি) যোগ করতে, OEM packages/apps/TimeZoneData/oem_template/data_app_prebuilt-এ উদাহরণ ফাইল কপি করতে পারে। এছাড়াও, উদাহরণ টেমপ্লেটে টেস্ট স্যুটে Data অ্যাপের টেস্ট ভার্সন অন্তর্ভুক্ত করার জন্য বিল্ড টার্গেট অন্তর্ভুক্ত থাকে।

সিস্টেম ইমেজে Updater ও Data অ্যাপ অন্তর্ভুক্ত করুন

OEM-কে অবশ্যই সিস্টেম ইমেজের /system/priv-app ডিরেক্টরিতে Updater এবং ডেটা অ্যাপ APK রাখতে হবে। এটি করতে, সিস্টেম ইমেজ বিল্ডে অবশ্যই Updater অ্যাপ এবং ডেটা অ্যাপের প্রি-বিল্ড টার্গেট অন্তর্ভুক্ত থাকতে হবে।

আপডেটার অ্যাপটি প্ল্যাটফর্ম কী দিয়ে সাইন করা এবং অন্য যেকোনও সিস্টেম অ্যাপের মতো অন্তর্ভুক্ত করা উচিত। টার্গেট packages/apps/TimeZoneUpdater-এ TimeZoneUpdater হিসেবে সংজ্ঞায়িত করা হয়েছে। The Data app inclusion is OEM-specific and depends on the target name chosen for the prebuild.

সিস্টেম সার্ভার কনফিগার করা

টাইম জোন আপডেট চালু করতে, OEM frameworks/base/core/res/res/values/config.xml-এ সংজ্ঞায়িত কনফিগারেশন প্রপার্টি ওভাররাইড করে সিস্টেম সার্ভার কনফিগার করতে পারে।

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

কনফিগারেশন ওভাররাইড সিস্টেম ইমেজে (ভেন্ডর বা অন্য কোনও জায়গায় নয়) থাকতে হবে, কারণ ভুল কনফিগার করা ডিভাইস বুট করতে অস্বীকার করতে পারে। কনফিগারেশন ওভাররাইড ভেন্ডর ইমেজে থাকলে, ডেটা অ্যাপ (বা আলাদা ডেটা অ্যাপ/আপডেটার অ্যাপ প্যাকেজের নাম) ছাড়া সিস্টেম ইমেজে আপডেট করাকে মিসকনফিগারেশন হিসেবে বিবেচনা করা হবে।

xTS টেস্টিং

xTS বলতে যেকোনও OEM-নির্দিষ্ট টেস্ট স্যুটকে বোঝায় যা Tradefed (যেমন CTS এবং VTS) ব্যবহার করে স্ট্যান্ডার্ড Android টেস্ট স্যুটের মতো। যেসব OEM-এর কাছে এই ধরনের টেস্ট সুইট আছে, তারা নিম্নলিখিত লোকেশনে দেওয়া Android টাইম জোন আপডেট টেস্ট যোগ করতে পারে:

• packages/apps/TimeZoneData/testing/xts-এ প্রাথমিক অটোমেটেড ফাংশনাল টেস্টিংয়ের জন্য প্রয়োজনীয় কোড অন্তর্ভুক্ত থাকে।
• packages/apps/TimeZoneData/oem_template/xts-এ Tradefed-এর মতো xTS স্যুটে টেস্ট অন্তর্ভুক্ত করার জন্য একটি স্যাম্পেল ডিরেক্টরি স্ট্রাকচার রয়েছে। অন্যান্য টেমপ্লেট ডিরেক্টরির মতো, OEM-এর থেকে আশা করা হয় যে তারা কপি করে নিজেদের প্রয়োজন অনুযায়ী কাস্টমাইজ করবে।
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt পরীক্ষার জন্য প্রয়োজনীয় আগে থেকে তৈরি টেস্ট APK অন্তর্ভুক্ত করার জন্য বিল্ড-টাইম কনফিগারেশন থাকে পরীক্ষার মাধ্যমে।

টাইম জোন সংক্রান্ত আপডেট তৈরি করুন

IANA যখন টাইম জোন সংক্রান্ত নিয়মের নতুন সেট প্রকাশ করে, তখন Android কোর লাইব্রেরি টিম AOSP-তে রিলিজ আপডেট করার জন্য প্যাচ তৈরি করে। স্টক Android সিস্টেম ও ডিস্ট্রো ফাইল ব্যবহার করা OEM-রা এই কমিটগুলি বেছে নিতে পারে, তাদের ডেটা অ্যাপের একটি নতুন ভার্সন তৈরি করতে সেগুলি ব্যবহার করতে পারে, তারপর প্রোডাকশনে তাদের ডিভাইস আপডেট করার জন্য নতুন ভার্সন রিলিজ করতে পারে।

ডেটা অ্যাপে Android ভার্সনের সাথে ঘনিষ্ঠভাবে যুক্ত ডিস্ট্রো ফাইল থাকে বলে, OEM-কে আপডেট করতে চায় এমন প্রতিটি কাজ করে Android রিলিজের জন্য OEM-কে ডেটা অ্যাপের নতুন ভার্সন তৈরি করতে হবে। যেমন, কোনও OEM যদি Android 8.1, 9 ও 10 ডিভাইসের জন্য আপডেট দিতে চায়, তাহলে তাকে তিনবার প্রসেসটি সম্পূর্ণ করতে হবে।

ধাপ ১: সিস্টেম/টাইমজোন এবং এক্সটার্নাল/icu ডেটা ফাইল আপডেট করা

এই ধাপে, OEM-রা AOSP-তে রিলিজ-ডেভ ব্রাঞ্চ থেকে system/timezone ও external/icu-এর জন্য স্টক Android কমিট নেয় এবং Android সোর্স কোডের কপির উপর সেইসব কমিট প্রয়োগ করে।

সিস্টেম/টাইমজোন AOSP প্যাচে system/timezone/input_data এবং system/timezone/output_data-এ আপডেট করা ফাইল আছে। যেসব OEM-কে অতিরিক্ত লোকাল ফিক্স করতে হবে, তারা ইনপুট ফাইল পরিবর্তন করে system/timezone/input_data ও external/icu-এ ফাইল ব্যবহার করে output_data-এ ফাইল জেনারেট করতে পারবে।

সবচেয়ে গুরুত্বপূর্ণ ফাইল হল system/timezone/output_data/distro/distro.zip, যা Data অ্যাপ APK তৈরি করার সময় অটোমেটিক অন্তর্ভুক্ত করা হয়।

ধাপ ২: Data অ্যাপের ভার্সন কোড আপডেট করুন

এই ধাপে, OEM ডেটা অ্যাপের ভার্সন কোড আপডেট করে। বিল্ড অটোমেটিক distro.zip বেছে নেয়, তবে ডেটা অ্যাপের নতুন ভার্সনে অবশ্যই একটি নতুন ভার্সন কোড থাকতে হবে যাতে এটি নতুন হিসেবে শনাক্ত করা হয় এবং প্রি-লোড করা ডেটা অ্যাপ বা আগের আপডেটের মাধ্যমে ডিভাইসে ইনস্টল করা ডেটা অ্যাপ প্রতিস্থাপন করতে ব্যবহৃত হয়।

package/apps/TimeZoneData/oem_template/data_app থেকে কপি করা ফাইল ব্যবহার করে Data অ্যাপ তৈরি করার সময়, আপনি Android.mk-এ APK-তে প্রয়োগ করা ভার্সন কোড/ভার্সন নাম দেখতে পাবেন:

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

testing/Android.mk-এ একই ধরনের এন্ট্রি পাওয়া যেতে পারে (তবে, টেস্ট ভার্সন কোড সিস্টেম ইমেজ ভার্সনের থেকে বেশি হতে হবে)। বিস্তারিত জানতে, উদাহরণ ভার্সন কোড স্ট্র্যাটেজি স্কিম দেখুন; যদি উদাহরণ স্কিম বা একই ধরনের স্কিম ব্যবহার করা হয়, তাহলে টেস্ট ভার্সন কোড আপডেট করার প্রয়োজন নেই কারণ সেগুলি আসল ভার্সন কোডের চেয়ে বেশি হবে বলে গ্যারান্টি দেওয়া হয়।

ধাপ ৩: আবার তৈরি, সাইন, পরীক্ষা ও রিলিজ করা

এই ধাপে, OEM-রা tapas ব্যবহার করে APK আবার তৈরি করে, জেনারেট করা APK সাইন করে, তারপরে APK পরীক্ষা করে রিলিজ করে:

• প্রকাশ করা হয়নি এমন ডিভাইসের জন্য (বা প্রকাশ করা হয়েছে এমন ডিভাইসের জন্য সিস্টেম আপডেট প্রস্তুত করার সময়), সিস্টেম ইমেজ ও xTS টেস্টে লেটেস্ট APK আছে কিনা তা নিশ্চিত করতে, Data অ্যাপের প্রি-বিল্ট ডিরেক্টরিতে নতুন APK জমা দিন। OEM-এর উচিত নতুন ফাইলটি সঠিকভাবে কাজ করছে কিনা তা পরীক্ষা করা (অর্থাৎ, এটি CTS এবং যেকোনও OEM-নির্দিষ্ট অটোমেটিক এবং ম্যানুয়াল টেস্টে পাস করে)।
• যেসব রিলিজ করা ডিভাইস আর সিস্টেম আপডেট পায় না, সেগুলির ক্ষেত্রে সাইন করা APK শুধুমাত্র অ্যাপ স্টোরের মাধ্যমে রিলিজ করা হতে পারে।

OEM-এর দায়িত্ব হল, রিলিজ করার আগে তাদের ডিভাইসে আপডেট করা Data অ্যাপের কোয়ালিটি অ্যাস্যুরেন্স ও টেস্টিং করা।

ডেটা অ্যাপ ভার্সন কোড স্ট্র্যাটেজি

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

APK ভার্সন কোডে নিম্নলিখিত তথ্য থাকতে হবে:

• ডিস্ট্রো ফর্ম্যাট ভার্সন (মেজর + মাইনর)
• ক্রমবর্ধমান (অস্বচ্ছ) ভার্সন নম্বর

বর্তমানে, প্ল্যাটফর্ম API লেভেল, ডিস্ট্রো ফর্ম্যাট ভার্সনের সাথে দৃঢ়ভাবে সম্পর্কিত কারণ প্রতিটি API লেভেল সাধারণত ICU-এর নতুন ভার্সনের সাথে যুক্ত থাকে (যা ডিস্ট্রো ফাইলকে ইনকম্প্যাটিবল করে তোলে)। ভবিষ্যতে, Android এটি পরিবর্তন করতে পারে যাতে একটি ডিস্ট্রো ফাইল একাধিক Android প্ল্যাটফর্ম রিলিজ জুড়ে কাজ করতে পারে (এবং API লেভেল ডেটা অ্যাপের ভার্সন কোড স্কিমে ব্যবহার করা হয় না)।

ভার্সন কোড স্ট্র্যাটেজির উদাহরণ

এই উদাহরণে দেখানো ভার্সন নম্বর স্কিম নিশ্চিত করে যে উচ্চতর ডিস্ট্রো ফর্ম্যাট ভার্সন নিম্নতর ডিস্ট্রো ফর্ম্যাট ভার্সনের স্থান অধিকার করে। AndroidManifest.xml android:minSdkVersion ব্যবহার করে নিশ্চিত করে যে পুরনো ডিভাইসগুলি যেন এমন কোনও ভার্সন না পায় যেটির ডিস্ট্রো ফর্ম্যাট সেগুলি হ্যান্ডেল করতে পারে তার থেকে বেশি।

ছবি ৬. ভার্সন কোড স্ট্র্যাটেজির উদাহরণ।

ডেসিমেলের পরিবর্তে বাইনারি ব্যবহার করা হলে স্কিমটি আরও ভালোভাবে প্যাক করা যেত, কিন্তু এই স্কিমটি মানুষের পক্ষে সহজে পাঠযোগ্য হওয়ার সুবিধা আছে। সম্পূর্ণ নম্বর রেঞ্জ শেষ হয়ে গেলে, Data অ্যাপ প্যাকেজের নাম পরিবর্তন হতে পারে।

ভার্সনের নাম হল বিবরণের মানুষের-পঠনযোগ্য উপস্থাপনা, যেমন: major=001,minor=001,iana=2017a, revision=1,respin=2। নিচের সারণিতে উদাহরণ দেখানো হয়েছে।

• উদাহরণ ১ ও ২-এ একই 2017a IANA রিলিজের দুটি APK ভার্সন দেখানো হয়েছে, তবে মেজর ফর্ম্যাট ভার্সন আলাদা। ২, ১-এর চেয়ে সংখ্যাগতভাবে বেশি, যা নিশ্চিত করে যে নতুন ডিভাইসগুলি উচ্চতর ফর্ম্যাট ভার্সন পাবে। minSdkVersion নিশ্চিত করে যে P ভার্সন O ডিভাইসে সাপ্লাই করা হবে না।
• উদাহরণ ৩ হল ১-এর সংশোধন/ফিক্স এবং সংখ্যাগতভাবে ১-এর থেকে বেশি।
• উদাহরণ ৪ ও ৫-এ O-MR1 ও P-এর জন্য 2017b রিলিজ দেখানো হয়েছে। সংখ্যাগতভাবে উচ্চতর হওয়ায়, এগুলি পূর্ববর্তী IANA রিলিজ/Android রিভিশনের নিজ নিজ পূর্বসূরীদের প্রতিস্থাপন করে।
• উদাহরণ ৬ ও ৭-এ O-MR1 ও P-এর জন্য 2018a রিলিজ দেখানো হয়েছে।
• উদাহরণ ৮-এ Y=0 স্কিম সম্পূর্ণভাবে প্রতিস্থাপন করার জন্য Y-এর ব্যবহার দেখানো হয়েছে।
• ৯ নম্বর উদাহরণে ৩ ও ৪-এর মধ্যে থাকা ফাঁকা জায়গাটি apk-কে আবার স্পিন করার জন্য ব্যবহার করা হয়েছে।

যেহেতু প্রতিটি ডিভাইস সিস্টেম ইমেজে ডিফল্ট, উপযুক্ত ভার্সনের APK সহ শিপ করা হয়, তাই P ডিভাইসে O-MR1 ভার্সন ইনস্টল হওয়ার কোনও ঝুঁকি নেই কারণ এটির ভার্সন নম্বর P সিস্টেম ইমেজ ভার্সনের চেয়ে কম। /data-এ ইনস্টল করা O-MR1 ভার্সন সহ একটি ডিভাইস যা পরে P-তে সিস্টেম আপডেট পায়, সেটি /data-এ O-MR1 ভার্সনের পরিবর্তে /system ভার্সন ব্যবহার করে, কারণ P ভার্সন সবসময় O-MR1-এর জন্য তৈরি যেকোনও অ্যাপের চেয়ে উন্নত।

tapas ব্যবহার করে Data অ্যাপ তৈরি করা

টাইম জোন ডেটা অ্যাপের বেশিরভাগ দিক ম্যানেজ করা এবং সিস্টেম ইমেজ সঠিকভাবে কনফিগার করার দায়িত্ব OEM-এর। Data অ্যাপটি tapas বিল্ডের মাধ্যমে তৈরি করার উদ্দেশ্যে করা হয়েছে যা সিস্টেম ইমেজে (প্রাথমিক রিলিজের জন্য) যোগ করার উপযুক্ত APK তৈরি করে এবং অ্যাপ স্টোরের (পরবর্তী আপডেটের জন্য) মাধ্যমে সাইন ও ডিস্ট্রিবিউট করা হয়।

Tapas হল Android বিল্ড সিস্টেমের একটি স্লিমড-ডাউন ভার্সন যা অ্যাপের ডিস্ট্রিবিউট করার মতো ভার্সন তৈরি করতে একটি ছোট সোর্স ট্রি ব্যবহার করে। সাধারণ Android বিল্ড সিস্টেমের সাথে পরিচিত OEM-এর সাধারণ Android প্ল্যাটফর্ম বিল্ড থেকে বিল্ড ফাইল শনাক্ত করতে হবে।

ম্যানিফেস্ট তৈরি করা

সাধারণত, কাস্টম ম্যানিফেস্ট ফাইলের মাধ্যমে সোর্স ট্রি কমানো হয়। এই ফাইলটি বিল্ড সিস্টেম ও অ্যাপ তৈরির জন্য প্রয়োজনীয় Git প্রোজেক্টের রেফারেন্স দেয়। ডেটা অ্যাপ তৈরি করা নিবন্ধে দেওয়া নির্দেশাবলী অনুসরণ করার পরে, OEM-এর কাছে অন্তত দুটি OEM-নির্দিষ্ট Git প্রোজেক্ট থাকতে হবে। এই প্রোজেক্টগুলি packages/apps/TimeZoneData/oem_template-এর অধীনে থাকা টেমপ্লেট ফাইল ব্যবহার করে তৈরি করা হয়:

• একটি Git প্রোজেক্টে অ্যাপ ফাইল থাকে, যেমন ম্যানিফেস্ট এবং অ্যাপ APK ফাইল তৈরি করার জন্য প্রয়োজনীয় বিল্ড ফাইল (যেমন, vendor/oem/apps/TimeZoneData)। এই প্রোজেক্টে টেস্ট APK-এর জন্য বিল্ড রুলও থাকে যা xTS টেস্ট ব্যবহার করতে পারে।
• একটি Git প্রোজেক্টে সিস্টেম ইমেজ বিল্ড এবং xTS টেস্টে অন্তর্ভুক্ত করার জন্য অ্যাপ বিল্ডের মাধ্যমে তৈরি করা স্বাক্ষরিত APK থাকে।

অ্যাপ বিল্ডে অন্যান্য Git প্রোজেক্ট ব্যবহার করা হয় যা প্ল্যাটফর্ম বিল্ডের সাথে শেয়ার করা হয় অথবা এতে OEM-নিরপেক্ষ কোড লাইব্রেরি থাকে।

নিম্নলিখিত ম্যানিফেস্ট স্নিপেটে টাইম জোন ডেটা অ্যাপের O-MR1 বিল্ডের জন্য প্রয়োজনীয় ন্যূনতম Git প্রজেক্টের সেট রয়েছে। OEM-দের এই ম্যানিফেস্টে তাদের OEM-নির্দিষ্ট Git প্রজেক্ট (যেটিতে সাধারণত সাইন করার সার্টিফিকেট থাকে) যোগ করতে হবে এবং সেই অনুযায়ী আলাদা ব্রাঞ্চ কনফিগার করতে হবে।

   <!-- Tapas Build -->
    <project
        path="build"
        name="platform/build">
        <copyfile src="core/root.mk" dest="Makefile" />
    </project>
    <project
        path="prebuilts/build-tools"
        name="platform/prebuilts/build-tools"
        clone-depth="1" />
    <project
        path="prebuilts/go/linux-x86"
        name="platform/prebuilts/go/linux-x86"
        clone-depth="1" />
    <project
        path="build/blueprint"
        name="platform/build/blueprint" />
    <project
        path="build/kati"
        name="platform/build/kati" />
    <project
        path="build/soong"
        name="platform/build/soong">
        <linkfile src="root.bp" dest="Android.bp" />
        <linkfile src="bootstrap.bash" dest="bootstrap.bash" />
    </project>

    <!-- SDK for system / public API stubs -->
    <project
        path="prebuilts/sdk"
        name="platform/prebuilts/sdk"
        clone-depth="1" />
    <!-- App source -->
    <project
        path="system/timezone"
        name="platform/system/timezone" />
    <project
        path="packages/apps/TimeZoneData"
        name="platform/packages/apps/TimeZoneData" />
    <!-- Enable repohooks -->
    <project
        path="tools/repohooks"
        name="platform/tools/repohooks"
        revision="main"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

tapas বিল্ড রান করানো

সোর্স ট্রি তৈরি হয়ে গেলে, নিম্নলিখিত কমান্ড ব্যবহার করে tapas বিল্ড ইনভোক করুন:

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

সফলভাবে বিল্ড করা হলে, out/dist ডিরেক্টরিতে পরীক্ষা করার জন্য ফাইল তৈরি হয়। সিস্টেম ইমেজে অন্তর্ভুক্ত করার জন্য এইসব ফাইলকে প্রি-বিল্ট ডিরেক্টরিতে রাখা যেতে পারে এবং/অথবা মানানসই ডিভাইসের জন্য অ্যাপ স্টোরের মাধ্যমে ডিস্ট্রিবিউট করা যেতে পারে।