تغییرات رفتار: برنامه هایی که اندروید 12 را هدف قرار می دهند، تغییرات رفتاری: برنامه هایی که اندروید 12 را هدف قرار می دهند

مانند نسخه‌های قبلی، اندروید ۱۲ شامل تغییرات رفتاری است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات رفتاری زیر منحصراً برای برنامه‌هایی اعمال می‌شود که اندروید ۱۲ یا بالاتر را هدف قرار می‌دهند. اگر برنامه شما اندروید ۱۲ را هدف قرار می‌دهد، باید برنامه خود را اصلاح کنید تا در صورت لزوم، از این رفتارها به درستی پشتیبانی کند.

حتماً لیست تغییرات رفتاری که بر همه برنامه‌های در حال اجرا در اندروید ۱۲ تأثیر می‌گذارند را نیز بررسی کنید.

تجربه کاربری

اعلان‌های سفارشی

اندروید ۱۲ ظاهر و رفتار اعلان‌های کاملاً سفارشی را تغییر می‌دهد. پیش از این، اعلان‌های سفارشی می‌توانستند از کل ناحیه اعلان استفاده کنند و طرح‌بندی‌ها و سبک‌های خاص خود را ارائه دهند. این امر منجر به ایجاد الگوهای ضدالگو می‌شد که می‌توانست کاربران را گیج کند یا باعث ایجاد مشکلات سازگاری طرح‌بندی در دستگاه‌های مختلف شود.

برای برنامه‌هایی که اندروید ۱۲ را هدف قرار می‌دهند، اعلان‌هایی که دارای نمای محتوای سفارشی هستند، دیگر از کل ناحیه اعلان استفاده نمی‌کنند؛ در عوض، سیستم یک الگوی استاندارد را اعمال می‌کند. این الگو تضمین می‌کند که اعلان‌های سفارشی در همه حالت‌ها، مانند نماد اعلان و گزینه‌های گسترش (در حالت بسته) و نماد اعلان، نام برنامه و گزینه‌های بسته (در حالت باز) از همان دکوراسیون اعلان‌های دیگر برخوردار باشند. این رفتار تقریباً مشابه رفتار Notification.DecoratedCustomViewStyle است.

به این ترتیب، اندروید ۱۲ تمام اعلان‌ها را از نظر بصری منسجم و خوانا می‌کند و به راحتی قابل مشاهده و مشاهده است و یک بخش اعلان آشنا و قابل کشف برای کاربران فراهم می‌کند.

تصویر زیر یک اعلان سفارشی را در قالب استاندارد نشان می‌دهد:

مثال‌های زیر نشان می‌دهند که اعلان‌های سفارشی چگونه در حالت‌های بسته و باز نمایش داده می‌شوند:

این تغییر در اندروید ۱۲، برنامه‌هایی را تحت تأثیر قرار می‌دهد که زیرکلاس‌های سفارشی Notification.Style را تعریف می‌کنند، یا از متدهای setCustomContentView(RemoteViews) ، setCustomBigContentView(RemoteViews) ‎ و setCustomHeadsUpContentView(RemoteViews) Notification.Builder استفاده می‌کنند.

اگر برنامه شما از اعلان‌های کاملاً سفارشی استفاده می‌کند، توصیه می‌کنیم در اسرع وقت با الگوی جدید آزمایش کنید.

1. فعال کردن تغییر اعلان‌های سفارشی:

   1. برای فعال کردن رفتار جدید، targetSdkVersion برنامه خود را به S تغییر دهید.
   2. دوباره کامپایل کنید.
   3. برنامه خود را روی دستگاه یا شبیه‌ساز دارای اندروید ۱۲ نصب کنید.

