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

অ্যান্ড্রয়েড ১০, এপিকে-ভিত্তিক টাইম জোন ডেটা আপডেট প্রক্রিয়াটিকে (যা অ্যান্ড্রয়েড ৮.১ এবং অ্যান্ড্রয়েড ৯-এ উপলব্ধ ছিল) বাতিল করে এবং এর পরিবর্তে একটি এপেক্স-ভিত্তিক মডিউল আপডেট প্রক্রিয়া চালু করেছে। AOSP ৮.১ থেকে ১৩-এর মধ্যে এখনও OEM-দের এপিকে-ভিত্তিক আপডেট চালু করার জন্য প্রয়োজনীয় প্ল্যাটফর্ম কোড অন্তর্ভুক্ত রয়েছে, তাই অ্যান্ড্রয়েড ১০-এ আপগ্রেড করা ডিভাইসগুলো এখনও এপিকে-এর মাধ্যমে পার্টনারদের দেওয়া টাইম জোন ডেটা আপডেট পেতে পারে। তবে, যে প্রোডাকশন ডিভাইসটি মডিউল আপডেটও পাচ্ছে, সেখানে এপিকে আপডেট প্রক্রিয়াটি ব্যবহার করা উচিত নয়, কারণ একটি এপিকে-ভিত্তিক আপডেট একটি এপেক্স-ভিত্তিক আপডেটকে বাতিল করে দেয় (অর্থাৎ, যে ডিভাইসটি একটি এপিকে আপডেট পেয়েছে, সেটি এপেক্স-ভিত্তিক আপডেটগুলোকে উপেক্ষা করবে)।

সময় অঞ্চলের আপডেট (অ্যান্ড্রয়েড ১০ এবং উচ্চতর সংস্করণ)

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

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

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

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

সময় অঞ্চলের আপডেট (অ্যান্ড্রয়েড ৮.১–৯)

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

অ্যান্ড্রয়েড ৮.১ এবং অ্যান্ড্রয়েড ৯-এ, OEM-রা সিস্টেম আপডেটের প্রয়োজন ছাড়াই ডিভাইসগুলিতে হালনাগাদ করা টাইম জোন নিয়মের ডেটা পাঠানোর জন্য একটি APK-ভিত্তিক পদ্ধতি ব্যবহার করতে পারে। এই পদ্ধতিটি ব্যবহারকারীদের সময়মতো আপডেট পেতে সক্ষম করে (ফলে একটি অ্যান্ড্রয়েড ডিভাইসের কার্যকর জীবনকাল বৃদ্ধি পায়) এবং অ্যান্ড্রয়েড পার্টনারদের সিস্টেম ইমেজ আপডেট থেকে স্বাধীনভাবে টাইম জোন আপডেট পরীক্ষা করার সুযোগ দেয়।

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

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

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

• libcore/ থেকে পরিচালিত কোড (উদাহরণস্বরূপ, java.util.TimeZone ) tzdata এবং tzlookup.xml ফাইল ব্যবহার করে।
• bionic/ ফোল্ডারের নেটিভ লাইব্রেরি কোড (যেমন, mktime , localtime সিস্টেম কলগুলোর জন্য) 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 ডিরেক্টরিটি পূরণ করার জন্য প্রয়োজনীয় ডেটা ফাইলগুলো থাকে। এই ডিস্ট্রো ফাইলগুলোতে মেটাডেটাও থাকে, যা ডিভাইসগুলোকে ভার্সনিং সংক্রান্ত সমস্যা শনাক্ত করতে সাহায্য করে।

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

সময় অঞ্চল আপডেট উপাদান

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

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

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

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

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

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

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

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

   চিত্র ২. আপডেট যাচাই ট্রিগার করুন।

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

     চিত্র ৩। ডেটা অ্যাপ আপডেট হচ্ছে এবং RulesManagerService-কে কল করা হচ্ছে।

   • ডিস্ট্রো সম্পর্কে তথ্য পেতে একটি সুনির্দিষ্ট ContentProvider URL এবং কলাম স্পেকস কোয়েরি করার মাধ্যমে ডেটা অ্যাপকে কোয়েরি করা হয়।
     
     

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

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

   চিত্র ৫। সম্পূর্ণ হয়েছে কিনা যাচাই করুন।

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

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

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

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

নিরাপত্তা

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

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

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

সময় অঞ্চলের আপডেটগুলি একীভূত করুন

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

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

প্রস্তুতি

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

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

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

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

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

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

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

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

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

আপডেটার অ্যাপটিকে প্ল্যাটফর্ম কী দিয়ে সাইন করতে হবে এবং অন্য যেকোনো সিস্টেম অ্যাপের মতোই অন্তর্ভুক্ত করতে হবে। টার্গেটটি 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-নির্দিষ্ট টেস্ট স্যুটকে বোঝায়, যা স্ট্যান্ডার্ড অ্যান্ড্রয়েড টেস্ট স্যুটের (যেমন CTS এবং VTS) অনুরূপ। যেসব OEM-এর এই ধরনের টেস্ট স্যুট রয়েছে, তারা নিম্নলিখিত স্থানগুলিতে প্রদত্ত অ্যান্ড্রয়েড টাইম জোন আপডেট টেস্টগুলি যোগ করতে পারেন:

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

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

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

যেহেতু ডেটা অ্যাপে অ্যান্ড্রয়েড ভার্সনের সাথে ঘনিষ্ঠভাবে যুক্ত ডিস্ট্রো ফাইল থাকে, তাই OEM-দেরকে প্রতিটি সমর্থিত অ্যান্ড্রয়েড রিলিজের জন্য ডেটা অ্যাপের একটি নতুন সংস্করণ তৈরি করতে হয়, যা তারা আপডেট করতে চায়। উদাহরণস্বরূপ, যদি কোনো OEM অ্যান্ড্রয়েড ৮.১, ৯, এবং ১০ ডিভাইসগুলোর জন্য আপডেট দিতে চায়, তবে তাদের এই প্রক্রিয়াটি তিনবার সম্পন্ন করতে হবে।

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

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

system/timezone 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 , যা ডেটা অ্যাপের APK তৈরি করার সময় স্বয়ংক্রিয়ভাবে অন্তর্ভুক্ত হয়ে যায়।

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

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

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

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

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

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

এই ধাপে, OEM-রা tapas ব্যবহার করে APK-টি পুনর্নির্মাণ করে, তৈরি হওয়া APK-টিতে স্বাক্ষর করে, তারপর APK-টি পরীক্ষা করে প্রকাশ করে:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

অ্যাপ বিল্ডটি আরও বেশ কয়েকটি গিট প্রজেক্ট ব্যবহার করে, যেগুলো প্ল্যাটফর্ম বিল্ডের সাথে শেয়ার করা হয় অথবা যেগুলোতে 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" />

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

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

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

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