সময় অঞ্চলের নিয়ম

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

সময় অঞ্চল আপডেট (Android 10 এবং উচ্চতর)

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

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

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

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

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

দ্রষ্টব্য: APK-ভিত্তিক টাইম জোন ডেটা আপডেট মেকানিজম বৈশিষ্ট্যটি অ্যান্ড্রয়েড 14 থেকে সম্পূর্ণরূপে সরানো হয়েছে এবং সোর্স কোডে পাওয়া যাবে না। অংশীদারদের সম্পূর্ণরূপে টাইম জোন মেইনলাইন মডিউলে স্থানান্তরিত করা উচিত৷

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

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

অ্যান্ড্রয়েড টাইম জোন সোর্স কোড এবং ডেটা

সমস্ত স্টক অ্যান্ড্রয়েড ডিভাইস, এমনকি যারা এই বৈশিষ্ট্যটি ব্যবহার করছে না, তাদের টাইম জোন নিয়ম ডেটার প্রয়োজন এবং /system পার্টিশনে টাইম জোন নিয়ম ডেটার একটি ডিফল্ট সেট সহ শিপ করতে হবে। এই ডেটা তারপরে Android সোর্স ট্রিতে নিম্নলিখিত লাইব্রেরি থেকে কোড দ্বারা ব্যবহার করা হয়:

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

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

অ্যান্ড্রয়েড সিস্টেমের উপাদানগুলির জন্য সময় অঞ্চল নিয়ম ডেটার প্রয়োজন প্রথমে নিম্নলিখিত অবস্থানগুলি পরীক্ষা করুন:

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

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

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

ডিস্ট্রো ফাইল ফরম্যাটটি অ্যান্ড্রয়েড-রিলিজ নির্ভর কারণ আইসিইউ সংস্করণ, অ্যান্ড্রয়েড প্ল্যাটফর্মের প্রয়োজনীয়তা এবং অন্যান্য প্রকাশের পরিবর্তনের সাথে বিষয়বস্তু পরিবর্তিত হয়। অ্যান্ড্রয়েড প্রতিটি IANA আপডেটের জন্য সমর্থিত অ্যান্ড্রয়েড রিলিজের জন্য ডিস্ট্রো ফাইল সরবরাহ করে (প্ল্যাটফর্ম সিস্টেম ফাইলগুলি আপডেট করার পাশাপাশি)। তাদের ডিভাইসগুলিকে আপ টু ডেট রাখতে, 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-নির্দিষ্ট, ডেটা অ্যাপ প্যাকেজ নামের পরিবর্তনগুলি দেখে।
   
   

   চিত্র 1. ডেটা অ্যাপ আপডেট।

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

   চিত্র 2. ট্রিগার আপডেট চেক।

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

     চিত্র 3. ডেটা অ্যাপ আপডেট, RulesManagerService কল করা।

   • ডিস্ট্রো সম্পর্কে তথ্য পেতে একটি সু-সংজ্ঞায়িত বিষয়বস্তু প্রদানকারী URL এবং কলামের চশমা জিজ্ঞাসা করে ডেটা অ্যাপকে প্রশ্ন করে৷
     
     

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

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

   চিত্র 5. সম্পূর্ণ পরীক্ষা করুন।

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

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

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

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

নিরাপত্তা

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

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

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

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

টাইম জোন আপডেট বৈশিষ্ট্য সক্রিয় করতে, OEM গুলি সাধারণত:

• তাদের নিজস্ব ডেটা অ্যাপ তৈরি করুন।
• সিস্টেম ইমেজ বিল্ডে আপডেটার এবং ডেটা অ্যাপস অন্তর্ভুক্ত করুন।
• RulesManagerService সক্ষম করতে সিস্টেম সার্ভার কনফিগার করুন।

প্রস্তুতি

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

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

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

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

OEM তাদের নিজস্ব আইকন, নাম, অনুবাদ এবং অন্যান্য বিবরণ দিয়ে ডেটা অ্যাপ কাস্টমাইজ করতে পারে। যাইহোক, যেহেতু ডেটা অ্যাপ চালু করা যাবে না, আইকনটি শুধুমাত্র সেটিংস > অ্যাপ স্ক্রিনে প্রদর্শিত হবে।

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