2. تمام اعلان‌هایی که از نماهای سفارشی استفاده می‌کنند را آزمایش کنید و مطمئن شوید که در سایه همانطور که انتظار دارید به نظر می‌رسند. هنگام آزمایش، این ملاحظات را در نظر بگیرید و تنظیمات لازم را انجام دهید:

   • ابعاد نماهای سفارشی تغییر کرده است. به طور کلی، ارتفاع ارائه شده به اعلان‌های سفارشی کمتر از قبل است. در حالت جمع شده، حداکثر ارتفاع محتوای سفارشی از 106dp به 48dp کاهش یافته است. همچنین، فضای افقی کمتری وجود دارد.

   • همه اعلان‌ها برای برنامه‌هایی که اندروید ۱۲ را هدف قرار می‌دهند، قابل بسط هستند. معمولاً این بدان معناست که اگر از setCustomContentView استفاده می‌کنید، باید از setBigCustomContentView نیز استفاده کنید تا مطمئن شوید حالت‌های جمع‌شده و بازشده با هم سازگار هستند.

   • برای اطمینان از اینکه حالت «Heads Up» مطابق انتظار شما باشد، فراموش نکنید که اهمیت کانال اعلان را به «HIGH» (روی صفحه ظاهر می‌شود) افزایش دهید.

تغییرات تأیید لینک‌های برنامه‌های اندروید

در برنامه‌هایی که اندروید ۱۲ یا بالاتر را هدف قرار می‌دهند، سیستم چندین تغییر در نحوه تأیید پیوندهای برنامه اندروید ایجاد می‌کند. این تغییرات قابلیت اطمینان تجربه پیوند برنامه را بهبود می‌بخشد و کنترل بیشتری را برای توسعه‌دهندگان برنامه و کاربران نهایی فراهم می‌کند.

اگر برای باز کردن لینک‌های وب در برنامه خود به تأیید پیوند برنامه اندروید (Android App Link verification) متکی هستید، هنگام اضافه کردن فیلترهای هدف برای تأیید پیوند برنامه اندروید (Android App Link verification)، بررسی کنید که از قالب صحیح استفاده می‌کنید. به طور خاص، مطمئن شوید که این فیلترهای هدف شامل دسته BROWSABLE باشند و از طرح https پشتیبانی کنند.

همچنین می‌توانید لینک‌های برنامه خود را به صورت دستی تأیید کنید تا اعتبار اعلان‌های خود را آزمایش کنید.

بهبود عملکرد تصویر در تصویر

اندروید ۱۲ بهبودهایی در رفتار حالت تصویر در تصویر (PiP) ارائه می‌دهد و بهبودهای ظاهری را برای انیمیشن‌های انتقال تصویر هم برای ناوبری حرکتی و هم ناوبری مبتنی بر عنصر توصیه می‌کند.

برای اطلاعات بیشتر به بهبودهای تصویر در تصویر مراجعه کنید.

طراحی مجدد نان تست

در اندروید ۱۲، نمای Toast دوباره طراحی شده است. Toastها اکنون به دو خط متن محدود شده‌اند و نماد برنامه را در کنار متن نشان می‌دهند.

برای جزئیات بیشتر به نمای کلی Toasts مراجعه کنید.

امنیت و حریم خصوصی

مکان تقریبی

در دستگاه‌هایی که اندروید ۱۲ یا بالاتر دارند، کاربران می‌توانند برای برنامه شما درخواست دقت تقریبی مکان کنند .

کوکی‌های مدرن SameSite در WebView

کامپوننت WebView اندروید بر اساس Chromium ، پروژه متن‌بازی که مرورگر کروم گوگل را پشتیبانی می‌کند، ساخته شده است. Chromium تغییراتی را در مدیریت کوکی‌های شخص ثالث ایجاد کرده است تا امنیت و حریم خصوصی بیشتری را فراهم کند و شفافیت و کنترل بیشتری را در اختیار کاربران قرار دهد. از اندروید ۱۲، این تغییرات در WebView نیز گنجانده شده است، زمانی که برنامه‌ها اندروید ۱۲ (سطح API ۳۱) یا بالاتر را هدف قرار می‌دهند.

ویژگی SameSite یک کوکی، کنترل می‌کند که آیا می‌توان آن را با هر درخواستی ارسال کرد یا فقط با درخواست‌های همان سایت. تغییرات محافظت از حریم خصوصی زیر، نحوه‌ی مدیریت پیش‌فرض کوکی‌های شخص ثالث را بهبود می‌بخشد و به محافظت در برابر اشتراک‌گذاری ناخواسته‌ی بین سایتی کمک می‌کند:

• کوکی‌های بدون ویژگی SameSite به صورت SameSite=Lax در نظر گرفته می‌شوند.
• کوکی‌هایی که SameSite=None دارند، باید ویژگی Secure را نیز مشخص کنند، به این معنی که به یک زمینه امن نیاز دارند و باید از طریق HTTPS ارسال شوند.
• لینک‌های بین نسخه‌های HTTP و HTTPS یک سایت اکنون به عنوان درخواست‌های بین سایتی در نظر گرفته می‌شوند، بنابراین کوکی‌ها ارسال نمی‌شوند مگر اینکه به طور مناسب با علامت‌گذاری SameSite=None; Secure مشخص شده باشند.

برای توسعه‌دهندگان، راهنمایی کلی این است که وابستگی‌های کوکی بین سایتی را در جریان‌های کاربری حیاتی خود شناسایی کنند و اطمینان حاصل کنند که ویژگی SameSite به صراحت با مقادیر مناسب در صورت نیاز تنظیم شده است. شما باید به صراحت کوکی‌هایی را که مجاز به کار در سراسر وب‌سایت‌ها یا در سراسر پیمایش‌های همان سایت هستند که از HTTP به HTTPS منتقل می‌شوند، مشخص کنید.

برای راهنمایی کامل برای توسعه‌دهندگان وب در مورد این تغییرات، به SameSite Cookies Explained و Schemeful SameSite مراجعه کنید.

رفتارهای SameSite را در برنامه خود آزمایش کنید

اگر برنامه شما از WebView استفاده می‌کند، یا اگر وب‌سایت یا سرویسی را مدیریت می‌کنید که از کوکی‌ها استفاده می‌کند، توصیه می‌کنیم جریان‌های خود را در Android 12 WebView آزمایش کنید. اگر مشکلی پیدا کردید، ممکن است لازم باشد کوکی‌های خود را برای پشتیبانی از رفتارهای جدید SameSite به‌روزرسانی کنید.

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

برای تست یک برنامه با WebView، باید رفتارهای جدید SameSite را برای برنامه‌ای که می‌خواهید تست کنید، با انجام هر یک از مراحل زیر فعال کنید:

• با فعال کردن پرچم رابط کاربری webview-enable-modern-cookie-same-site در ابزار توسعه وب ویو، رفتارهای SameSite را به صورت دستی در دستگاه آزمایشی فعال کنید.

  این رویکرد به شما امکان می‌دهد تا روی هر دستگاهی که اندروید ۵.۰ (سطح API 21) یا بالاتر - از جمله اندروید ۱۲ - و نسخه WebView 89.0.4385.0 یا بالاتر را اجرا می‌کند، تست کنید.

• برنامه خود را برای هدف قرار دادن اندروید ۱۲ (سطح API 31) توسط targetSdkVersion کامپایل کنید.

  اگر از این روش استفاده می‌کنید، باید از دستگاهی استفاده کنید که اندروید ۱۲ را اجرا می‌کند.

برای اطلاعات بیشتر در مورد اشکال‌زدایی از راه دور برای WebView در اندروید، به «شروع به کار با اشکال‌زدایی از راه دور دستگاه‌های اندروید» مراجعه کنید.

منابع دیگر

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

سنسورهای حرکتی محدود به سرعت هستند

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

درباره محدود کردن سرعت حسگر بیشتر بدانید.

خواب زمستانی برنامه

اندروید ۱۲، رفتار بازنشانی خودکار مجوزها را که در اندروید ۱۱ (سطح API 30) معرفی شده بود، گسترش می‌دهد. اگر برنامه شما برای اندروید ۱۲ باشد و کاربر برای چند ماه با برنامه شما تعامل نداشته باشد، سیستم هرگونه مجوز اعطا شده را به طور خودکار بازنشانی می‌کند و برنامه شما را در حالت خواب زمستانی قرار می‌دهد.

