این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

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

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

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

تجربه کاربری

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

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

برای برنامه‌هایی که Android 12 را هدف قرار می‌دهند، اعلان‌هایی با نمای محتوای سفارشی دیگر از منطقه اعلان کامل استفاده نمی‌کنند. در عوض، سیستم یک الگوی استاندارد را اعمال می کند. این الگو تضمین می‌کند که اعلان‌های سفارشی مانند سایر اعلان‌ها در همه حالت‌ها، تزئینات مشابهی دارند، مانند نماد اعلان و امکانات توسعه (در حالت جمع‌شده) و نماد اعلان، نام برنامه، و هزینه فرو ریختن (در حالت گسترش). این رفتار تقریباً مشابه رفتار Notification.DecoratedCustomViewStyle است.

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

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

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

تغییر در Android 12 بر برنامه‌هایی تأثیر می‌گذارد که زیر کلاس‌های سفارشی Notification.Style را تعریف می‌کنند یا از روش‌های Notification.Builder استفاده می‌کنند setCustomContentView(RemoteViews) ، setCustomBigContentView(RemoteViews) و setCustomHeadsUpContentView(RemoteViews)

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

فعال کردن تغییر اعلان‌های سفارشی:
1. برای فعال کردن رفتار جدید، targetSdkVersion برنامه خود را به S تغییر دهید.
2. دوباره کامپایل کنید.
3. برنامه خود را روی دستگاه یا شبیه ساز دارای اندروید 12 نصب کنید.
همه اعلان‌هایی را که از نماهای سفارشی استفاده می‌کنند تست کنید، مطمئن شوید که در سایه همانطور که انتظار دارید به نظر می‌رسند. در حین آزمایش، این نکات را در نظر بگیرید و تنظیمات لازم را انجام دهید:
- ابعاد نماهای سفارشی تغییر کرده است. به طور کلی ارتفاعی که برای اعلان های سفارشی در نظر گرفته می شود کمتر از قبل است. در حالت جمع‌شده، حداکثر ارتفاع محتوای سفارشی از 106dp به 48dp کاهش یافته است. همچنین فضای افقی کمتری وجود دارد.
- همه اعلان‌ها برای برنامه‌هایی که Android 12 را هدف قرار می‌دهند قابل ارتقا هستند. معمولاً، این بدان معناست که اگر از setCustomContentView استفاده می‌کنید، می‌خواهید از setBigCustomContentView نیز استفاده کنید تا مطمئن شوید که حالت‌های جمع‌شده و بازشده سازگار هستند.
- برای اطمینان از اینکه وضعیت "Heads Up" همانطور که انتظار دارید به نظر می رسد، فراموش نکنید که اهمیت کانال اعلان را به "HIGH" (بالا رفتن روی صفحه) ببرید.

تأیید پیوندهای برنامه Android تغییر می کند

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

اگر برای باز کردن پیوندهای وب در برنامه خود به تأیید پیوند برنامه Android متکی هستید، بررسی کنید هنگام افزودن فیلترهای هدف برای تأیید پیوند برنامه Android از قالب صحیح استفاده کنید. به ویژه، مطمئن شوید که این فیلترهای هدف شامل دسته BROWSABLE هستند و از طرح https پشتیبانی می کنند.

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

بهبود رفتار تصویر در تصویر

اندروید 12 بهبودهای رفتاری را برای حالت تصویر در تصویر (PiP) معرفی می‌کند و بهبودهای زیبایی را برای انیمیشن‌های انتقالی برای ناوبری حرکتی و ناوبری مبتنی بر عنصر توصیه می‌کند.

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

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

در اندروید 12 نمای نان تست دوباره طراحی شده است. نان تست ها اکنون به دو خط متن محدود شده اند و نماد برنامه را در کنار متن نشان می دهند.

تصویر دستگاه Android که یک پنجره بازشو با خواندن «ارسال پیام» در کنار نماد برنامه نشان می‌دهد

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

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

مکان تقریبی

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

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

مؤلفه WebView Android بر اساس Chromium است، پروژه منبع باز که مرورگر کروم Google را تقویت می کند. Chromium برای ارائه امنیت و حریم خصوصی بیشتر و ارائه شفافیت و کنترل بیشتر به کاربران، تغییراتی را در مدیریت کوکی‌های شخص ثالث ایجاد کرد. با شروع اندروید 12، زمانی که برنامه‌ها اندروید 12 (سطح API 31) یا بالاتر را هدف قرار می‌دهند، این تغییرات در WebView نیز گنجانده می‌شود.

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

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

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

برای راهنمایی کامل برای توسعه دهندگان وب در مورد این تغییرات، به کوکی های SameSite توضیح داده شده و طرحواره SameSite مراجعه کنید.

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

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

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

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

با تغییر دادن پرچم رابط کاربری webview-enable-modern-cookie-same-site در ابزارهای توسعه WebView ، رفتارهای SameSite را به صورت دستی در دستگاه آزمایشی فعال کنید.
این رویکرد به شما امکان می‌دهد روی هر دستگاهی که دارای Android نسخه 5.0 (سطح API 21) یا بالاتر است - از جمله Android 12 - و WebView نسخه 89.0.4385.0 یا بالاتر تست کنید.
برنامه خود را برای هدف قرار دادن Android 12 (سطح API 31) توسط targetSdkVersion کامپایل کنید.
اگر از این روش استفاده می کنید، باید از دستگاهی استفاده کنید که اندروید 12 را اجرا می کند.

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