OEM-কে অবশ্যই /system/priv-app এ একটি ডিভাইসের সিস্টেম ইমেজে পূর্বনির্মাণ করা ডেটা অ্যাপ ইনস্টল করতে হবে। সিস্টেম ইমেজে প্রি-বিল্ট APKs (টাপাস বিল্ড প্রসেস দ্বারা তৈরি) অন্তর্ভুক্ত করতে, OEMগুলি packages/apps/TimeZoneData/oem_template/data_app_prebuilt এ উদাহরণ ফাইলগুলি অনুলিপি করতে পারে। উদাহরণ টেমপ্লেটগুলি টেস্ট স্যুটগুলিতে ডেটা অ্যাপের পরীক্ষার সংস্করণগুলি অন্তর্ভুক্ত করার জন্য বিল্ড লক্ষ্যগুলিও অন্তর্ভুক্ত করে।

সিস্টেম ইমেজে আপডেটার এবং ডেটা অ্যাপস অন্তর্ভুক্ত করুন

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

আপডেটার অ্যাপটি প্ল্যাটফর্ম কী দিয়ে স্বাক্ষরিত হওয়া উচিত এবং অন্য যেকোন সিস্টেম অ্যাপের মতো অন্তর্ভুক্ত করা উচিত। লক্ষ্যটি packages/apps/TimeZoneUpdater এ TimeZoneUpdater হিসাবে সংজ্ঞায়িত করা হয়েছে। ডেটা অ্যাপ অন্তর্ভুক্তি হল OEM-নির্দিষ্ট এবং প্রি-বিল্ডের জন্য বেছে নেওয়া টার্গেট নামের উপর নির্ভর করে।

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

টাইম জোন আপডেটগুলি সক্ষম করতে, 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) ব্যবহার করে স্ট্যান্ডার্ড অ্যান্ড্রয়েড টেস্ট স্যুটের মতো। যে 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-তে রিলিজ আপডেট করার জন্য প্যাচ তৈরি করে। স্টক অ্যান্ড্রয়েড সিস্টেম এবং ডিস্ট্রো ফাইলগুলি ব্যবহার করে OEMগুলি এই কমিটগুলি নিতে পারে, তাদের ডেটা অ্যাপের একটি নতুন সংস্করণ তৈরি করতে ব্যবহার করতে পারে, তারপরে তাদের ডিভাইসগুলিকে উত্পাদনে আপডেট করতে নতুন সংস্করণ প্রকাশ করতে পারে।

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

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

এই ধাপে, OEMগুলি AOSP-এর রিলিজ -dev শাখাগুলি থেকে system/timezone এবং external/icu জন্য অ্যান্ড্রয়েড প্রতিশ্রুতিগুলি স্টক করে এবং সেই প্রতিশ্রুতিগুলি তাদের Android সোর্স কোডের অনুলিপিতে প্রয়োগ করে৷

সিস্টেম/টাইমজোন AOSP প্যাচে system/timezone/input_data এবং system/timezone/output_data আপডেট করা ফাইল রয়েছে। যে OEM-দের অতিরিক্ত স্থানীয় সংশোধন করতে হবে তারা ইনপুট ফাইলগুলি সংশোধন করতে পারে তারপর output_data এ ফাইল তৈরি করতে system/timezone/input_data এবং external/icu এ ফাইলগুলি ব্যবহার করতে পারে।

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

ধাপ 2: ডেটা অ্যাপের সংস্করণ কোড আপডেট করুন

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

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

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

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

ধাপ 3: পুনঃনির্মাণ করুন, সাইন করুন, পরীক্ষা করুন এবং প্রকাশ করুন

এই ধাপে, OEMs tapas ব্যবহার করে APK পুনর্নির্মাণ করে, জেনারেট করা APK-এ স্বাক্ষর করে, তারপর APK পরীক্ষা করে ছেড়ে দেয়:

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

OEMগুলি মানের নিশ্চয়তা এবং রিলিজের আগে তাদের ডিভাইসে আপডেট করা ডেটা অ্যাপ পরীক্ষা করার জন্য দায়ী৷

ডেটা অ্যাপ সংস্করণ কোড কৌশল

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

APK সংস্করণ কোড নিম্নলিখিত তথ্য অন্তর্ভুক্ত করা উচিত:

• ডিস্ট্রো ফরম্যাট সংস্করণ (প্রধান + ছোট)
• একটি ক্রমবর্ধমান (অস্বচ্ছ) সংস্করণ নম্বর

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

উদাহরণ সংস্করণ কোড কৌশল

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