برای کسب اطلاعات بیشتر در مورد خواب زمستانی برنامه، به راهنمای آن مراجعه کنید.

اعلام انتساب در حسابرسی دسترسی به داده‌ها

API حسابرسی دسترسی به داده‌ها، که در اندروید ۱۱ (سطح API 30) معرفی شد، به شما امکان می‌دهد بر اساس موارد استفاده برنامه خود ، برچسب‌های انتساب ایجاد کنید . این برچسب‌ها تعیین اینکه کدام بخش از برنامه شما نوع خاصی از دسترسی به داده‌ها را انجام می‌دهد، برای شما آسان‌تر می‌کنند.

اگر برنامه شما اندروید ۱۲ یا بالاتر را هدف قرار می‌دهد، باید این تگ‌های انتساب را در فایل مانیفست برنامه خود اعلام کنید .

محدودیت پشتیبان‌گیری ADB

برای کمک به محافظت از داده‌های خصوصی برنامه، اندروید ۱۲ رفتار پیش‌فرض دستور adb backup را تغییر می‌دهد. برای برنامه‌هایی که اندروید ۱۲ (سطح API 31) یا بالاتر را هدف قرار می‌دهند، هنگامی که کاربر دستور adb backup را اجرا می‌کند، داده‌های برنامه از هرگونه داده سیستمی دیگری که از دستگاه صادر می‌شود، مستثنی می‌شوند.

اگر گردش‌های کاری تست یا توسعه شما به داده‌های برنامه با استفاده از adb backup متکی هستند، اکنون می‌توانید با تنظیم android:debuggable روی true در فایل مانیفست برنامه خود، امکان خروجی گرفتن از داده‌های برنامه خود را فراهم کنید.

صادرات ایمن‌تر قطعات

اگر برنامه شما اندروید ۱۲ یا بالاتر را هدف قرار داده و شامل فعالیت‌ها ، سرویس‌ها یا گیرنده‌های پخشی است که از فیلترهای intent استفاده می‌کنند، باید صریحاً ویژگی android:exported را برای این اجزای برنامه اعلام کنید.

اگر کامپوننت برنامه شامل دسته LAUNCHER است، android:exported را روی true تنظیم کنید. در بیشتر موارد دیگر، android:exported را روی false تنظیم کنید.

قطعه کد زیر نمونه‌ای از یک سرویس را نشان می‌دهد که شامل یک فیلتر intent است که ویژگی 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>

پیام‌ها در اندروید استودیو

اگر برنامه شما شامل یک اکتیویتی، سرویس یا گیرنده پخش است که از فیلترهای intent استفاده می‌کند اما android:exported را تعریف نکرده است، بسته به نسخه اندروید استودیویی که استفاده می‌کنید، پیام‌های هشدار زیر ظاهر می‌شوند:

اندروید استودیو ۲۰۲۰.۳.۱ Canary 11 یا بالاتر

پیام‌های زیر ظاهر می‌شوند:

1. هشدار lint زیر در فایل مانیفست شما ظاهر می‌شود:

   When using intent filters, please specify android:exported as well
   

2. وقتی سعی می‌کنید برنامه خود را کامپایل کنید، پیام خطای ساخت زیر ظاهر می‌شود:

   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.
   

نسخه‌های قدیمی‌تر اندروید استودیو

اگر سعی کنید برنامه را نصب کنید، 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'

تغییرپذیری intent های در انتظار

اگر برنامه شما اندروید ۱۲ را هدف قرار می‌دهد، باید قابلیت تغییرپذیری هر شیء PendingIntent که برنامه شما ایجاد می‌کند را مشخص کنید. این الزام اضافی امنیت برنامه شما را بهبود می‌بخشد.

تغییرپذیریِ در حال انتظارِ اینتنت را آزمایش کنید

برای تشخیص اینکه آیا برنامه شما فاقد اعلان‌های تغییرپذیری است یا خیر، به دنبال هشدار lint زیر در اندروید استودیو باشید:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

قصد ناامن راه اندازی می شود

