نام و آیکون را کنار بگذارید؛ سه لایه ای که هویت واقعی یک APK را می سازند

این موضوع فقط برای توسعه دهنده ای که خروجی می سازد مهم نیست. خطای «برنامه نصب نشد»، امکان نصب هم زمان دو کلاینت و تغییر ناگهانی مجوزها همگی به همین لایه ها مربوط می شوند. شناخت آنها کمک می کند پیش از اجرای فایل، سوال های دقیق تری بپرسیم.

لایه اول: Package Name یا شناسنامه برنامه

نام بسته رشته ای مانند com.example.app است که اندروید از آن برای تشخیص برنامه استفاده می کند. این شناسه معمولا در رابط کاربر دیده نمی شود، اما در نصب، ذخیره داده، مجوزها و ارتباط با فروشگاه نقش اصلی دارد. اگر دو APK نام بسته متفاوت داشته باشند، در بسیاری از موارد می توانند کنار هم نصب شوند؛ حتی اگر نام نمایشی و آیکون یکسانی داشته باشند.

اگر نام بسته یکسان باشد، اندروید فایل جدید را نامزد به روزرسانی برنامه موجود می داند. اینجا لایه دوم وارد می شود: امضا باید با نسخه نصب شده سازگار باشد. به همین دلیل تغییر نام بسته راهی برای ساخت نسخه موازی است، اما هزینه دارد؛ داده و تنظیمات آن برنامه از نسخه اصلی جدا خواهند بود.

versionName و versionCode یک چیز نیستند

versionName همان عدد یا عبارتی است که کاربر می بیند؛ مثلا ۱۲.۱. توسعه دهنده می تواند قالب آن را تقریبا آزادانه انتخاب کند. versionCode عدد داخلی برای ترتیب نسخه هاست. سیستم عامل و فروشگاه از این عدد می فهمند کدام خروجی جدیدتر است.

ممکن است versionName ظاهرا بزرگ تر باشد، اما versionCode مسیر منطقی نداشته باشد. برای بررسی به روزرسانی فقط به متن روی صفحه دانلود اکتفا نکنید. بسته باید از نظر شناسه، امضا و کد نسخه با مسیر قبلی سازگار باشد.

دیدن اطلاعات بسته با ابزارهای Android SDK

اگر Build Tools اندروید نصب است، دستور aapt اطلاعات پایه را بدون اجرای برنامه نشان می دهد:

aapt dump badging sample.apk

در خروجی می توان نام بسته، کد و نام نسخه، حداقل نسخه اندروید، معماری و برخی قابلیت های اعلام شده را دید. ابزار apkanalyzer نیز برای مرور مانیفست و اجزای بسته مناسب است:

apkanalyzer manifest print sample.apk

این بررسی ایستا است؛ فایل را نصب یا کد آن را اجرا نمی کند. با این حال، ایستا بودن به معنی امن بودن کامل تحلیل نیست. فایل ناشناس را در پوشه جدا نگه دارید و ابزارهای خود را به روز نگه دارید.

لایه دوم: امضای دیجیتال و زنجیره به روزرسانی

هر APK قابل نصب باید امضا شود. امضا به اندروید اجازه می دهد تشخیص دهد نسخه جدید با همان هویت رمزنگاری قبلی ارائه شده یا نه. اگر نام بسته برابر اما گواهی متفاوت باشد، سیستم معمولا اجازه نمی دهد فایل جدید روی نسخه موجود نصب شود. این همان خطای تداخل امضاست که کاربر گاهی با حذف نسخه قبلی دور می زند.

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

برای نمایش گواهی می توان از ابزار زیر استفاده کرد:

apksigner verify --print-certs sample.apk

خروجی شامل اثر انگشت های گواهی امضاکننده است. این مقادیر را باید با نسخه مرجع مقایسه کرد. هش کل فایل و اثر انگشت گواهی دو چیز متفاوت اند: اولی تمام بایت های APK را می سنجد؛ دومی هویت کلیدی را که فایل با آن امضا شده نشان می دهد.

