نام (NAME)

apk-v3 - فرمت بسته APK نسخه ۳ در پکیجمنیجر Alpine

توضیحات (DESCRIPTION)

یک فایل .apk نسخه ۳ شامل محتویات یک بسته واحد، مقداری متادیتا و چند امضا است. فایل .apk شامل درختی از اشیاء است که در یک قالب باینری سفارشی نمایش داده شده و در مجموع با یک طرح‌واره (schema) از پیش تعریف‌شده مطابقت دارد. این فرمت فایل در درون apk(5) تحت عنوان adb نامیده می‌شود.

قالب داده روی سیم (WIRE FORMAT)

یک فایل apk نسخه ۳ از دنباله‌هایی از مقادیر سریال‌شده تشکیل شده است که هر یک از آن‌ها با یک کلمه ۳۲ بیتی little-endian شروع می‌شود که همان برچسب (tag) مقدار است. ۴ بیت پرارزش برچسب، کد نوع داده (type code) هستند و ۲۸ بیت کم‌ارزش برای یک مقدار بی‌واسطه (immediate value) استفاده می‌شوند. کدهای نوع داده تعریف‌شده عبارتند از:

یک مقدار مستقیم (direct) در ۲۸ بیت کم‌ارزش کلمه برچسب بسته‌بندی می‌شود؛ در مقابل، یک مقدار غیرمستقیم (indirect) در جای دیگری از فایل ذخیره شده و آفست (offset) آن مقدار غیرمستقیم در ۲۸ بیت کم‌ارزش کلمه برچسب قرار می‌گیرد.

آرایه‌ها و اشیاء با دنباله‌ای از اسلات‌های شماره‌گذاری‌شده نمایش داده می‌شوند؛ مقداری که درون کلمه برچسب آن‌ها بسته‌بندی می‌شود، آفستی است که این دنباله از آنجا شروع می‌شود. اولین اسلات همیشه تعداد کل اسلات‌ها است، بنابراین تمام آرایه‌ها و اشیاء حداقل حاوی یک مورد هستند.

تنها تفاوت واقعی میان آرایه‌ها و اشیاء در کدگذاری داده‌های سیم (wire encoding) این است که آرایه‌ها همگن (homogenous) هستند، در حالی که اشیاء ناهمگن (heterogeneous) بوده و برای هر اسلات یک نوع داده مشخص و مجزا دارند.

نوع ویژه (special) برای نمایش سه اتم استفاده می‌شود:

طرح‌واره‌های فایل (FILE SCHEMAS)

طرح‌واره (schema) نمایشی از این است که چه عناصر داده‌ای در یک فایل adb انتظار می‌روند. طرح‌واره‌ها درختی را تشکیل می‌دهند که گره‌های آن یا طرح‌واره‌های اسکالر (که برگ‌های درخت هستند) می‌باشند یا طرح‌واره‌های آرایه/شیء که خود دارای فرزند هستند. برای نمونه، طرح‌واره برای یک شیء بسته (package object) ممکن است اعلام کند که حاوی فیلدهایی است که خود با طرح‌واره آرایه رشته‌ای (string array)، طرح‌واره pkginfo یا موارد مشابه مطابقت دارند.

خود طرح‌واره‌ها به هیچ عنوان در داخل فایل adb نمایش داده نمی‌شوند؛ آن‌ها در بخش‌هایی از apk(1) وجود دارند که چنین فایل‌هایی را خوانده و می‌نویسند. توضیح کامل تمام طرح‌واره‌های apk بسیار طولانی خواهد بود، اما به عنوان مثال، در اینجا طرح‌واره یک فایل منفرد درون یک بسته آورده شده است:

در اینجا، تمام فیلدها به جز "acl" اسکالر هستند، و خود acl یک طرح‌واره است که به این صورت می‌باشد:

بلوک‌ها (BLOCKS)

یک فایل adb واقعی از دنباله‌ای از بلوک‌های نوع‌دار (typed blocks) تشکیل شده است؛ هر بلوک نیز با یک کلمه برچسب ۳۲ بیتی little-endian آغاز می‌شود که دارای ۲ بیت نوع و ۳۰ بیت اندازه است. دو بیت نوع عبارتند از:

فایل adb باید با یک بلوک ADB آغاز شود، سپس به صورت اختیاری یک یا چند بلوک SIG و در ادامه یک یا چند بلوک DATA قرار گیرد. بلوک ADB باید با یک عدد جادویی (magic number) شروع شود که نشان‌دهنده طرح‌واره شیء ریشه کل بلوک ADB است. همچنین بلوک ADB در خارج از شیء ریشه، حاوی مقداری متادیتا است که نسخه فرمت adb مورد استفاده را توصیف می‌کند.

بلوک SIG حاوی یک یا چند امضا از بلوک ADB است. امضاهای متعلق به یک نسخه مشابه باید در همان بلوک SIG قرار گیرند. اگر در آینده نسخه جدیدی از امضا مشخص شود، و بسته بنا به دلایل سازگاری در دوره گذار نیاز به داشتن دو نسخه متفاوت از امضا داشته باشد، آنگاه باید دو بلوک امضا وجود داشته باشد، یکی برای هر نسخه.

برخلاف فرمت نسخه ۲، نام کلید استفاده‌شده برای امضا به طور صریح مشخص نمی‌شود. در عوض از شناسه ذاتی (intrinsic ID) کلید برای جستجو استفاده می‌شود، بنابراین اعتبارسنج‌ها باید کلید را بر اساس شناسه کلید پیدا کنند. همچنین برخلاف فرمت نسخه ۲، بلوک ADB به طور مستقیم امضا نمی‌شود، بلکه ابتدا توسط یک خلاصه‌ساز امن (در حال حاضر SHA512) هش می‌شود. پس از این، یک محموله (payload) کوچک حاوی این هش از پیش محاسبه‌شده توسط الگوریتم مشخص‌شده امضا می‌شود (معمولاً این محموله سپس در طول فرآیند امضا دوباره با یک دایجست امن بر اساس الگوریتم امضا هش می‌شود).

بلوک‌های DATA تنها برای ذخیره داده‌های فایل بسته استفاده می‌شوند؛ تمام متادیتای فایل، از جمله هش‌های محتوا، در عوض در بلوک ADB ذخیره می‌شوند. بنابراین محتویات بلوک‌های DATA توسط هش‌های ارائه‌شده در بلوک ADB محافظت می‌شوند، که خود آن نیز توسط امضا در بلوک SIG محافظت می‌شود.

در حال حاضر ظاهر شدن یک بلوک DATAX غیرمجاز است.

نکات (NOTES)

فرمت فایل نسخه ۳ با چیدمان ساختارهای زبان C در حافظه (C struct layout) درهم‌تنیده است، زیرا گاهی اوقات مستقیماً استراکت‌ها را در بخش adb می‌نویسد، از جمله هرگونه فاصله‌گذاری (padding) اضافه‌شده توسط کامپایلر و مواردی از این دست.

همچنین ببینید (SEE ALSO)

abuild(1), apk(8), apk-package(5), apk-v2(5)