برای بهبود امنیت پلتفرم، اندروید ۱۲ و بالاتر یک ویژگی اشکال‌زدایی ارائه می‌دهد که راه‌اندازی‌های ناامن intentها را تشخیص می‌دهد . هنگامی که سیستم چنین راه‌اندازی ناامنی را تشخیص می‌دهد، نقض StrictMode رخ می‌دهد.

عملکرد

محدودیت‌های راه‌اندازی سرویس پیش‌زمینه

برنامه‌هایی که اندروید ۱۲ یا بالاتر را هدف قرار می‌دهند، نمی‌توانند سرویس‌های پیش‌زمینه را هنگام اجرا در پس‌زمینه شروع کنند ، به جز چند مورد خاص . اگر برنامه‌ای سعی کند هنگام اجرا در پس‌زمینه، یک سرویس پیش‌زمینه را شروع کند، یک استثنا رخ می‌دهد (به جز چند مورد خاص).

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

اجازه دقیق زنگ هشدار

برای تشویق برنامه‌ها به صرفه‌جویی در منابع سیستم، برنامه‌هایی که اندروید ۱۲ و بالاتر را هدف قرار می‌دهند و آلارم‌های دقیقی تنظیم می‌کنند، باید به قابلیت «آلارم‌ها و یادآوری‌ها» که در صفحه دسترسی ویژه به برنامه‌ها در تنظیمات سیستم ظاهر می‌شود، دسترسی داشته باشند.

برای به دست آوردن این دسترسی ویژه به برنامه، مجوز SCHEDULE_EXACT_ALARM را در مانیفست درخواست کنید.

هشدارهای دقیق فقط باید برای ویژگی‌های کاربرپسند استفاده شوند. درباره موارد استفاده قابل قبول برای تنظیم هشدار دقیق بیشتر بدانید.

غیرفعال کردن تغییر رفتار

همزمان با آماده‌سازی برنامه خود برای اندروید ۱۲، می‌توانید تغییر رفتار را در نسخه قابل اشکال‌زدایی خود به طور موقت برای اهداف آزمایشی غیرفعال کنید. برای انجام این کار، یکی از کارهای زیر را انجام دهید:

• در صفحه تنظیمات گزینه‌های توسعه‌دهندگان ، گزینه «تغییرات سازگاری برنامه» را انتخاب کنید. در صفحه‌ای که ظاهر می‌شود، روی نام برنامه خود ضربه بزنید، سپس گزینه «نیازمندی‌ها» (REQUIRE_EXACT_ALARM_PERMISSION) را غیرفعال کنید.

• در یک پنجره ترمینال روی دستگاه توسعه‌دهنده خود، دستور زیر را اجرا کنید:

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

اطلاع رسانی محدودیت های ترامپولین

وقتی کاربران با اعلان‌ها تعامل می‌کنند، برخی از برنامه‌ها با راه‌اندازی یک جزء برنامه که در نهایت فعالیتی را که کاربر در نهایت می‌بیند و با آن تعامل می‌کند، شروع می‌کند، به لمس اعلان‌ها پاسخ می‌دهند. این جزء برنامه به عنوان یک ترامپولین اعلان شناخته می‌شود.

برای بهبود عملکرد و تجربه کاربری برنامه، برنامه‌هایی که اندروید ۱۲ یا بالاتر را هدف قرار می‌دهند، نمی‌توانند فعالیت‌ها را از سرویس‌ها یا گیرنده‌های پخش که به عنوان تابلوهای اعلان استفاده می‌شوند، شروع کنند. به عبارت دیگر، پس از اینکه کاربر روی یک اعلان یا یک دکمه عمل در اعلان ضربه می‌زند، برنامه شما نمی‌تواند 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" است. این بخش شامل اطلاعات لازم برای شناسایی کامپوننتی است که در نتیجه‌ی لمس اعلان شروع به کار می‌کند.

برنامه خود را به‌روزرسانی کنید

اگر برنامه شما یک فعالیت را از یک سرویس یا گیرنده پخش که به عنوان یک ترامپولین اعلان عمل می‌کند، شروع می‌کند، مراحل مهاجرت زیر را انجام دهید:

1. یک شیء PendingIntent ایجاد کنید که با فعالیتی که کاربران پس از لمس اعلان می‌بینند، مرتبط باشد.
2. از شیء PendingIntent که در مرحله قبل ایجاد کردید، به عنوان بخشی از ساخت اعلان خود استفاده کنید.

برای شناسایی منشأ فعالیت، مثلاً برای انجام ثبت وقایع، هنگام ارسال اعلان از موارد اضافی استفاده کنید. برای ثبت وقایع متمرکز، از ActivityLifecycleCallbacks یا Jetpack lifecycle observers استفاده کنید.

تغییر رفتار

هنگام آزمایش نسخه قابل اشکال‌زدایی برنامه خود، می‌توانید این محدودیت را با استفاده از پرچم سازگاری برنامه NOTIFICATION_TRAMPOLINE_BLOCK فعال و غیرفعال کنید.

پشتیبان گیری و بازیابی

تغییراتی در نحوه‌ی عملکرد پشتیبان‌گیری و بازیابی در برنامه‌هایی که روی اندروید ۱۲ (سطح API ۳۱) اجرا می‌شوند و آن را هدف قرار می‌دهند، ایجاد شده است. پشتیبان‌گیری و بازیابی اندروید دو شکل دارد:

• پشتیبان‌گیری ابری: داده‌های کاربر در گوگل درایو کاربر ذخیره می‌شوند تا بعداً بتوان آن‌ها را در همان دستگاه یا یک دستگاه جدید بازیابی کرد.
• انتقال دستگاه به دستگاه (D2D): داده‌های کاربر مستقیماً از دستگاه قدیمی‌تر او به دستگاه جدیدش ارسال می‌شود، مثلاً با استفاده از کابل.

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

تغییرات عملکرد انتقال D2D

برای برنامه‌هایی که روی اندروید ۱۲ و بالاتر اجرا می‌شوند و هدف قرار می‌دهند:

• تعیین قوانین شمول و عدم شمول با مکانیزم پیکربندی XML بر انتقال‌های D2D تأثیری ندارد، اگرچه همچنان بر پشتیبان‌گیری و بازیابی مبتنی بر ابر (مانند پشتیبان‌گیری‌های Google Drive) تأثیر می‌گذارد. برای تعیین قوانین برای انتقال‌های D2D، باید از پیکربندی جدیدی که در بخش بعدی پوشش داده شده است، استفاده کنید.

• در دستگاه‌های برخی از تولیدکنندگان، مشخص کردن android:allowBackup="false" پشتیبان‌گیری در گوگل درایو را غیرفعال می‌کند، اما انتقال D2D را برای برنامه غیرفعال نمی‌کند.

قالب جدید برای شمول و عدم شمول

برنامه‌هایی که روی اندروید ۱۲ و بالاتر اجرا می‌شوند و هدفشان اندروید است، از فرمت متفاوتی برای پیکربندی XML استفاده می‌کنند. این فرمت با ملزم کردن شما به تعیین قوانین شمول و عدم شمول به طور جداگانه برای پشتیبان‌گیری ابری و انتقال D2D، تفاوت بین پشتیبان‌گیری گوگل درایو و انتقال D2D را آشکار می‌کند.

به صورت اختیاری، می‌توانید از آن برای تعیین قوانین پشتیبان‌گیری نیز استفاده کنید، که در این صورت پیکربندی قبلی در دستگاه‌هایی که اندروید ۱۲ یا بالاتر دارند نادیده گرفته می‌شود. پیکربندی قدیمی‌تر همچنان برای دستگاه‌هایی که اندروید ۱۱ یا پایین‌تر دارند مورد نیاز است.

تغییرات قالب XML

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

<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 در فایل manifest، برنامه‌های خود را به پیکربندی XML جدید هدایت کنید. وقتی به پیکربندی XML جدید اشاره می‌کنید، ویژگی android:fullBackupContent که به پیکربندی قدیمی اشاره می‌کند، در دستگاه‌هایی که اندروید ۱۲ یا بالاتر دارند، نادیده گرفته می‌شود. نمونه کد زیر ورودی‌های فایل manifest جدید را نشان می‌دهد:

<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>

اتصال

مجوزهای بلوتوث

اندروید ۱۲ مجوزهای BLUETOOTH_SCAN ، BLUETOOTH_ADVERTISE و BLUETOOTH_CONNECT را معرفی کرد. این مجوزها، تعامل برنامه‌هایی که اندروید ۱۲ را هدف قرار می‌دهند با دستگاه‌های بلوتوث را آسان‌تر می‌کند، به خصوص برای برنامه‌هایی که نیازی به دسترسی به موقعیت مکانی دستگاه ندارند.

برای آماده‌سازی دستگاه خود برای اندروید ۱۲ یا بالاتر، منطق برنامه خود را به‌روزرسانی کنید. به جای اعلام مجموعه‌ای قدیمی از مجوزهای بلوتوث ، مجموعه‌ای مدرن‌تر از مجوزهای بلوتوث را اعلام کنید.

اتصال همزمان نظیر به نظیر + اینترنت

برای برنامه‌هایی که اندروید ۱۲ (سطح API 31) یا بالاتر را هدف قرار می‌دهند، دستگاه‌هایی که از اتصالات همزمان نظیر به نظیر و اینترنت پشتیبانی می‌کنند، می‌توانند اتصالات Wi-Fi همزمان را هم به دستگاه نظیر و هم به شبکه اصلی ارائه دهنده اینترنت حفظ کنند و تجربه کاربر را یکپارچه‌تر کنند. برنامه‌هایی که اندروید ۱۱ (سطح API 30) یا پایین‌تر را هدف قرار می‌دهند، هنوز رفتار قدیمی را تجربه می‌کنند، جایی که شبکه Wi-Fi اصلی قبل از اتصال به دستگاه نظیر قطع می‌شود.

سازگاری

WifiManager.getConnectionInfo() قادر است WifiInfo فقط برای یک شبکه واحد برگرداند. به همین دلیل، رفتار API در اندروید ۱۲ و بالاتر به روش‌های زیر تغییر کرده است:

• اگر فقط یک شبکه وای‌فای در دسترس باشد، اطلاعات مربوط به آن WifiInfo برگردانده می‌شود.
• اگر بیش از یک شبکه Wi-Fi در دسترس باشد و برنامه فراخوانی یک اتصال نظیر به نظیر را فعال کرده باشد، WifiInfo مربوط به دستگاه نظیر بازگردانده می‌شود.
• اگر بیش از یک شبکه Wi-Fi در دسترس باشد و برنامه تماس گیرنده اتصال نظیر به نظیر را برقرار نکرده باشد، WifiInfo اتصال اصلی ارائه دهنده اینترنت بازگردانده می‌شود.

برای ارائه تجربه کاربری بهتر در دستگاه‌هایی که از دو شبکه وای‌فای همزمان پشتیبانی می‌کنند، به همه برنامه‌ها - به ویژه برنامه‌هایی که اتصالات نظیر به نظیر را فعال می‌کنند - توصیه می‌کنیم از فراخوانی WifiManager.getConnectionInfo() صرف نظر کرده و در عوض از NetworkCallback.onCapabilitiesChanged() برای دریافت تمام اشیاء WifiInfo که با NetworkRequest مورد استفاده برای ثبت NetworkCallback مطابقت دارند، استفاده کنند. getConnectionInfo() از اندروید ۱۲ منسوخ شده است.

نمونه کد زیر نحوه دریافت 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;
    ...
  }
  ...
};

API بومی mDNSResponder

اندروید ۱۲ زمانی که برنامه‌ها می‌توانند با استفاده از API بومی mDNSResponder با سرویس mDNSResponder تعامل داشته باشند، تغییر می‌کند. پیش از این، هنگامی که یک برنامه سرویسی را در شبکه ثبت می‌کرد و متد getSystemService() را فراخوانی می‌کرد، سرویس NSD سیستم، سرویس mDNSResponder را آغاز می‌کرد، حتی اگر برنامه هنوز هیچ متد NsdManager فراخوانی نکرده بود. سپس این سرویس دستگاه را در گروه‌های چندپخشی all-nodes ثبت می‌کرد و باعث می‌شد سیستم بیشتر بیدار شود و از انرژی اضافی استفاده کند. برای به حداقل رساندن مصرف باتری، در اندروید ۱۲ و بالاتر، سیستم اکنون سرویس mDNSResponder را فقط زمانی که برای رویدادهای NSD مورد نیاز است، آغاز می‌کند و پس از آن متوقف می‌کند.