لایه سوم: مانیفست و سطح دسترسی

فایل AndroidManifest فهرست اجزای برنامه، مجوزها، سرویس ها، گیرنده ها و حداقل نسخه سیستم عامل را تعریف می کند. مجوز اعلام شده لزوما به معنی سوءاستفاده نیست؛ باید با کارکرد برنامه سنجیده شود. پیام رسان برای اعلان، دوربین یا انتخاب فایل ممکن است مجوز مرتبط بخواهد. اما اضافه شدن دسترسی تازه در به روزرسانی، بدون توضیح قابلیت متناظر، ارزش بررسی دارد.

فهرست مجوزها را می توان چنین دید:

apkanalyzer manifest permissions sample.apk

اندروید جدید برخی مجوزهای حساس را هنگام استفاده از کاربر می پرسد، اما همه رفتارها در پنجره نصب خلاصه نمی شوند. سرویس های پس زمینه، مقصدهای شبکه و کتابخانه های ثالث نیازمند تحلیل عمیق تری هستند.

یک جدول برای جدا کردن نشانه ها

نشانه	چه چیزی می گوید؟	چه چیزی را ثابت نمی کند؟
نام نمایشی	عنوانی که کاربر می بیند	هویت فنی سازنده
Package Name	شناسه برنامه نزد اندروید	امن بودن کد
هش SHA-256 فایل	یکسان بودن دقیق فایل	معتبر بودن منبع اولیه
گواهی امضا	تداوم کلید امضاکننده	بی نقص بودن رفتار برنامه
مجوزها	بخشی از دسترسی های درخواستی	تمام مقصدهای ارسال داده

چرا دو نسخه یک پیام رسان کنار هم نصب می شوند؟

کلاینت های مختلف تلگرام معمولا نام بسته متفاوتی دارند؛ بنابراین اندروید آنها را برنامه های جدا می بیند. هر کدام فضای داده، کش و تنظیمات خود را دارد. نشست حساب در سطح سرویس تلگرام همگام می شود، اما فایل های محلی، تنظیمات رابط و برخی پوشه ها مستقل می مانند.

پیش از نصب فایل های مختلف، بهتر است مسیر درست را از یک  راهنمای نصب APK روی اندروید  مرور کرد. فعال کردن اجازه نصب برای منبع ناشناس، فقط یک مرحله فنی است؛ این اجازه هیچ داوری درباره سلامت فایل انجام نمی دهد.

تحلیل ایستا کجا کم می آورد؟

بدافزار می تواند کد را مبهم کند، بخش هایی را بعدا از شبکه بگیرد یا رفتار خود را بر اساس محیط تغییر دهد. در نتیجه package name درست، امضای ثابت و مجوزهای ظاهرا منطقی برای صدور حکم کافی نیستند. تحلیل شبکه، بررسی کتابخانه ها، اجرای کنترل شده و سابقه سازنده تصویر کامل تری می دهند.

برای کاربر عمومی، سطح تحلیل باید با ارزش حساب متناسب باشد. اگر حساب به اطلاعات کاری یا مدیریت کانال مهم وصل است، انتخاب نسخه رسمی و مسیر رسمی دریافت ساده ترین راه کاهش سطح عدم قطعیت است. صفحه  تلگرام رسمی  می تواند نقطه شروع مقایسه با نسخه های دیگر باشد.

حریم خصوصی بعد از نصب شروع نمی شود

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

هویت واقعی در جزئیات پنهان نیست؛ در جزئیات تعریف شده است

نام و آیکون برای انسان طراحی شده اند، اما اندروید با شناسه بسته، کد نسخه و گواهی کار می کند. توسعه دهنده یا کاربر فنی که این سه لایه را می بیند، خطای نصب را بهتر توضیح می دهد و در برابر فایل های هم نام کمتر فریب می خورد. بررسی فنی تضمین مطلق نمی سازد، اما تصمیم را از حدس ظاهری به شواهد قابل مقایسه منتقل می کند.