منابع دیگر

برای اطلاعات بیشتر درباره رفتارهای مدرن SameSite و عرضه به Chrome و WebView، از صفحه Chromium SameSite Updates دیدن کنید. اگر اشکالی در WebView یا Chromium پیدا کردید، می‌توانید آن را در ردیاب عمومی مشکلات Chromium گزارش کنید.

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

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

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

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

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

در راهنمای مربوط به خواب زمستانی برنامه بیشتر بیاموزید.

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

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

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

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

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

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

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

اگر برنامه شما Android 12 یا بالاتر را هدف قرار می‌دهد و شامل فعالیت‌ها ، سرویس‌ها یا گیرنده‌های پخش است که از فیلترهای هدف استفاده می‌کنند، باید مشخصه 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: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.

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

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

تغییرپذیری مقاصد معلق

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

تغییر تغییرپذیری قصد معلق را آزمایش کنید

برای تعیین اینکه آیا برنامه شما اعلامیه های تغییرپذیری را ندارد، به دنبال هشدار پرز زیر در Android Studio باشید:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

هدف ناامن راه اندازی شد

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

عملکرد

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

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

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

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

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

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

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

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

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

در صفحه تنظیمات گزینه‌های برنامه‌نویس ، تغییرات سازگاری برنامه را انتخاب کنید. در صفحه نمایش داده شده، روی نام برنامه خود ضربه بزنید، سپس REQUIRE_EXACT_ALARM_PERMISSION را خاموش کنید.
در یک پنجره ترمینال در ماشین توسعه خود، دستور زیر را اجرا کنید:
```
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
```

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

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

برای بهبود عملکرد برنامه و UX، برنامه‌هایی که Android 12 یا بالاتر را هدف قرار می‌دهند، نمی‌توانند فعالیت‌ها را از سرویس‌ها یا گیرنده‌های پخشی که به عنوان ترامپولین اعلان استفاده می‌شوند شروع کنند. به عبارت دیگر، پس از ضربه زدن کاربر بر روی یک اعلان یا یک دکمه عمل در اعلان، برنامه شما نمی تواند 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 اجرا می‌شوند و آن‌ها را هدف قرار می‌دهند (سطح API 31) وجود دارد. پشتیبان گیری و بازیابی اندروید دارای دو شکل است:

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

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

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

برای برنامه‌هایی که روی Android 12 و بالاتر اجرا می‌شوند و آن‌ها را هدف قرار می‌دهند:

مشخص کردن شامل و حذف قوانین با مکانیسم پیکربندی XML بر انتقال‌های D2D تأثیری ندارد، اگرچه همچنان بر پشتیبان‌گیری و بازیابی مبتنی بر ابر تأثیر می‌گذارد (مانند پشتیبان‌گیری Google Drive). برای تعیین قوانین برای انتقال D2D، باید از پیکربندی جدید که در بخش بعدی توضیح داده شده است استفاده کنید.
در دستگاه‌های برخی از سازندگان دستگاه، مشخص کردن android:allowBackup="false" پشتیبان‌گیری در Google Drive را غیرفعال می‌کند، اما انتقال D2D را برای برنامه غیرفعال نمی‌کند.

قالب جدید شامل و حذف

برنامه‌هایی که روی Android 12 و بالاتر اجرا می‌شوند و آن‌ها را هدف قرار می‌دهند، از فرمت متفاوتی برای پیکربندی XML استفاده می‌کنند. این قالب تفاوت بین پشتیبان‌گیری Google Drive و انتقال D2D را آشکار می‌کند، زیرا از شما می‌خواهد که قوانین را به‌طور جداگانه برای پشتیبان‌گیری ابری و برای انتقال D2D مشخص کنید.

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

فرمت XML تغییر می کند

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

<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 12 یا بالاتر، منطق برنامه خود را به‌روزرسانی کنید. به جای اعلام مجموعه قدیمی از مجوزهای بلوتوث ، مجموعه مدرنتری از مجوزهای بلوتوث را اعلام کنید.

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

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

سازگاری

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

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

برای ارائه تجربه کاربری بهتر در دستگاه‌هایی که از شبکه‌های Wi-Fi همزمان دوگانه پشتیبانی می‌کنند، توصیه می‌کنیم همه برنامه‌ها - به‌ویژه برنامه‌هایی که اتصالات همتا به همتا را راه‌اندازی می‌کنند - از تماس با WifiManager.getConnectionInfo() خارج شوند و در عوض از NetworkCallback.onCapabilitiesChanged() استفاده کنند. برای دریافت تمام اشیاء WifiInfo که مطابق با NetworkRequest هستند که برای ثبت NetworkCallback استفاده می شود. getConnectionInfo() از اندروید 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;
    ...
  }
  ...
};

API بومی mDNSResponder

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

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

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

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

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

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

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

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

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

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

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