مانند نسخه‌های قبلی، Android 12 شامل تغییرات رفتاری است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات رفتاری زیر منحصراً برای برنامه‌هایی اعمال می‌شود که Android 12 یا بالاتر را هدف قرار می‌دهند. اگر برنامه‌تان Android نسخه ۱۲ را هدف قرار می‌دهد، باید برنامه‌تان را اصلاح کنید تا درصورت لزوم از این رفتارها به‌درستی پشتیبانی کند.
حتماً فهرست تغییرات رفتاری را که بر همه برنامه‌های درحال اجرا در Android 12 تأثیر می‌گذارد مرور کنید.
تجربه کاربری
اعلان‌های سفارشی
Android 12 ظاهر و رفتار اعلان‌های کاملاً سفارشی را تغییر می‌دهد. قبلاً، اعلان‌های سفارشی می‌توانستند از کل ناحیه اعلان استفاده کنند و چیدمان‌ها و سبک‌های خودشان را ارائه دهند. این امر منجر به الگوهای نامناسبی می‌شد که می‌توانست کاربران را سردرگم کند یا باعث مشکلات سازگاری چیدمان در دستگاه‌های مختلف شود.
برای برنامه‌هایی که Android 12 را هدف قرار می‌دهند، اعلان‌های دارای نماهای محتوای سفارشی دیگر از کل ناحیه اعلان استفاده نخواهند کرد؛ درعوض، سیستم الگوی استانداردی را اعمال می‌کند. این الگو تضمین می‌کند که اعلان‌های سفارشی در همه حالت‌ها، مانند نماد اعلان و امکانات گسترش (در حالت جمع‌شده) و نماد اعلان، نام برنامه، و امکانات جمع کردن (در حالت گسترش‌یافته)، همان تزئینات سایر اعلان‌ها را داشته باشند. این رفتار
تقریباً مشابه رفتار
Notification.DecoratedCustomViewStyle است.
به این ترتیب، Android 12 همه اعلان‌ها را ازنظر بصری سازگار و آسان برای اسکن می‌کند، با گسترش اعلان قابل‌شناسایی و آشنا برای کاربران.
تصویر زیر اعلان سفارشی را در الگوی استاندارد نشان می‌دهد:
مثال‌های زیر نشان می‌دهد که اعلان‌های سفارشی چگونه در حالت جمع‌شده و ازهم‌بازشده ارائه می‌شوند:
تغییر در Android 12 بر برنامه‌هایی تأثیر می‌گذارد که زیرکلاس‌های سفارشی
Notification.Style را تعریف می‌کنند، یا از روش‌های
Notification.Builder
setCustomContentView(RemoteViews)،
setCustomBigContentView(RemoteViews)،
و setCustomHeadsUpContentView(RemoteViews) استفاده می‌کنند.
اگر برنامه‌تان از اعلان‌های کاملاً سفارشی استفاده می‌کند، توصیه می‌کنیم در اسرع وقت با الگوی جدید آزمایش کنید.
تغییر اعلان‌های سفارشی را فعال کنید:
targetSdkVersionبرنامه‌تان را بهSتغییر دهید تا رفتار جدید فعال شود.- بازهمگردانی کردن.
- برنامه‌تان را در دستگاه یا شبیه‌سازی که Android 12 را اجرا می‌کند نصب کنید.
همه اعلان‌هایی را که از نماهای سفارشی استفاده می‌کنند آزمایش کنید و مطمئن شوید که در سایه همان‌طور که انتظار دارید به‌نظر می‌رسند. هنگام آزمایش، این ملاحظات را درنظر بگیرید و اصلاحات لازم را انجام دهید:
ابعاد نماهای سفارشی تغییر کرده است. به‌طور کلی، ارتفاعی که برای اعلان‌های سفارشی درنظر گرفته شده است کمتر از قبل است. در حالت جمع‌شده، حداکثر ارتفاع محتوای سفارشی از ۱۰۶dp به ۴۸dp کاهش یافته است. همچنین، فضای افقی کمتری وجود دارد.
همه اعلان‌ها برای برنامه‌هایی که Android 12 را هدف‌یابی می‌کنند قابل‌گسترش هستند. معمولاً این یعنی اگر از
setCustomContentViewاستفاده می‌کنید، باید ازsetBigCustomContentViewنیز استفاده کنید تا مطمئن شوید حالت‌های جمع‌شده و ازهم بازشده سازگار هستند.برای اطمینان از اینکه وضعیت «هشدار» همان‌طور که انتظار دارید به‌نظر می‌رسد، فراموش نکنید که اهمیت کانال اعلان را به «بالا» (نمایش ناگهانی در صفحه) افزایش دهید.
تغییرات درستی‌سنجی «پیوندهای برنامه Android»
در برنامه‌هایی که Android نسخه ۱۲ یا بالاتر را هدف‌یابی می‌کنند، سیستم تغییرات متعددی در نحوه درستی‌سنجی «پیوندهای برنامه Android» ایجاد می‌کند. این تغییرات قابلیت اطمینان تجربه پیونددهی برنامه را بهبود می‌بخشد و کنترل بیشتری به توسعه‌دهندگان برنامه و کاربران نهایی می‌دهد.
اگر برای باز کردن پیوندهای وب در برنامه‌تان به درستی‌سنجی «پیوند برنامه Android» متکی هستید،
بررسی کنید که هنگام افزودن فیلترهای قصد برای
درستی‌سنجی «پیوند برنامه Android»، از قالب صحیح استفاده کنید. به‌ویژه، مطمئن شوید که این فیلترهای قصد
شامل دسته BROWSABLE باشند و از طرح https پشتیبانی کنند.
همچنین می‌توانید پیوندهای برنامه‌تان را به‌صورت دستی درستی‌سنجی کنید تا قابلیت اطمینان اظهارنامه‌هایتان را آزمایش کنید.
بهبودهای رفتار تصویردرتصویر
Android 12 بهبودهای رفتاری را برای حالت تصویردرتصویر (PiP) معرفی می‌کند، و بهبودهای ظاهری توصیه‌شده برای پویانمایی‌های انتقال برای هر دو پیمایش اشاره‌ای و پیمایش مبتنی بر عنصر.
برای اطلاعات بیشتر، به بهبودهای تصویردرتصویر مراجعه کنید.
بازطراحی Toast
در Android 12، نمای اعلان موقت بازطراحی شده است. اکنون پیام‌های موقت به دو خط نوشتار محدود شده‌اند و نماد برنامه را در کنار نوشتار نشان می‌دهند.
برای جزئیات بیشتر، به نمای کلی اعلان‌های گذرا مراجعه کنید.
امنیت و حریم خصوصی
مکان تقریبی
در دستگاه‌هایی که Android نسخه ۱۲ یا بالاتر دارند، کاربران می‌توانند دقت مکان تقریبی را برای برنامه‌تان درخواست کنند.
کوکی‌های SameSite مدرن در WebView
مؤلفه WebView در Android براساس Chromium است،
پروژه متن‌بازی که مرورگر Chrome متعلق به Google را تقویت می‌کند. Chromium تغییراتی را در نحوه مدیریت کوکی‌های طرف سوم معرفی کرده است تا امنیت و حریم خصوصی بیشتری فراهم کند و شفافیت و کنترل بیشتری به کاربران ارائه دهد. از Android نسخه ۱۲،
این تغییرات در WebView نیز گنجانده شده است، وقتی برنامه‌ها
Android نسخه ۱۲ (سطح میانای برنامه‌سازی کاربردی ۳۱) یا بالاتر را هدف قرار می‌دهند.
مشخصه SameSite کوکی کنترل می‌کند که آیا کوکی می‌تواند با هر درخواستی ارسال شود یا فقط با درخواست‌های همان سایت. تغییرات زیر در زمینه محافظت از حریم خصوصی، مدیریت پیش‌فرض کوکی‌های طرف سوم را بهبود می‌بخشد و به محافظت دربرابر هم‌رسانی ناخواسته بین‌سایتی کمک می‌کند:
- کوکی‌های بدون شاخصه
SameSiteبه‌عنوانSameSite=Laxدرنظر گرفته می‌شوند. - کوکی‌های دارای
SameSite=Noneباید مشخصهSecureرا نیز مشخص کنند، یعنی به بافت امن نیاز دارند و باید ازطریق HTTPS ارسال شوند. - پیوندهای بین نسخه‌های HTTP و HTTPS یک سایت اکنون به‌عنوان درخواست‌های بین‌سایتی درنظر گرفته می‌شوند، بنابراین کوکی‌ها ارسال نمی‌شوند مگراینکه به‌درستی به‌عنوان
SameSite=None; Secureعلامت‌گذاری شده باشند.
برای توسعه‌دهندگان، راهنمایی کلی این است که وابستگی‌های کوکی بین‌سایتی را در جریان‌های کاربر حیاتی خود شناسایی کنند و مطمئن شوند که ویژگی SameSite به‌طور صریح با مقادیر مناسب در جاهایی که لازم است تنظیم شده باشد. باید
کوکی‌هایی را که مجاز به کار در وب‌سایت‌ها یا
در پیمایش‌های همان سایت که از HTTP به HTTPS منتقل می‌شوند هستند به‌طور صریح مشخص کنید.
برای راهنمایی کامل توسعه‌دهندگان وب درباره این تغییرات، به توضیح کوکی‌های SameSite و Schemeful SameSite مراجعه کنید.
آزمایش رفتارهای SameSite در برنامه
اگر برنامه‌تان از WebView استفاده می‌کند، یا اگر وب‌سایت یا سرویسی را مدیریت می‌کنید که از کوکی‌ها استفاده می‌کند، توصیه می‌کنیم جریان‌هایتان را در WebView در Android 12 آزمایش کنید. اگر مشکلی پیدا کردید، ممکن است لازم باشد کوکی‌هایتان را به‌روز کنید تا از رفتارهای جدید SameSite پشتیبانی کند.
مراقب مشکلات مربوط به ورود به سیستم و محتوای جاسازی‌شده، و همچنین جریان‌های ورود به سیستم، خرید، و سایر جریان‌های اصالت‌سنجی که کاربر از یک صفحه ناامن شروع می‌کند و به یک صفحه امن منتقل می‌شود باشید.
برای آزمایش کردن برنامه با «وب‌نما»، باید با تکمیل یکی از مراحل زیر، رفتارهای SameSite جدید را برای برنامه‌ای که می‌خواهید آزمایش کنید فعال کنید:
با تغییر وضعیت پرچم واسط کاربر webview-enable-modern-cookie-same-site در ابزارهای توسعه WebView، رفتارهای SameSite را به‌صورت دستی در دستگاه آزمایشی فعال کنید.
این رویکرد به شما امکان می‌دهد در هر دستگاهی که Android نسخه ۵.۰ (سطح میانای برنامه‌سازی کاربردی ۲۱) یا بالاتر (ازجمله Android نسخه ۱۲) و WebView نسخه ۸۹.۰.۴۳۸۵.۰ یا بالاتر دارد آزمایش کنید.
برنامه‌تان را تا
targetSdkVersionبرای هدف‌یابی Android 12 (سطح میانای برنامه‌سازی کاربردی ۳۱) کامپایل کنید.اگر از این رویکرد استفاده می‌کنید، باید از دستگاهی استفاده کنید که Android 12 را اجرا می‌کند.
برای اطلاعات درباره اشکال‌زدایی از راه دور برای WebView در Android، به شروع به کار با اشکال‌زدایی از راه دور دستگاه‌های Android مراجعه کنید.
منابع دیگر
برای اطلاعات بیشتر درباره رفتارهای مدرن SameSite و عرضه آن در Chrome و WebView، به صفحه به‌روزرسانی‌های Chromium SameSite مراجعه کنید. اگر اشکالی در WebView یا Chromium پیدا کردید، می‌توانید آن را در ردیاب مشکل Chromium عمومی گزارش کنید.
حسگرهای حرکتی محدودیت نرخ دارند
برای محافظت از اطلاعات بالقوه حساس درباره کاربران، اگر برنامه شما Android 12 یا بالاتر را هدف قرار دهد، سیستم محدودیتی برای نرخ بازآوری داده‌های حسگرهای حرکتی و حسگرهای موقعیت خاص اعمال می‌کند.
درباره محدود کردن نرخ حسگر بیشتر بدانید.
خواب موقت برنامه
Android 12 رفتار بازنشانی خودکار اجازه‌ها را که در Android 11 (سطح میانای برنامه‌سازی کاربردی ۳۰) معرفی شده بود گسترش می‌دهد. اگر برنامه شما Android 12 را هدف قرار دهد و کاربر چند ماه با برنامه شما تعامل نداشته باشد، سیستم به‌طور خودکار همه اجازه‌های اعطاشده را بازنشانی می‌کند و برنامه شما را در وضعیت خواب زمستانی قرار می‌دهد.
در راهنمای خواب موقت برنامه بیشتر بدانید.
اعلام ارجاع در ممیزی دسترسی به داده‌ها
میانای برنامه‌سازی کاربردی ممیزی دسترسی به داده‌ها که در Android 11 (میانای برنامه‌سازی کاربردی سطح ۳۰) معرفی شده است به شما امکان می‌دهد براساس موارد استفاده برنامه‌تان برچسب‌های ارجاع ایجاد کنید. این برچسب‌ها به شما کمک می‌کنند راحت‌تر تعیین کنید کدام بخش از برنامه‌تان نوع خاصی از دسترسی به داده را انجام می‌دهد.
اگر برنامه شما Android نسخه ۱۲ یا بالاتر را هدف قرار می‌دهد، باید این برچسب‌های ارجاع را در فایل مانیفست برنامه‌تان اعلام کنید.
محدودیت پشتیبان‌گیری ADB
برای کمک به محافظت از داده‌های خصوصی برنامه، Android 12 رفتار پیش‌فرض فرمان
adb backup را تغییر می‌دهد. برای برنامه‌هایی که Android 12 (سطح میانای برنامه‌سازی کاربردی ۳۱) یا بالاتر را هدف قرار می‌دهند،
وقتی کاربر فرمان adb backup را اجرا می‌کند، داده‌های برنامه از هر داده سیستم دیگری
که از دستگاه صادر می‌شود مستثنی می‌شود.
اگر گردش‌های کاری آزمایشی یا توسعه شما به داده‌های برنامه بااستفاده از adb backup متکی است،
اکنون می‌توانید با تنظیم کردن
android:debuggable
روی true در فایل مانیفست برنامه‌تان،
با صادر کردن داده‌های برنامه‌تان موافقت کنید.
صادر کردن ایمن‌تر مؤلفه
اگر برنامه شما Android نسخه ۱۲ یا بالاتر را هدف‌یابی می‌کند و حاوی
فعالیت‌ها،
سرویس‌ها، یا گیرنده‌های
رویداد ثبت‌شده است که از فیلترهای
قصد استفاده می‌کنند، باید به‌طور صریح
ویژگی
android:exported را
برای این مؤلفه‌های برنامه اعلام کنید.
اگر مؤلفه برنامه شامل دسته
LAUNCHER است،
android:exported را روی true تنظیم کنید. در اکثر موارد دیگر، android:exported را روی
false تنظیم کنید.
تکه‌کد زیر نمونه‌ای از سرویسی را نشان می‌دهد که حاوی فیلتر قصدی است که ویژگی android:exported آن روی false تنظیم شده است:
<service android:name="com.example.app.backgroundService" android:exported="false"> <intent-filter> <action android:name="com.example.app.START_BACKGROUND" /> </intent-filter> </service>
پیام‌ها در «استودیو Android»
اگر برنامه‌تان حاوی فعالیت، سرویس، یا گیرنده رویداد ثبت‌شده‌ای است که از
فیلترهای هدف استفاده می‌کند اما android:exported را اعلام نمی‌کند، بسته به نسخه Android Studio که استفاده می‌کنید،
پیام‌های هشدار زیر ظاهر می‌شود:
Android Studio 2020.3.1 Canary 11 یا بالاتر
پیام‌های زیر نشان داده می‌شود:
هشدار lint زیر در فایل مانیفست شما نشان داده می‌شود:
When using intent filters, please specify android:exported as wellوقتی می‌خواهید برنامه‌تان را کامپایل کنید، پیام خطای ساخت زیر نمایش داده می‌شود:
Manifest merger failed : Apps targeting Android 12 and higher are required \ to specify an explicit value for android:exported when the corresponding \ component has an intent filter defined.
نسخه‌های قدیمی‌تر «استودیو Android»
اگر برای نصب برنامه تلاش کنید، Logcat پیام خطای زیر را نمایش می‌دهد:
Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'
تغییرپذیری اهداف تعلیقی
اگر برنامه شما Android نسخه ۱۲ را هدف قرار می‌دهد، باید تغییرپذیری هر شیء PendingIntent را که برنامه‌تان ایجاد می‌کند مشخص کنید. این الزام اضافی امنیت برنامه‌تان را بهبود می‌بخشد.
تغییر تغییرپذیری قصد معوق را آزمایش کنید
برای تعیین اینکه آیا برنامه شما فاقد اعلامیه‌های تغییرپذیری است، به‌دنبال هشدار lint زیر در Android Studio بگردید:
Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]
راه‌اندازی‌های هدف ناامن
برای بهبود امنیت پلاتفرم، Android 12 و نسخه‌های بالاتر ویژگی اشکال‌زدایی‌ای ارائه می‌دهند که راه‌اندازی‌های ناامن هدف‌ها را شناسایی می‌کند. وقتی سیستم چنین راه‌اندازی ناایمنی را تشخیص دهد، نقض StrictMode رخ می‌دهد.
عملکرد
محدودیت‌های راه‌اندازی سرویس پیش‌زمینه‌ای
برنامه‌هایی که Android نسخه ۱۲ یا بالاتر را هدف قرار می‌دهند نمی‌توانند سرویس‌های پیش‌زمینه‌ای را درحین اجرا در پس‌زمینه شروع کنند، به‌جز چند مورد خاص. اگر برنامه‌ای درحین اجرا در پس‌زمینه تلاش کند سرویس پیش‌زمینه‌ای راه‌اندازی کند، استثنایی رخ می‌دهد (به‌جز چند مورد خاص).
وقتی برنامه‌تان در پس‌زمینه اجرا می‌شود، بهتر است از WorkManager برای زمان‌بندی و شروع وظیفه تسریع‌شده استفاده کنید. برای تکمیل کنش‌های حساس به زمان که کاربر درخواست می‌کند، سرویس‌های پیش‌زمینه‌ای را در زنگ ساعت دقیق شروع کنید.
اجازه هشدار دقیق
برای تشویق برنامه‌ها به حفظ منابع سیستم، برنامه‌هایی که Android نسخه ۱۲ و بالاتر را هدف قرار می‌دهند و زنگ‌های دقیق تنظیم می‌کنند باید به قابلیت «زنگ‌ها و یادآوری‌ها» که در صفحه دسترسی ویژه برنامه در تنظیمات سیستم نشان داده می‌شود دسترسی داشته باشند.
برای دریافت این دسترسی ویژه برنامه، اجازه
SCHEDULE_EXACT_ALARM
را در مانیفست درخواست کنید.
هشدارهای دقیق فقط باید برای ویژگی‌های سَمت کاربر استفاده شود. درباره موارد استفاده قابل‌قبول برای تنظیم زنگ ساعت دقیق بیشتر بدانید.
غیرفعال کردن تغییر رفتار
وقتی برنامه‌تان را برای هدف قرار دادن Android 12 آماده می‌کنید، می‌توانید تغییر رفتار را در تنوع ساخت قابل‌اشکال‌زدایی‌تان به‌طور موقت برای اهداف آزمایشی غیرفعال کنید. برای انجام این کار، یکی از تکالیف زیر را تکمیل کنید:
- در صفحه تنظیمات گزینه‌های توسعه‌دهنده، تغییرات سازگاری برنامه را انتخاب کنید. در صفحه‌ای که ظاهر می‌شود، روی نام برنامه‌تان تک‌ضرب بزنید، سپس REQUIRE_EXACT_ALARM_PERMISSION را خاموش کنید.
در پنجره ترمینال در ماشین توسعه نرم‌افزار، فرمان زیر را اجرا کنید:
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
محدودیت‌های ترامپولین اعلان
وقتی کاربران با اعلان‌ها تعامل می‌کنند، برخی‌از برنامه‌ها با راه‌اندازی مؤلفه برنامه به ضربه زدن روی اعلان پاسخ می‌دهند که درنهایت فعالیتی را شروع می‌کند که کاربر درنهایت می‌بیند و با آن تعامل می‌کند. این مؤلفه برنامه به‌عنوان ترامپولین اعلان شناخته می‌شود.
برای بهبود عملکرد برنامه و تجربه کاربری، برنامه‌هایی که Android ۱۲ یا بالاتر را هدف قرار می‌دهند نمی‌توانند فعالیت‌ها را از سرویس‌ها یا گیرندگان رویداد ثبت‌شده که به‌عنوان ترامپولین اعلان استفاده می‌شوند شروع کنند. به‌عبارت دیگر، پس‌از اینکه کاربر روی اعلانی
یا دکمه کنشی در
اعلان تک‌ضرب می‌زند، برنامه‌تان نمی‌تواند
startActivity()
را در سرویس یا گیرنده رویداد ثبت‌شده فراخوانی کند.
وقتی برنامه‌تان سعی می‌کند فعالیتی را از سرویس یا گیرنده رویداد ثبت‌شده‌ای شروع کند که به‌عنوان ترامپولین اعلان عمل می‌کند، سیستم از شروع فعالیت جلوگیری می‌کند و پیام زیر در Logcat نشان داده می‌شود:
Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.
شناسایی مؤلفه‌های برنامه‌ای که به‌عنوان ترامپولین اعلان عمل می‌کنند
هنگام آزمایش کردن برنامه‌تان، پس‌از تک‌ضرب زدن روی اعلان، می‌توانید تشخیص دهید که کدام سرویس یا گیرنده رویداد ثبت‌شده به‌عنوان ترامپولین اعلان در برنامه‌تان عمل کرده است. برای انجام این کار، به خروجی فرمان پایانه زیر نگاه کنید:
adb shell dumpsys activity service \ com.android.systemui/.dump.SystemUIAuxiliaryDumpService
بخشی از برونداد شامل نوشتار «NotifInteractionLog» است. این بخش حاوی اطلاعاتی است که برای شناسایی مؤلفه‌ای که درنتیجه تک‌ضرب بر اعلان شروع می‌شود ضروری است.
به‌روزرسانی برنامه
اگر برنامه‌تان فعالیتی را از گیرنده رویداد ثبت‌شده یا سرویسی شروع می‌کند که به‌عنوان ترامپولین اعلان عمل می‌کند، مراحل انتقال زیر را تکمیل کنید:
- شیء
PendingIntentایجاد کنید که با فعالیتی مرتبط باشد که کاربران پس‌از تک‌ضرب زدن روی اعلان می‌بینند. - از شیء
PendingIntentکه در مرحله قبلی ایجاد کردید به‌عنوان بخشی از ساختن اعلان استفاده کنید.
برای شناسایی منشأ فعالیت، مثلاً برای انجام ثبت گزارش،
هنگام پست کردن اعلان از موارد اضافی استفاده کنید. برای ثبت متمرکز، از
ActivityLifecycleCallbacks
یا ناظران چرخه حیات Jetpack استفاده کنید.
تغییر وضعیت رفتار
هنگام آزمایش نسخه قابل‌اشکال‌زدایی برنامه‌تان، می‌توانید این محدودیت را بااستفاده از پرچم سازگاری برنامه NOTIFICATION_TRAMPOLINE_BLOCK فعال و غیرفعال کنید.
پشتیبان‌گیری و بازیابی
تغییراتی در نحوه عملکرد پشتیبان‌گیری و بازیابی در برنامه‌هایی که در Android 12 (سطح میانای برنامه‌سازی کاربردی ۳۱) اجرا می‌شوند و آن را هدف قرار می‌دهند ایجاد شده است. پشتیبان‌گیری و بازیابی Android دو شکل دارد:
- پشتیبان‌گیری ابری: داده‌های کاربر در Google Drive کاربر ذخیره می‌شود تا بعداً بتواند در آن دستگاه یا دستگاه جدیدی بازیابی شود.
- انتقال دستگاه به دستگاه (D2D): داده‌های کاربر مستقیماً از دستگاه قدیمی‌تر به دستگاه جدید کاربر ارسال می‌شود، مثلاً بااستفاده از کابل.
برای اطلاعات بیشتر درباره نحوه پشتیبان‌گیری و بازیابی داده‌ها، به پشتیبان‌گیری از داده‌های کاربر با «پشتیبان‌گیری خودکار» و پشتیبان‌گیری از جفت‌های کلید-مقدار با «سرویس پشتیبان‌گیری Android» مراجعه کنید.
تغییرات عملکرد انتقال دستگاه به دستگاه (D2D)
برای برنامه‌هایی که در Android نسخه ۱۲ و بالاتر اجرا می‌شوند و آن را هدف قرار می‌دهند:
مشخص کردن قوانین گنجاندن و مستثنی کردن با سازوکار پیکربندی XML بر انتقال‌های D2D تأثیری ندارد، هرچند همچنان بر پشتیبان‌گیری و بازیابی مبتنی بر ابر (مانند پشتیبان‌گیری‌های Google Drive) تأثیر می‌گذارد. برای مشخص کردن قوانین انتقال‌های D2D، باید از پیکربندی جدیدی که در بخش بعدی توضیح داده شده است استفاده کنید.
در دستگاه‌های برخی‌از سازندگان دستگاه، مشخص کردن
android:allowBackup="false"پشتیبان‌گیری در Google Drive را غیرفعال می‌کند، اما انتقال‌های دستگاه به دستگاه را برای برنامه غیرفعال نمی‌کند.
قالب جدید گنجاندن و کنار گذاشتن
برنامه‌هایی که در Android نسخه ۱۲ و بالاتر اجرا می‌شوند و این نسخه‌ها را هدف‌یابی می‌کنند، از قالب متفاوتی برای پیکربندی XML استفاده می‌کنند. این قالب تفاوت بین پشتیبان‌گیری Google Drive و انتقال D2D را با ملزم کردن شما به مشخص کردن جداگانه قوانین گنجاندن و مستثنی کردن برای پشتیبان‌گیری‌های ابری و انتقال D2D صریح می‌کند.
درصورت تمایل، می‌توانید از آن برای مشخص کردن قوانین پشتیبان‌گیری نیز استفاده کنید که دراین‌صورت، پیکربندی قبلاً استفاده‌شده در دستگاه‌های دارای Android نسخه ۱۲ یا بالاتر نادیده گرفته می‌شود. پیکربندی قدیمی‌تر هنوز برای دستگاه‌های دارای Android نسخه ۱۱ یا پایین‌تر لازم است.
تغییرات قالب XML
قالب زیر برای پیکربندی پشتیبان‌گیری و بازیابی در Android نسخه ۱۱ و پایین‌تر استفاده می‌شود:
<full-backup-content> <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] /> <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" /> </full-backup-content>
موارد زیر تغییرات قالب را به‌صورت پررنگ نشان می‌دهد.
<data-extraction-rules> <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]> ... <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... </cloud-backup> <device-transfer> ... <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string"/> ... </device-transfer> </data-extraction-rules>
برای اطلاعات بیشتر، به بخش مربوطه در راهنمای پشتیبان‌گیری از داده‌های کاربر با «پشتیبان‌گیری خودکار» مراجعه کنید.
پرچم مانیفست برای برنامه‌ها
بااستفاده از مشخصه
android:dataExtractionRules در فایل مانیفست،
برنامه‌هایتان را به پیکربندی XML جدید هدایت کنید. وقتی به پیکربندی XML جدید اشاره می‌کنید،
مشخصه android:fullBackupContent که به پیکربندی قدیمی اشاره می‌کند
در دستگاه‌های دارای Android 12 یا بالاتر نادیده گرفته می‌شود. نمونه کد زیر ورودی‌های جدید فایل مانیفست را نشان می‌دهد:
<application ... <!-- The below attribute is ignored. --> android:fullBackupContent="old_config.xml" <!-- You can point to your new configuration using the new dataExtractionRules attribute . --> android:dataExtractionRules="new_config.xml" ...> </application>
اتصال‌پذیری
اجازه‌های بلوتوث
Android 12 اجازه‌های
BLUETOOTH_SCAN،
BLUETOOTH_ADVERTISE،
و
BLUETOOTH_CONNECT
را معرفی می‌کند. این اجازه‌ها تعامل با
دستگاه‌های بلوتوث را برای برنامه‌هایی که
Android 12 را هدف قرار می‌دهند آسان‌تر می‌کند، به‌ویژه برای برنامه‌هایی که
به دسترسی به مکان دستگاه نیاز ندارند.
برای آماده کردن دستگاهتان برای هدف‌یابی Android نسخه ۱۲ یا بالاتر، منطق برنامه‌تان را به‌روز کنید. به‌جای اعلام مجموعه قدیمی اجازه‌های بلوتوث، مجموعه جدیدتری از اجازه‌های بلوتوث را اعلام کنید.
اتصال هم‌زمان همتا به همتا + اینترنت
برای برنامه‌هایی که Android 12 (میانای برنامه‌سازی کاربردی سطح ۳۱) یا بالاتر را هدف قرار می‌دهند، دستگاه‌هایی که از اتصال هم‌زمان همتا به همتا و اینترنت پشتیبانی می‌کنند می‌توانند اتصال Wi-Fi هم‌زمان به دستگاه همتا و شبکه اصلی ارائه‌دهنده اینترنت را حفظ کنند، که این امر تجربه کاربری را یکپارچه‌تر می‌کند. برنامه‌هایی که Android 11 (سطح API ۳۰) یا پایین‌تر را هدف قرار می‌دهند همچنان رفتار قدیمی را تجربه می‌کنند، که در آن اتصال شبکه Wi-Fi اصلی پیش‌از اتصال به دستگاه همتا قطع می‌شود.
سازگاری
WifiManager.getConnectionInfo()
می‌تواند WifiInfo را فقط برای یک شبکه برگرداند. به همین دلیل، رفتار میانای برنامه‌سازی کاربردی در Android 12 و بالاتر به روش‌های زیر تغییر کرده است:
- اگر فقط یک شبکه Wi-Fi دردسترس باشد،
WifiInfoآن برگردانده می‌شود. - اگر بیش‌از یک شبکه Wi-Fi دردسترس باشد و برنامه تماس گیرنده اتصال همتا به همتا را راه‌اندازی کرده باشد،
WifiInfoمربوط به دستگاه همتا برگردانده می‌شود. - اگر بیش‌از یک شبکه Wi-Fi دردسترس باشد و برنامه برقراری تماس اتصال همتا‌به‌همتا را راه‌اندازی نکرده باشد،
WifiInfoاتصال اصلی ارائه‌دهنده اینترنت برگردانده می‌شود.
برای ارائه تجربه کاربری بهتر در دستگاه‌هایی که از شبکه‌های Wi-Fi هم‌زمان دوگانه پشتیبانی می‌کنند، توصیه می‌کنیم همه برنامه‌ها (به‌ویژه برنامه‌هایی که اتصالات همتا‌به‌همتا را راه‌اندازی می‌کنند) از فراخوانی WifiManager.getConnectionInfo() مهاجرت کنند و به‌جای آن از NetworkCallback.onCapabilitiesChanged() استفاده کنند تا همه اشیای WifiInfo را که با NetworkRequest استفاده‌شده برای ثبت NetworkCallback مطابقت دارند دریافت کنند. getConnectionInfo() از Android 12 منسوخ شده است.
نمونه کد زیر نحوه دریافت WifiInfo را در
NetworkCallback نشان می‌دهد:
کاتلین
val networkCallback = object : ConnectivityManager.NetworkCallback() { ... override fun onCapabilitiesChanged( network : Network, networkCapabilities : NetworkCapabilities) { val transportInfo = networkCapabilities.getTransportInfo() if (transportInfo !is WifiInfo) return val wifiInfo : WifiInfo = transportInfo ... } }
جاوا
final NetworkCallback networkCallback = new NetworkCallback() { ... @Override public void onCapabilitiesChanged( Network network, NetworkCapabilities networkCapabilities) { final TransportInfo transportInfo = networkCapabilities.getTransportInfo(); if (!(transportInfo instanceof WifiInfo)) return; final WifiInfo wifiInfo = (WifiInfo) transportInfo; ... } ... };
میانای برنامه‌سازی کاربردی بومی mDNSResponder
Android 12 زمان تعامل برنامه‌ها با شبح mDNSResponder را بااستفاده از
میانای برنامه‌سازی کاربردی بومی mDNSResponder تغییر می‌دهد.
قبلاً، وقتی برنامه‌ای سرویسی را در شبکه ثبت می‌کرد
و روش getSystemService() را فراخوانی می‌کرد،
سرویس NSD سیستم، دیمون mDNSResponder را راه‌اندازی می‌کرد، حتی اگر
برنامه هنوز هیچ روش NsdManager را فراخوانی نکرده بود. سپس دیمون دستگاه را در گروه‌های چندفرستی همه گره‌ها مشترک کرد که باعث شد سیستم بیشتر بیدار شود و برق بیشتری مصرف کند. برای به‌حداقل رساندن مصرف باتری، در Android 12
و نسخه‌های بالاتر، سیستم اکنون دیمون mDNSResponder را فقط زمانی که برای رویدادهای NSD لازم باشد راه‌اندازی می‌کند و پس‌از آن متوقف می‌کند.
چون این تغییر بر زمان دردسترس بودن شبح mDNSResponder تأثیر می‌گذارد، برنامه‌هایی که فرض می‌کنند شبح mDNSResponder پس‌از فراخوانی روش getSystemService() شروع خواهد شد ممکن است پیام‌هایی از سیستم دریافت کنند که می‌گوید شبح mDNSResponder دردسترس نیست. برنامه‌هایی که از NsdManager استفاده می‌کنند و از
میانای برنامه‌سازی کاربردی بومی mDNSResponder استفاده نمی‌کنند تحت‌تأثیر این تغییر قرار نمی‌گیرند.
کتابخانه‌های ارائه‌دهنده
کتابخانه‌های مشترک بومی ارائه‌شده توسط فروشنده
کتابخانه‌های مشترک بومی غیرNDK
که توسط فروشندگان سیلیکون یا سازندگان دستگاه ارائه می‌شوند،
به‌طور پیش‌فرض دردسترس نیستند اگر برنامه Android 12 (سطح میانای برنامه‌سازی کاربردی ۳۱) یا بالاتر را هدف قرار دهد. کتابخانه‌های
فقط زمانی قابل‌دسترسی هستند که صریحاً بااستفاده از برچسب
<uses-native-library>
درخواست شوند.
اگر برنامه Android 11 (سطح میانای برنامه‌سازی کاربردی ۳۰) یا پایین‌تر را هدف‌یابی می‌کند،
برچسب <uses-native-library> لازم نیست. در این صورت، هر کتابخانه مشترک بومی
صرف‌نظر از اینکه کتابخانه NDK باشد یا نه، قابل‌دسترسی است.
محدودیت‌های غیرکیت توسعه نرم‌افزار به‌روز شد
Android 12 شامل فهرست‌های به‌روزشده‌ای از میاناهای غیرکیت توسعه نرم‌افزار محدودشده است که براساس همکاری با توسعه‌دهندگان Android و جدیدترین آزمایش‌های داخلی تهیه شده است. هرزمان ممکن باشد، پیش‌از محدود کردن میاناهای غیرکیت توسعه نرم‌افزار، مطمئن می‌شویم که جایگزین‌های عمومی دردسترس باشند.
اگر برنامه شما Android 12 را هدف قرار نمی‌دهد، برخی‌از این تغییرات ممکن است فوراً بر شما تأثیر نگذارد. بااین‌حال، اگرچه درحال‌حاضر می‌توانید از برخی میاناهای غیرکیت توسعه نرم‌افزار استفاده کنید (بسته به سطح میانای برنامه‌سازی کاربردی هدف برنامه‌تان)، استفاده از هر روش یا فیلد غیرکیت توسعه نرم‌افزار همیشه خطر بالایی برای ازکار افتادن برنامه‌تان دارد.
اگر مطمئن نیستید که برنامه‌تان از میاناهای غیرکیت توسعه نرم‌افزار استفاده می‌کند یا نه، می‌توانید برنامه‌تان را آزمایش کنید تا متوجه شوید. اگر برنامه‌تان به میاناهای غیر SDK متکی است، باید برنامه‌ریزی برای انتقال به جایگزین‌های SDK را شروع کنید. بااین‌حال، می‌دانیم که برخی‌از برنامه‌ها موارد استفاده معتبری برای استفاده از میاناهای غیرکیت توسعه نرم‌افزار دارند. اگر نمی‌توانید جایگزینی برای استفاده از میانای غیرکیت توسعه نرم‌افزار برای ویژگی‌ای در برنامه‌تان پیدا کنید، باید درخواست میانای برنامه‌سازی کاربردی عمومی جدیدی بدهید.
برای آشنایی بیشتر با تغییرات این نسخه از Android، به به‌روزرسانی‌های محدودیت‌های میانای غیر کیت توسعه نرم‌افزار در Android 12 مراجعه کنید. برای کسب اطلاعات بیشتر درباره میاناهای غیرکیت توسعه نرم‌افزار به‌طور کلی، به محدودیت‌های میاناهای غیرکیت توسعه نرم‌افزار مراجعه کنید.