চিত্র 6. উদাহরণ সংস্করণ কোড কৌশল।

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

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

• উদাহরণ 1 এবং 2 একই 2017a IANA রিলিজের জন্য বিভিন্ন প্রধান ফর্ম্যাট সংস্করণ সহ দুটি APK সংস্করণ দেখায়৷ 2 সংখ্যাগতভাবে 1 থেকে বেশি, যা নতুন ডিভাইসগুলি উচ্চতর বিন্যাস সংস্করণগুলি গ্রহণ করে তা নিশ্চিত করার জন্য প্রয়োজন। minSdkVersion নিশ্চিত করে যে P সংস্করণটি O ডিভাইসে সরবরাহ করা হবে না।
• উদাহরণ 3 হল 1 এর জন্য একটি রিভিশন/ফিক্স এবং সংখ্যাগতভাবে 1 এর থেকে বেশি৷
• উদাহরণ 4 এবং 5 O-MR1 এবং P-এর জন্য 2017b রিলিজগুলি দেখায়। সংখ্যাগতভাবে উচ্চতর হওয়ায়, তারা তাদের নিজ নিজ পূর্বসূরীদের পূর্ববর্তী IANA রিলিজ/Android সংশোধনগুলি প্রতিস্থাপন করে।
• উদাহরণ 6 এবং 7 O-MR1 এবং P এর জন্য 2018a প্রকাশগুলি দেখায়।
• উদাহরণ 8 সম্পূর্ণরূপে Y=0 স্কিম প্রতিস্থাপন করতে Y এর ব্যবহার প্রদর্শন করে।
• উদাহরণ 9 এপিকে পুনরায় স্পিন করতে 3 এবং 4 এর মধ্যে থাকা ফাঁকের ব্যবহার প্রদর্শন করে।

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

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

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

Tapas হল অ্যান্ড্রয়েড বিল্ড সিস্টেমের একটি স্লিমড-ডাউন সংস্করণ যা অ্যাপগুলির বিতরণযোগ্য সংস্করণ তৈরি করতে একটি হ্রাসকৃত উৎস গাছ ব্যবহার করে। সাধারণ অ্যান্ড্রয়েড বিল্ড সিস্টেমের সাথে পরিচিত OEMগুলিকে সাধারণ অ্যান্ড্রয়েড প্ল্যাটফর্ম বিল্ড থেকে বিল্ড ফাইলগুলি চিনতে হবে৷

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

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

• ওয়ান গিট প্রোজেক্টে অ্যাপ ফাইল রয়েছে যেমন ম্যানিফেস্ট এবং অ্যাপ APK ফাইল তৈরি করতে প্রয়োজনীয় বিল্ড ফাইল (উদাহরণস্বরূপ, vendor/ oem /apps/TimeZoneData )। এই প্রকল্পে পরীক্ষার APKগুলির জন্য বিল্ড নিয়ম রয়েছে যা xTS পরীক্ষা দ্বারা ব্যবহার করা যেতে পারে।
• ওয়ান গিট প্রজেক্টে সিস্টেম ইমেজ বিল্ড এবং xTS পরীক্ষায় অন্তর্ভুক্তির জন্য অ্যাপ বিল্ড দ্বারা উত্পাদিত স্বাক্ষরিত APKগুলি রয়েছে৷

অ্যাপ বিল্ডটি অন্যান্য বেশ কয়েকটি গিট প্রকল্পের সুবিধা দেয় যা প্ল্যাটফর্ম বিল্ডের সাথে ভাগ করা হয় বা OEM-স্বাধীন কোড লাইব্রেরি ধারণ করে।

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

   <!-- 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" />

তাপস বিল্ড চালান

সোর্স ট্রি প্রতিষ্ঠিত হওয়ার পরে, নিম্নলিখিত কমান্ডগুলি ব্যবহার করে তাপস বিল্ডকে আহ্বান করুন:

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

একটি সফল বিল্ড পরীক্ষার জন্য out/dist ডিরেক্টরিতে ফাইল তৈরি করে। এই ফাইলগুলিকে সিস্টেম ইমেজে অন্তর্ভুক্ত করার জন্য প্রি-বিল্ট ডিরেক্টরিতে স্থাপন করা যেতে পারে এবং/অথবা সামঞ্জস্যপূর্ণ ডিভাইসগুলির জন্য একটি অ্যাপ স্টোরের মাধ্যমে বিতরণ করা যেতে পারে।