এই পৃষ্ঠাটি বিল্ডগুলির মধ্যে অপ্রয়োজনীয় ফাইল পরিবর্তনগুলি কমাতে AOSP-তে যোগ করা পরিবর্তনগুলি বর্ণনা করে। ডিভাইস বাস্তবায়নকারীরা যারা তাদের নিজস্ব বিল্ড সিস্টেম বজায় রাখে তারা তাদের ওভার-দ্য-এয়ার (OTA) আপডেটের আকার হ্রাস করার জন্য এই তথ্যটি একটি গাইড হিসাবে ব্যবহার করতে পারে।
Android OTA আপডেটে মাঝে মাঝে পরিবর্তিত ফাইল থাকে যা কোড পরিবর্তনের সাথে সঙ্গতিপূর্ণ নয়। তারা আসলে সিস্টেম আর্টিফ্যাক্ট নির্মাণ করছি. এটি ঘটতে পারে যখন একই কোড, বিভিন্ন সময়ে নির্মিত, বিভিন্ন ডিরেক্টরি থেকে, বা বিভিন্ন মেশিনে প্রচুর পরিবর্তিত ফাইল তৈরি করে। এই ধরনের অতিরিক্ত ফাইলগুলি একটি OTA প্যাচের আকার বাড়ায় এবং কোন কোডটি পরিবর্তিত হয়েছে তা নির্ধারণ করা কঠিন করে তোলে।
একটি OTA-এর বিষয়বস্তুকে আরও স্বচ্ছ করতে, AOSP-এ OTA প্যাচের আকার কমানোর জন্য ডিজাইন করা বিল্ড সিস্টেম পরিবর্তনগুলি অন্তর্ভুক্ত রয়েছে। বিল্ডগুলির মধ্যে অপ্রয়োজনীয় ফাইল পরিবর্তনগুলি বাদ দেওয়া হয়েছে, এবং শুধুমাত্র প্যাচ-সম্পর্কিত ফাইলগুলি OTA আপডেটগুলিতে রয়েছে৷ AOSP-এ একটি বিল্ড ডিফ টুলও রয়েছে, যা একটি ক্লিনার বিল্ড ফাইল ডিফ প্রদান করতে সাধারণ বিল্ড-সম্পর্কিত ফাইল পরিবর্তনগুলিকে ফিল্টার করে এবং একটি ব্লক ম্যাপিং টুল , যা আপনাকে ব্লক বরাদ্দ সামঞ্জস্য রাখতে সাহায্য করে।
একটি বিল্ড সিস্টেম বিভিন্ন উপায়ে অপ্রয়োজনীয়ভাবে বড় প্যাচ তৈরি করতে পারে। এটি প্রশমিত করার জন্য, Android 8.0 এবং উচ্চতর সংস্করণে, প্রতিটি ফাইলের পার্থক্যের জন্য প্যাচের আকার কমাতে নতুন বৈশিষ্ট্যগুলি প্রয়োগ করা হয়েছিল৷ উন্নতি যা OTA-আপডেট প্যাকেজের আকার হ্রাস করেছে তার মধ্যে রয়েছে:
- ZSTD- এর ব্যবহার, একটি জেনেরিক-উদ্দেশ্য, লসলেস-কম্প্রেশন অ্যালগরিদম নন-A/B ডিভাইস আপডেটে সম্পূর্ণ চিত্রের জন্য। কম্প্রেশন লেভেল বাড়িয়ে উচ্চ কম্প্রেশন অনুপাতের জন্য ZSTD কাস্টমাইজ করা যেতে পারে। OTA জেনারেশনের সময় কম্প্রেশন লেভেল সেট করা হয় এবং পতাকা পাস করে সেট করা যায়
--vabc_compression_param=zstd,$COMPRESSION_LEVEL
- OTA এর সময় ব্যবহৃত কম্প্রেশন উইন্ডোর আকার বৃদ্ধি করা। একটি ডিভাইসের
.mk
ফাইলে বিল্ড প্যারামিটার কাস্টমাইজ করে সর্বাধিক কম্প্রেশন উইন্ডোর আকার সেট করা যেতে পারে। এই ভেরিয়েবলটিPRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 262144
হিসাবে সেট করা হয়েছে - পাফিন রিকম্প্রেশনের ব্যবহার, ডিফ্লেট স্ট্রিমগুলির জন্য একটি নির্ধারক প্যাচিং টুল, যা A/B OTA আপডেট জেনারেশনের জন্য কম্প্রেশন এবং ডিফ ফাংশন পরিচালনা করে।
- ডেল্টা-জেনারেশন টুল ব্যবহারে পরিবর্তন, যেমন
bsdiff
লাইব্রেরি কীভাবে প্যাচ সংকুচিত করার জন্য ব্যবহার করা হয়। Android 9 এবং উচ্চতর তে,bsdiff
টুল কম্প্রেশন অ্যালগরিদম নির্বাচন করে যা একটি প্যাচের জন্য সেরা কম্প্রেশন ফলাফল দেবে। -
update_engine
উন্নতির ফলে A/B ডিভাইস আপডেটের জন্য প্যাচ প্রয়োগ করা হলে মেমরি কম খরচ হয়।
নিম্নলিখিত বিভাগগুলি বিভিন্ন সমস্যা নিয়ে আলোচনা করে যা OTA-আপডেটের আকার, তাদের সমাধান এবং AOSP-তে বাস্তবায়নের উদাহরণগুলিকে প্রভাবিত করে।
ফাইল অর্ডার
সমস্যা : ফাইল সিস্টেমগুলি যখন একটি ডিরেক্টরিতে ফাইলগুলির একটি তালিকা চাওয়া হলে একটি ফাইল অর্ডারের গ্যারান্টি দেয় না, যদিও এটি একই চেকআউটের জন্য সাধারণত একই। ls
এর মতো টুলগুলি ডিফল্টভাবে ফলাফলগুলিকে সাজায়, কিন্তু ওয়াইল্ডকার্ড ফাংশনটি কমান্ড দ্বারা ব্যবহৃত হয় যেমন find
এবং make
না সাজানো৷ এই সরঞ্জামগুলি ব্যবহার করার আগে, আপনাকে অবশ্যই আউটপুটগুলি সাজাতে হবে।
সমাধান : আপনি যখন ওয়াইল্ডকার্ড ফাংশন দিয়ে find
অ্যান্ড make
এর মতো টুল ব্যবহার করেন, তখন সেগুলি ব্যবহার করার আগে এই কমান্ডগুলির আউটপুট সাজান। Android.mk
ফাইলগুলিতে $(wildcard)
বা $(shell find)
ব্যবহার করার সময়, সেগুলিকেও সাজান। কিছু টুল, যেমন জাভা, ইনপুট বাছাই করে, তাই আপনি ফাইলগুলি সাজানোর আগে যাচাই করুন যে আপনি যে টুলটি ব্যবহার করছেন সেটি ইতিমধ্যে এটি করেনি।
উদাহরণ: বিল্টইন all-*-files-under
ম্যাক্রো ব্যবহার করে কোর বিল্ড সিস্টেমে অনেকগুলি দৃষ্টান্ত স্থির করা হয়েছিল, যার মধ্যে all-cpp-files-under
অন্তর্ভুক্ত রয়েছে (যেমন অন্যান্য মেকফাইলে বিভিন্ন সংজ্ঞা ছড়িয়ে দেওয়া হয়েছিল)। বিস্তারিত জানার জন্য, নিম্নলিখিত দেখুন:
- https://android.googlesource.com/platform/build/+/4d66adfd0e6d599d8502007e4ea9aaf82e95569f
- https://android.googlesource.com/platform/build/+/379f9f9cec4fe1c66b6d60a6c19fecb81b9eb410
- https://android.googlesource.com/platform/build/+/7c3e3f8314eec2c053012dd97d2ae649ebeb5653
- https://android.googlesource.com/platform/build/+/5c64b4e81c1331cab56d8a8c201f26bb263b630c
ডিরেক্টরি তৈরি করুন
সমস্যা: যে ডিরেক্টরিতে জিনিসগুলি তৈরি করা হয় সেটি পরিবর্তন করলে বাইনারিগুলি ভিন্ন হতে পারে। অ্যান্ড্রয়েড বিল্ডের বেশিরভাগ পাথ আপেক্ষিক পাথ তাই C/C++ এ __FILE__
কোনো সমস্যা নয়। যাইহোক, ডিবাগ চিহ্নগুলি ডিফল্টরূপে সম্পূর্ণ পাথনেম এনকোড করে এবং .note.gnu.build-id
তৈরি হয় প্রি-স্ট্রিপড বাইনারি হ্যাশ করার ফলে, তাই ডিবাগ চিহ্নগুলি পরিবর্তন হলে এটি পরিবর্তন হবে।
সমাধান: AOSP এখন ডিবাগ পাথ আপেক্ষিক করে তোলে। বিস্তারিত জানার জন্য, CL দেখুন: https://android.googlesource.com/platform/build/+/6a66a887baadc9eb3d0d60e26f748b8453e27a02 ।
টাইমস্ট্যাম্প
সমস্যা: বিল্ড আউটপুটে টাইমস্ট্যাম্পের ফলে অপ্রয়োজনীয় ফাইল পরিবর্তন হয়। এটি নিম্নলিখিত অবস্থানে ঘটতে পারে:
-
__DATE__/__TIME__/__TIMESTAMP__
ম্যাক্রো C বা C++ কোডে। - জিপ-ভিত্তিক আর্কাইভে এমবেড করা টাইমস্ট্যাম্প।
সমাধান/উদাহরণ: বিল্ড আউটপুট থেকে টাইমস্ট্যাম্প অপসারণ করতে, C/C++ এ __DATE__/__TIME__/__TIMESTAMP__-এ নিচে দেওয়া নির্দেশাবলী ব্যবহার করুন। এবং আর্কাইভে এমবেডেড টাইমস্ট্যাম্প ।
__DATE__/__TIME__/__TIMESTAMP__ C/C++ এ
এই ম্যাক্রোগুলি সর্বদা বিভিন্ন বিল্ডের জন্য বিভিন্ন আউটপুট তৈরি করে, তাই সেগুলি ব্যবহার করবেন না। এই ম্যাক্রোগুলি নির্মূল করার জন্য এখানে কয়েকটি বিকল্প রয়েছে:
- তাদের সরান. উদাহরণের জন্য, https://android.googlesource.com/platform/system/core/+/30622bbb209db187f6851e4cf0cdaa147c2fca9f দেখুন।
- চলমান বাইনারিটিকে অনন্যভাবে সনাক্ত করতে, ELF হেডার থেকে বিল্ড-আইডি পড়ুন।
- ওএস কখন তৈরি করা হয়েছিল তা জানতে,
ro.build.date
পড়ুন (এটি ক্রমবর্ধমান বিল্ড ছাড়া সবকিছুর জন্য কাজ করে, যা এই তারিখটি আপডেট নাও করতে পারে)। উদাহরণের জন্য, https://android.googlesource.com/platform/external/libchrome/+/8b7977eccc94f6b3a3896cd13b4aeacbfa1e0f84 দেখুন।
আর্কাইভে এম্বেড করা টাইমস্ট্যাম্প (জিপ, জার)
অ্যান্ড্রয়েড 7.0 zip
কমান্ডের সমস্ত ব্যবহারে -X
যুক্ত করে জিপ আর্কাইভে এমবেডেড টাইমস্ট্যাম্পের সমস্যা সমাধান করেছে। এটি বিল্ডারের UID/GID এবং জিপ ফাইল থেকে বর্ধিত ইউনিক্স টাইমস্ট্যাম্প সরিয়ে দিয়েছে।
একটি নতুন টুল, ziptime
( /platform/build/+/main/tools/ziptime/
তে অবস্থিত) জিপ শিরোনামগুলিতে স্বাভাবিক টাইমস্ট্যাম্পগুলি পুনরায় সেট করে। বিস্তারিত জানার জন্য, README ফাইলটি পড়ুন।
signapk
টুলটি APK ফাইলগুলির জন্য টাইমস্ট্যাম্প সেট করে যা সার্ভারের টাইমজোনের উপর নির্ভর করে পরিবর্তিত হতে পারে। বিস্তারিত জানার জন্য, CL https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028 দেখুন।
signapk
টুলটি APK ফাইলগুলির জন্য টাইমস্ট্যাম্প সেট করে যা সার্ভারের টাইমজোনের উপর নির্ভর করে পরিবর্তিত হতে পারে। বিস্তারিত জানার জন্য, CL https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028 দেখুন।
সংস্করণ স্ট্রিং
সমস্যা: APK সংস্করণের স্ট্রিংগুলিতে প্রায়শই তাদের হার্ডকোড করা সংস্করণগুলির সাথে BUILD_NUMBER
যুক্ত থাকে৷ এমনকি একটি APK-এ অন্য কিছু না পরিবর্তিত হলেও, ফলস্বরূপ, APK এখনও ভিন্ন হবে।
সমাধান: APK সংস্করণ স্ট্রিং থেকে বিল্ড নম্বর সরান।
উদাহরণ:
- https://android.googlesource.com/platform/packages/apps/Camera2/+/5e0f4cf699a4c7c95e2c38ae3babe6f20c258d27
- https://android.googlesource.com/platform/build/+/d75d893da8f97a5c7781142aaa7a16cf1dbb669c
অন-ডিভাইস যাচাই গণনা সক্ষম করুন
যদি আপনার ডিভাইসে dm-verity সক্ষম করা থাকে, তাহলে OTA টুলগুলি স্বয়ংক্রিয়ভাবে আপনার ভেরিটি কনফিগারেশন গ্রহণ করে এবং অন-ডিভাইস ভেরিটি গণনা সক্ষম করে। এটি আপনার OTA প্যাকেজে কাঁচা বাইট হিসাবে সংরক্ষণ করার পরিবর্তে অ্যান্ড্রয়েড ডিভাইসে সত্যতা ব্লকগুলিকে গণনা করার অনুমতি দেয়৷ ভেরিটি ব্লক 2GB পার্টিশনের জন্য প্রায় 16MB ব্যবহার করতে পারে।
যাইহোক, ডিভাইসে কম্পিউটিং ভেরিটি অনেক সময় নিতে পারে। বিশেষত, ফরোয়ার্ড ত্রুটি-সংশোধন কোডটি দীর্ঘ সময় নিতে পারে। পিক্সেল ডিভাইসে, এটি 10 মিনিট পর্যন্ত সময় নেয়। লো-এন্ড ডিভাইসে এটি বেশি সময় নিতে পারে। আপনি যদি অন-ডিভাইস ভেরিটি কম্পিউটেশন অক্ষম করতে চান, কিন্তু তারপরও dm-verity সক্ষম করেন, তাহলে আপনি OTA আপডেট তৈরি করার সময় ota_from_target_files
টুলে --disable_fec_computation
পাস করে তা করতে পারেন। এই পতাকাটি OTA আপডেটের সময় ডিভাইসে যাচাইয়ের গণনা অক্ষম করে। এটি OTA ইনস্টলেশনের সময় হ্রাস করে, কিন্তু OTA প্যাকেজের আকার বাড়ায়। যদি আপনার ডিভাইসে dm-verity সক্ষম না থাকে, তাহলে এই পতাকা পাস করার কোনো প্রভাব নেই।
সামঞ্জস্যপূর্ণ নির্মাণ সরঞ্জাম
সমস্যা: যে সরঞ্জামগুলি ইনস্টল করা ফাইলগুলি তৈরি করে তা অবশ্যই সামঞ্জস্যপূর্ণ হতে হবে (একটি প্রদত্ত ইনপুট সর্বদা একই আউটপুট তৈরি করা উচিত)।
সমাধান/উদাহরণ: নিম্নলিখিত বিল্ড টুলগুলিতে পরিবর্তন প্রয়োজন ছিল:
- নোটিশ ফাইল নির্মাতা । পুনরুত্পাদনযোগ্য NOTICE সংগ্রহ তৈরি করতে NOTICE ফাইল নির্মাতা পরিবর্তন করা হয়েছে৷ CL দেখুন: https://android.googlesource.com/platform/build/+/8ae4984c2c8009e7a08e2a76b1762c2837ad4f64 ।
- জাভা অ্যান্ড্রয়েড কম্পাইলার কিট (জ্যাক) । জেনারেট কনস্ট্রাক্টর অর্ডারিংয়ে মাঝে মাঝে পরিবর্তনগুলি পরিচালনা করার জন্য জ্যাক টুলচেইনের একটি আপডেট প্রয়োজন। কনস্ট্রাক্টরদের জন্য ডিটারমিনিস্টিক অ্যাক্সেসরগুলি টুলচেইনে যোগ করা হয়েছে: https://android.googlesource.com/toolchain/jack/+/056a5425b3ef57935206c19ecb198a89221ca64b ।
- ART AOT কম্পাইলার (dex2oat) । ART কম্পাইলার বাইনারি একটি আপডেট পেয়েছে যা একটি নির্ধারক চিত্র তৈরি করার বিকল্প যোগ করেছে: https://android.googlesource.com/platform/art/+/ace0dc1dd5480ad458e622085e51583653853fb9 ।
- libpac.so ফাইল (V8) । প্রতিটি বিল্ড একটি আলাদা
/system/lib/libpac.so
ফাইল তৈরি করে কারণ প্রতিটি বিল্ডের জন্য V8 স্ন্যাপশট পরিবর্তন হয়। সমাধানটি ছিল স্ন্যাপশটটি সরানো: https://android.googlesource.com/platform/external/v8/+/e537f38c36600fd0f3026adba6b3f4cbcee1fb29 । - অ্যাপ্লিকেশন প্রি-ডেক্সপট (.odex) ফাইল । প্রি-ডেক্সোপ্ট (.odex) ফাইলে 64-বিট সিস্টেমে অপ্রচলিত প্যাডিং থাকে। এটি সংশোধন করা হয়েছে: https://android.googlesource.com/platform/art/+/34ed3afc41820c72a3c0ab9770be66b6668aa029 ।
বিল্ড ডিফ টুল ব্যবহার করুন
যে ক্ষেত্রে বিল্ড-সম্পর্কিত ফাইল পরিবর্তনগুলি দূর করা সম্ভব নয়, AOSP-এ দুটি ফাইল প্যাকেজ তুলনা করার জন্য একটি বিল্ড ডিফ টুল, target_files_diff.py
অন্তর্ভুক্ত রয়েছে। এই টুলটি দুটি বিল্ডের মধ্যে একটি পুনরাবৃত্ত পার্থক্য সম্পাদন করে, সাধারণ বিল্ড-সম্পর্কিত ফাইল পরিবর্তনগুলি বাদ দিয়ে, যেমন
- বিল্ড আউটপুটে প্রত্যাশিত পরিবর্তন (উদাহরণস্বরূপ, বিল্ড নম্বর পরিবর্তনের কারণে)।
- বর্তমান বিল্ড সিস্টেমে পরিচিত সমস্যার কারণে পরিবর্তন।
বিল্ড ডিফ টুল ব্যবহার করতে, নিম্নলিখিত কমান্ডটি চালান:
target_files_diff.py dir1 dir2
dir1
এবং dir2
হল বেস ডিরেক্টরি যাতে প্রতিটি বিল্ডের জন্য নিষ্কাশিত টার্গেট ফাইল থাকে।
ব্লক বরাদ্দ সামঞ্জস্য রাখুন
একটি প্রদত্ত ফাইলের জন্য, যদিও এর বিষয়বস্তু দুটি বিল্ডের মধ্যে একই থাকে, প্রকৃত ব্লকগুলি যা ডেটা ধারণ করে তা পরিবর্তিত হতে পারে। ফলস্বরূপ, OTA আপডেটের জন্য ব্লকগুলিকে চারপাশে সরানোর জন্য আপডেটারকে অবশ্যই অপ্রয়োজনীয় I/O করতে হবে।
একটি ভার্চুয়াল A/B OTA আপডেটে, অপ্রয়োজনীয় I/O কপি-অন-রাইট স্ন্যাপশট সংরক্ষণ করার জন্য প্রয়োজনীয় স্টোরেজ স্পেসকে ব্যাপকভাবে বৃদ্ধি করতে পারে। একটি নন-এ/বি ওটিএ আপডেটে, একটি OTA আপডেটের জন্য ব্লকগুলিকে চারপাশে সরিয়ে নেওয়ার সময় আপডেট করতে অবদান রাখে কারণ ব্লক মুভের কারণে আরও I/O আছে।
এই সমস্যাটির সমাধান করার জন্য, Android 7.0-এ Google বিল্ড জুড়ে ব্লক বরাদ্দ সামঞ্জস্য রাখার জন্য make_ext4fs
টুল প্রসারিত করেছে। make_ext4fs
টুল একটি ঐচ্ছিক -d base_fs
পতাকা গ্রহণ করে যা একটি ext4
ইমেজ তৈরি করার সময় একই ব্লকে ফাইল বরাদ্দ করার চেষ্টা করে। আপনি পূর্ববর্তী বিল্ডের টার্গেট ফাইলের জিপ ফাইল থেকে ব্লক ম্যাপিং ফাইল (যেমন base_fs
ম্যাপ ফাইল) বের করতে পারেন। প্রতিটি ext4
পার্টিশনের জন্য, IMAGES
ডিরেক্টরিতে একটি .map
ফাইল থাকে (উদাহরণস্বরূপ, IMAGES/system.map
system
পার্টিশনের সাথে মিলে যায়)। এই base_fs
ফাইলগুলিকে তারপর চেক-ইন করা যেতে পারে এবং PRODUCT_<partition>_BASE_FS_PATH
এর মাধ্যমে নির্দিষ্ট করা যেতে পারে, যেমন এই উদাহরণে:
PRODUCT_SYSTEM_BASE_FS_PATH := path/to/base_fs_files/base_system.map PRODUCT_SYSTEM_EXT_BASE_FS_PATH := path/to/base_fs_files/base_system_ext.map PRODUCT_VENDOR_BASE_FS_PATH := path/to/base_fs_files/base_vendor.map PRODUCT_PRODUCT_BASE_FS_PATH := path/to/base_fs_files/base_product.map PRODUCT_ODM_BASE_FS_PATH := path/to/base_fs_files/base_odm.map
যদিও এটি সামগ্রিক OTA প্যাকেজের আকার কমাতে সাহায্য করে না, এটি I/O-এর পরিমাণ কমিয়ে OTA আপডেট কর্মক্ষমতা উন্নত করে। ভার্চুয়াল A/B আপডেটের জন্য, এটি OTA প্রয়োগ করার জন্য প্রয়োজনীয় স্টোরেজ স্পেসের পরিমাণকে ব্যাপকভাবে হ্রাস করে।
অ্যাপ আপডেট করা এড়িয়ে চলুন
বিল্ড ডিফ কমানোর পাশাপাশি, অ্যাপ স্টোরের মাধ্যমে আপডেট পাওয়া অ্যাপগুলির আপডেটগুলি বাদ দিয়ে আপনি OTA আপডেটের আকার কমাতে পারেন। APK প্রায়ই একটি ডিভাইসে বিভিন্ন পার্টিশনের একটি উল্লেখযোগ্য অংশ নিয়ে থাকে। একটি OTA আপডেটে অ্যাপ স্টোরগুলি দ্বারা আপডেট হওয়া অ্যাপগুলির সর্বশেষ সংস্করণগুলি সহ OTA প্যাকেজগুলির উপর একটি বড় আকারের প্রভাব থাকতে পারে এবং ব্যবহারকারীর সামান্য সুবিধা প্রদান করতে পারে। ব্যবহারকারীরা একটি OTA প্যাকেজ পাওয়ার সময়, তাদের কাছে ইতিমধ্যেই আপডেটেড অ্যাপ থাকতে পারে, অথবা একটি এমনকি নতুন সংস্করণ, সরাসরি অ্যাপ স্টোর থেকে প্রাপ্ত হতে পারে।