از آنجا که این تغییر زمانی که سرویس mDNSResponder در دسترس است، تأثیر می‌گذارد، برنامه‌هایی که فرض می‌کنند سرویس mDNSResponder پس از فراخوانی متد getSystemService() آغاز خواهد شد، ممکن است پیام‌هایی از سیستم دریافت کنند که می‌گویند سرویس mDNSResponder در دسترس نیست. برنامه‌هایی که از NsdManager استفاده می‌کنند و از API بومی mDNSResponder استفاده نمی‌کنند، تحت تأثیر این تغییر قرار نمی‌گیرند.

کتابخانه‌های فروشندگان

کتابخانه‌های اشتراکی بومی ارائه شده توسط فروشنده

کتابخانه‌های اشتراکی غیر NDK که توسط فروشندگان سیلیکون یا سازندگان دستگاه ارائه می‌شوند، اگر برنامه اندروید ۱۲ (سطح API 31) یا بالاتر را هدف قرار دهد، به طور پیش‌فرض قابل دسترسی نیستند. این کتابخانه‌ها فقط زمانی قابل دسترسی هستند که به صراحت با استفاده از برچسب <uses-native-library> درخواست شوند.

اگر برنامه اندروید ۱۱ (سطح API 30) یا پایین‌تر را هدف قرار می‌دهد، تگ <uses-native-library> لازم نیست. در این صورت، هر کتابخانه اشتراکی بومی صرف نظر از اینکه یک کتابخانه NDK باشد یا خیر، قابل دسترسی است.

محدودیت‌های غیر SDK به‌روزرسانی شدند

اندروید ۱۲ شامل فهرست‌های به‌روز شده‌ای از رابط‌های کاربری محدود شده غیر SDK بر اساس همکاری با توسعه‌دهندگان اندروید و آخرین آزمایش‌های داخلی است. در صورت امکان، قبل از محدود کردن رابط‌های کاربری غیر SDK، مطمئن می‌شویم که جایگزین‌های عمومی در دسترس هستند.

اگر برنامه شما اندروید ۱۲ را هدف قرار نمی‌دهد، ممکن است برخی از این تغییرات بلافاصله شما را تحت تأثیر قرار ندهند. با این حال، اگرچه در حال حاضر می‌توانید از برخی رابط‌های غیر SDK ( بسته به سطح API هدف برنامه خود ) استفاده کنید، استفاده از هر روش یا فیلد غیر SDK همیشه خطر بالای خرابی برنامه شما را به همراه دارد.

اگر مطمئن نیستید که برنامه شما از رابط‌های غیر SDK استفاده می‌کند، می‌توانید برنامه خود را آزمایش کنید تا متوجه شوید. اگر برنامه شما به رابط‌های غیر SDK متکی است، باید برنامه‌ریزی برای مهاجرت به جایگزین‌های SDK را آغاز کنید. با این وجود، ما درک می‌کنیم که برخی از برنامه‌ها موارد استفاده معتبری برای استفاده از رابط‌های غیر SDK دارند. اگر نمی‌توانید جایگزینی برای استفاده از رابط غیر SDK برای یک ویژگی در برنامه خود پیدا کنید، باید یک API عمومی جدید درخواست کنید .

برای کسب اطلاعات بیشتر در مورد تغییرات این نسخه از اندروید، به «به‌روزرسانی محدودیت‌های رابط‌های غیر SDK در اندروید ۱۲» مراجعه کنید. برای کسب اطلاعات بیشتر در مورد رابط‌های غیر SDK به طور کلی، به «محدودیت‌های رابط‌های غیر SDK» مراجعه کنید.