การเปลี่ยนแปลงลักษณะการทำงาน: แอปที่กำหนดเป้าหมายเป็น Android 12

Android 12 มีการเปลี่ยนแปลงลักษณะการทำงานเช่นเดียวกับรุ่นก่อนหน้านี้ อาจส่งผลกระทบต่อแอปของคุณ การเปลี่ยนแปลงลักษณะการทำงานต่อไปนี้มีผลเฉพาะแอปเท่านั้น ที่กำหนดเป้าหมายเป็น Android 12 ขึ้นไป หากแอปของคุณคือ ที่กำหนดเป้าหมายเป็น Android 12 คุณควรแก้ไขแอปเพื่อรองรับลักษณะการทำงานเหล่านี้ อย่างเหมาะสม และเหมาะสม

โปรดตรวจสอบรายการการเปลี่ยนแปลงลักษณะการทำงานที่มีผลต่อแอปทั้งหมดด้วย ที่ทำงานใน Android 12

ประสบการณ์ของผู้ใช้

การแจ้งเตือนที่กำหนดเอง

Android 12 เปลี่ยนรูปลักษณ์และลักษณะการทำงานของการแจ้งเตือนที่กำหนดเองอย่างเต็มรูปแบบ ก่อนหน้านี้การแจ้งเตือนที่กำหนดเองจะใช้พื้นที่การแจ้งเตือนทั้งหมดได้ และระบุเลย์เอาต์และสไตล์ของตัวเอง ซึ่งส่งผลให้เกิดรูปแบบต่อต้าน อาจทำให้ผู้ใช้สับสนหรือทำให้เกิดปัญหาความเข้ากันได้ของเลย์เอาต์ในอุปกรณ์ที่แตกต่างกัน

สำหรับแอปที่กำหนดเป้าหมายเป็น Android 12 การแจ้งเตือนที่มีมุมมองเนื้อหาที่กำหนดเองจะไม่ ใช้พื้นที่การแจ้งเตือนแบบเต็มนานขึ้น แต่ระบบจะใช้มาตรฐาน เทมเพลต เทมเพลตนี้จะตรวจสอบว่าการแจ้งเตือนที่กำหนดเอง การตกแต่งเหมือนการแจ้งเตือนอื่นๆ ในทุกรัฐ เช่น ไอคอนการแจ้งเตือน และความสามารถในการขยาย (ในสถานะยุบ) และไอคอนการแจ้งเตือน ชื่อแอป และราคายุบ (ในสถานะการขยาย) ลักษณะการทำงานนี้ เกือบเหมือนกันทุกประการกับพฤติกรรมของ Notification.DecoratedCustomViewStyle

ด้วยวิธีนี้ Android 12 จะช่วยให้การแจ้งเตือนทั้งหมดมีรูปลักษณ์ที่สอดคล้องกันและง่ายต่อการ โดยใช้การขยายการแจ้งเตือนที่คุ้นเคยและค้นพบได้สำหรับผู้ใช้

ภาพประกอบต่อไปนี้แสดงการแจ้งเตือนที่กำหนดเองในเทมเพลตมาตรฐาน

ตัวอย่างต่อไปนี้แสดงลักษณะการแสดงผลการแจ้งเตือนที่กำหนดเองเมื่อยุบ และสถานะที่ขยาย:

การเปลี่ยนแปลงใน Android 12 ส่งผลต่อแอปที่กำหนดคลาสย่อยที่กำหนดเองของ Notification.Style หรือใช้ วิธีการของ Notification.Builder setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) และ setCustomHeadsUpContentView(RemoteViews)

หากแอปใช้การแจ้งเตือนที่กำหนดเองอย่างเต็มรูปแบบ เราขอแนะนำให้ทดสอบด้วย เทมเพลตใหม่โดยเร็วที่สุด

1. เปิดใช้การเปลี่ยนแปลงการแจ้งเตือนที่กำหนดเอง

   1. เปลี่ยน targetSdkVersion ของแอปเป็น S เพื่อเปิดใช้ลักษณะการทำงานใหม่
   2. คอมไพล์ซ้ำ
   3. ติดตั้งแอปในอุปกรณ์หรือโปรแกรมจําลองที่ใช้ Android 12

2. ทดสอบการแจ้งเตือนทั้งหมดที่ใช้มุมมองที่กำหนดเองเพื่อให้มั่นใจว่าระบบจะแสดงมุมมองในแบบของคุณ อยู่ในเฉดสี โปรดคํานึงถึงข้อควรพิจารณาเหล่านี้ขณะทดสอบ และทำการปรับเปลี่ยนที่จำเป็น ดังนี้

   • มีการเปลี่ยนแปลงมิติข้อมูลของมุมมองที่กำหนดเอง โดยทั่วไป ความสูง การแจ้งเตือนที่กำหนดเองน้อยลงกว่าเดิม ในช่องยุบ ความสูงสูงสุดของเนื้อหาที่กำหนดเองลดลงจาก 106dp ถึง 48dp นอกจากนี้ยังมีพื้นที่ว่างแนวนอนน้อยลงด้วย

   • การแจ้งเตือนทั้งหมดจะขยายได้สำหรับแอปที่กำหนดเป้าหมายเป็น Android 12 ซึ่งโดยทั่วไปจะหมายถึงการใช้ setCustomContentView ซึ่งคุณจะต้องใช้ setBigCustomContentView ด้วย เพื่อให้แน่ใจว่าสถานะที่ยุบและขยายจะสอดคล้องกัน

   • หากต้องการให้ปุ่ม "แจ้งเตือนให้ดูทาง" สถานะเป็นไปตามที่คุณคาดหวัง อย่าลืม เพื่อเพิ่มความสำคัญของช่องทางการแจ้งเตือนเป็น "HIGH" (แสดงเมื่อ หน้าจอ)

การเปลี่ยนแปลงเกี่ยวกับการยืนยันของ Android App Link

ในแอปที่กำหนดเป้าหมายเป็น Android 12 ขึ้นไป ระบบจะกำหนดให้ การเปลี่ยนแปลงหลายอย่างกับ Android App Link ยืนยันแล้ว เหล่านี้ จะเพิ่มความน่าเชื่อถือของประสบการณ์การลิงก์แอป และให้ แก่นักพัฒนาแอปและผู้ใช้ปลายทาง

หากคุณใช้การยืนยัน Android App Link เพื่อเปิดเว็บลิงก์ในแอป ตรวจสอบว่าคุณใช้รูปแบบที่ถูกต้องเมื่อเพิ่ม Intent ตัวกรองสำหรับ การยืนยัน Android App Link โดยเฉพาะอย่างยิ่ง ดูให้แน่ใจว่าเจตนาเหล่านี้ ตัวกรองจะรวมหมวดหมู่ BROWSABLE และรองรับรูปแบบ https

คุณยังสามารถดำเนินการด้วยตนเอง ยืนยัน ลิงก์ของแอปเพื่อทดสอบความน่าเชื่อถือของการประกาศ

การปรับปรุงลักษณะการทำงานของการแสดงภาพซ้อนภาพ

Android 12 มีการปรับปรุงลักษณะการทำงานสำหรับโหมดการแสดงภาพซ้อนภาพ (PIP) และการปรับปรุงที่แนะนำเกี่ยวกับลักษณะการเปลี่ยนหน้า ภาพเคลื่อนไหวสำหรับท่าทางสัมผัสทั้ง 2 แบบ และการนำทางตามองค์ประกอบ

โปรดดูการแสดงภาพซ้อนภาพ ที่ดีขึ้น

การออกแบบ Toast ใหม่

ใน Android 12 มุมมองข้อความโทสต์จะ โฉมใหม่ ขณะนี้ข้อความโทสต์จำกัดข้อความสองบรรทัด และแสดงแอปพลิเคชัน ข้างข้อความ

ดูรายละเอียดเพิ่มเติมได้ที่ภาพรวมของข้อความโทสต์

ความปลอดภัยและความเป็นส่วนตัว

ตำแหน่งโดยประมาณ

ในอุปกรณ์ที่ใช้ Android 12 ขึ้นไป ผู้ใช้สามารถส่งคำขอ ตำแหน่งโดยประมาณ ความแม่นยำของแอป

คุกกี้ SameSite ที่ทันสมัยใน WebView

คอมโพเนนต์ WebView ของ Android ใช้ Chromium โครงการโอเพนซอร์สที่ขับเคลื่อนเบราว์เซอร์ Chrome ของ Google เปิดตัว Chromium การเปลี่ยนแปลงการจัดการคุกกี้ของบุคคลที่สามเพื่อเพิ่มความปลอดภัยและ ความเป็นส่วนตัว และมอบความโปร่งใสและการควบคุมให้แก่ผู้ใช้มากขึ้น เริ่มตั้งแต่ Android 12 การเปลี่ยนแปลงเหล่านี้จะรวมอยู่ใน WebView ด้วยเมื่อกำหนดเป้าหมายแอป Android 12 (API ระดับ 31) ขึ้นไป

แอตทริบิวต์ SameSite ของคุกกี้ควบคุมว่าจะส่งพร้อมกับ หรือเฉพาะกับคำขอเว็บไซต์เดียวกัน การคุ้มครองความเป็นส่วนตัวดังต่อไปนี้ ปรับปรุงการจัดการเริ่มต้นสำหรับคุกกี้ของบุคคลที่สาม และช่วยปกป้อง ต่อต้านการแชร์ข้ามเว็บไซต์โดยไม่ตั้งใจ

• คุกกี้ที่ไม่มีแอตทริบิวต์ SameSite จะถือว่าเป็น SameSite=Lax
• คุกกี้ที่มี SameSite=None จะต้องระบุแอตทริบิวต์ Secure ด้วย ซึ่งหมายความว่า มิติข้อมูลเหล่านี้ต้องการบริบทที่ปลอดภัยและควรส่งผ่าน HTTPS
• ตอนนี้ลิงก์ระหว่างเวอร์ชัน HTTP และ HTTPS ของเว็บไซต์ถือเป็นแบบข้ามเว็บไซต์ ดังนั้น จะไม่มีการส่งคุกกี้เว้นแต่จะมีการทำเครื่องหมายอย่างเหมาะสมว่า SameSite=None; Secure

สำหรับนักพัฒนาซอฟต์แวร์ คำแนะนำทั่วไปคือให้ระบุคุกกี้ข้ามเว็บไซต์ ทรัพยากร Dependency ในโฟลว์ผู้ใช้ที่สำคัญ และตรวจสอบว่า SameSite ด้วยค่าที่เหมาะสมตามที่จำเป็นอย่างชัดเจน คุณต้อง ระบุคุกกี้ที่ได้รับอนุญาตให้ทำงานในเว็บไซต์อย่างชัดเจน หรือ ในการไปยังส่วนต่างๆ ของเว็บไซต์เดียวกันที่เปลี่ยนจาก HTTP ไปเป็น HTTPS

ดูคำแนะนำทั้งหมดสำหรับนักพัฒนาเว็บเกี่ยวกับการเปลี่ยนแปลงเหล่านี้ได้ที่ SameSite Cookies อธิบายและแบบแผน SameSite

ทดสอบลักษณะการทำงานของ SameSite ในแอปของคุณ

หากแอปใช้ WebView หรือหากคุณจัดการเว็บไซต์หรือบริการที่ใช้ และคุกกี้ เราขอแนะนำให้ทดสอบโฟลว์ใน Android 12 WebView หากคุณพบปัญหา คุณอาจต้องอัปเดตคุกกี้เพื่อรองรับ ลักษณะการทำงานของ SameSite

คอยระวังปัญหาในการเข้าสู่ระบบและเนื้อหาที่ฝัง รวมถึงขั้นตอนการลงชื่อเข้าใช้ และขั้นตอนการตรวจสอบสิทธิ์อื่นๆ ที่ผู้ใช้เริ่มต้นที่ไม่ปลอดภัย และเปลี่ยนไปยังหน้าที่ปลอดภัย

หากต้องการทดสอบแอปกับ WebView คุณต้องเปิดใช้ลักษณะการทำงาน SameSite แบบใหม่สำหรับ ที่คุณต้องการทดสอบโดยทำตามขั้นตอนใดขั้นตอนหนึ่งต่อไปนี้

• เปิดใช้ลักษณะการทำงาน SameSite ในอุปกรณ์ทดสอบด้วยตนเองโดยสลับแฟล็ก UI Webview-enable-modern-cookie-same-site ในเครื่องมือสำหรับนักพัฒนาเว็บ WebView

  วิธีนี้ช่วยให้คุณทดสอบในอุปกรณ์ใดก็ได้ที่ใช้ Android 5.0 (API ระดับ 21) ขึ้นไป รวมถึง Android 12 และ WebView เวอร์ชัน 89.0.4385.0 หรือสูงกว่า

• คอมไพล์แอปเพื่อกำหนดเป้าหมายเป็น Android 12 (API ระดับ 31) ตาม targetSdkVersion

  หากใช้วิธีนี้ คุณต้องใช้อุปกรณ์ที่เรียกใช้ Android 12

โปรดดูข้อมูลเกี่ยวกับการแก้ไขข้อบกพร่องระยะไกลสำหรับ WebView บน Android ที่เริ่มต้นใช้งาน ด้วยการแก้ไขข้อบกพร่องระยะไกลกับอุปกรณ์ Android

ทรัพยากรอื่นๆ

ดูข้อมูลเพิ่มเติมเกี่ยวกับลักษณะการทำงานสมัยใหม่ของ SameSite และการเปิดตัวใน Chrome และ WebView โปรดไปที่การอัปเดต Chromium SameSite หากคุณพบข้อบกพร่องใน WebView หรือ Chromium คุณสามารถรายงานปัญหานี้ได้ในปัญหาเกี่ยวกับ Chromium แท็กติดตาม

เซ็นเซอร์ตรวจจับการเคลื่อนไหวมีการจำกัดอัตราคำขอ

เพื่อปกป้องข้อมูลที่อาจมีความละเอียดอ่อนเกี่ยวกับผู้ใช้ หากแอปกำหนดเป้าหมาย Android 12 ขึ้นไป ระบบจะจำกัดการรีเฟรช อัตราการส่งข้อมูลจากเซ็นเซอร์ตรวจจับการเคลื่อนไหวและเซ็นเซอร์ตำแหน่งบางประเภท

ดูข้อมูลเพิ่มเติมเกี่ยวกับเซ็นเซอร์ การจำกัดอัตราคำขอ

การพักใช้งานแอป

Android 12 จะขยายออกเมื่อมีการรีเซ็ตสิทธิ์อัตโนมัติ พฤติกรรม ที่เปิดตัวไปใน Android 11 (API ระดับ 30) หากแอปกำหนดเป้าหมาย Android 12 และผู้ใช้ไม่ได้โต้ตอบกับแอปของคุณมาระยะหนึ่งแล้ว ระบบจะรีเซ็ตสิทธิ์ใดๆ ที่ให้โดยอัตโนมัติ และวางแอปของคุณลงใน การพักใช้งาน

เรียนรู้เพิ่มเติมในคำแนะนำเกี่ยวกับแอป การพักใช้งาน

การประกาศการระบุแหล่งที่มาในการตรวจสอบการเข้าถึงข้อมูล

API การตรวจสอบการเข้าถึงข้อมูลที่เปิดตัวใน Android 11 (API ระดับ 30) ช่วยให้คุณ เพื่อสร้างการระบุแหล่งที่มา โดยอิงตาม Use Case ของแอป แท็กเหล่านี้ช่วยให้ทราบ ได้ง่ายขึ้นว่าส่วนใดของ แอปของคุณเข้าถึงข้อมูลบางประเภท

หากแอปกำหนดเป้าหมายเป็น Android 12 ขึ้นไป คุณต้องประกาศรายการเหล่านี้ แท็กการระบุแหล่งที่มาใน ไฟล์ Manifest ของแอป

ข้อจำกัดการสำรองข้อมูล ADB

เพื่อช่วยปกป้องข้อมูลส่วนตัวของแอปส่วนตัว Android 12 ได้เปลี่ยนลักษณะการทำงานเริ่มต้นของ คำสั่ง adb backup สำหรับแอปที่กำหนดเป้าหมายเป็น Android 12 (API ระดับ 31) ขึ้นไป เมื่อผู้ใช้เรียกใช้คำสั่ง adb backup ระบบจะยกเว้นข้อมูลแอปออกจากรายการอื่นๆ ข้อมูลระบบที่ส่งออกจากอุปกรณ์

หากเวิร์กโฟลว์การทดสอบหรือการพัฒนาต้องใช้ข้อมูลแอปโดยใช้ adb backup ตอนนี้คุณเลือกใช้การส่งออกข้อมูลของแอปได้โดยการตั้งค่า android:debuggable ไปยัง true ในไฟล์ Manifest ของแอป

การส่งออกคอมโพเนนต์ที่ปลอดภัยขึ้น

หากแอปกำหนดเป้าหมายเป็น Android 12 ขึ้นไปและมี กิจกรรม บริการหรือประกาศ รีซีฟเวอร์ที่ใช้ความตั้งใจ คุณต้องทำดังนี้ ประกาศ แอตทริบิวต์ 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>

ข้อความใน Android Studio

หากแอปมีกิจกรรม บริการ หรือ Broadcast Receiver ที่ใช้ ตัวกรอง Intent แต่ไม่ได้ประกาศ android:exported คำเตือนต่อไปนี้ จะปรากฏขึ้น โดยขึ้นอยู่กับเวอร์ชันของ Android Studio ที่คุณใช้ ดังนี้

Android Studio 2020.3.1 Canary 11 ขึ้นไป

ข้อความต่อไปนี้จะปรากฏขึ้น

1. คำเตือนของ Lint ต่อไปนี้จะปรากฏในไฟล์ Manifest

   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.
   

Android Studio เวอร์ชันเก่า

หากคุณพยายามติดตั้งแอป 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 ที่รอดำเนินการ

หากแอปกำหนดเป้าหมายเป็น Android 12 คุณต้องระบุ ความสามารถในการเปลี่ยนแปลงได้ ออบเจ็กต์ PendingIntent แต่ละรายการที่ การสร้างแอป ข้อกำหนดเพิ่มเติมนี้ช่วยปรับปรุงความปลอดภัยของแอป

ทดสอบการเปลี่ยนแปลงการเปลี่ยนแปลงของ Intent ที่รอดำเนินการ

หากต้องการดูว่าแอปไม่มีการประกาศการเปลี่ยนแปลงหรือไม่ ให้มองหา ต่อไปนี้คำเตือนของ Lint ใน Android Studio

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

การเปิดตัว Intent ที่ไม่ปลอดภัย

เพื่อปรับปรุงความปลอดภัยของแพลตฟอร์ม Android 12 ขึ้นไปจะมี ฟีเจอร์การแก้ไขข้อบกพร่องที่ตรวจจับการเปิดที่ไม่ปลอดภัยของ Intent วันและเวลา ระบบจะตรวจพบการเปิดที่ไม่ปลอดภัย เกิดการละเมิด StrictMode

ประสิทธิภาพ

การจำกัดการเปิดตัวบริการที่ทำงานอยู่เบื้องหน้า

แอปที่กำหนดเป้าหมายเป็น Android 12 ขึ้นไปจะเริ่มต้นในเบื้องหน้าไม่ได้ บริการขณะที่เรียกใช้ใน พื้นหลัง ยกเว้นรายการพิเศษ กรณี หากแอปพยายามจะเริ่มต้นบริการที่ทำงานอยู่เบื้องหน้าขณะทำงานใน จะมีข้อยกเว้น (ยกเว้นกรณีพิเศษบางกรณี)

ลองใช้ WorkManager เพื่อกำหนดเวลาและเริ่มต้น Expedited ที่ทำงาน ในขณะที่แอปของคุณทำงานในพื้นหลัง สำหรับการดำเนินการที่ต้องคำนึงถึงเวลาเป็นสำคัญ เริ่มต้นบริการที่ทำงานอยู่เบื้องหน้าภายใน การปลุก

สิทธิ์การปลุกในเวลาที่แน่นอน

หากต้องการสนับสนุนให้แอปประหยัดทรัพยากรของระบบ แอปที่กำหนดเป้าหมาย Android 12 ขึ้นไปและตั้งค่าแบบตรงทั้งหมด นาฬิกาปลุกต้องมีสิทธิ์เข้าถึง "นาฬิกาปลุกและ ช่วยเตือน" ที่ปรากฏภายในหน้าจอสิทธิ์เข้าถึงพิเศษของแอปใน การตั้งค่าระบบ

หากต้องการรับสิทธิ์เข้าถึงพิเศษของแอปนี้ โปรดขอ SCHEDULE_EXACT_ALARM ในไฟล์ Manifest

ควรใช้การปลุกในเวลาที่แน่นอนสำหรับฟีเจอร์ที่แสดงต่อผู้ใช้เท่านั้น ดูข้อมูลเพิ่มเติมเกี่ยวกับ กรณีการใช้งานที่ยอมรับได้สำหรับการตั้งค่า การปลุก

ปิดใช้การเปลี่ยนแปลงลักษณะการทำงาน

ขณะเตรียมแอปเพื่อกําหนดเป้าหมายเป็น Android 12 คุณสามารถชั่วคราวได้ ปิดใช้การเปลี่ยนแปลงลักษณะการทำงานใน build ที่แก้ไขข้อบกพร่องได้ของคุณ ตัวแปรเพื่อวัตถุประสงค์ในการทดสอบ โดยกรอกข้อมูลใน ทำงานใดงานหนึ่งต่อไปนี้

• ในหน้าจอการตั้งค่าตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ ให้เลือกความเข้ากันได้ของแอป การเปลี่ยนแปลง แตะชื่อแอปในหน้าจอที่ปรากฏขึ้น แล้วปิด REQUIRE_EXACT_ALARM_PERMISSION

• ในหน้าต่างเทอร์มินัลบนเครื่องพัฒนา ให้เรียกใช้คำสั่งต่อไปนี้

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

ข้อจำกัดแทรมโพลีนการแจ้งเตือน

เมื่อผู้ใช้โต้ตอบกับ การแจ้งเตือน บางแอปจะตอบสนองต่อ การแตะโดยเปิดแอป ซึ่งจะเริ่มต้น กิจกรรมที่ผู้ใช้ดูและโต้ตอบด้วยในท้ายที่สุด คอมโพเนนต์ของแอปนี้คือ หรือที่เรียกว่าแทรมโพลีนแจ้งเตือน

แอปที่กำหนดเป้าหมายเป็น Android 12 หรือ ระดับที่สูงกว่าจะไม่สามารถเริ่มกิจกรรมจากบริการ หรือ Broadcast Receiver ที่ใช้เป็น แทรมโพลีนการแจ้งเตือน กล่าวคือ หลังจากที่ผู้ใช้แตะการแจ้งเตือน หรือปุ่มดำเนินการภายใน การแจ้งเตือนนั้น แอปของคุณไม่สามารถเรียก startActivity() ภายในบริการหรือ Broadcast Receiver

เมื่อแอปของคุณพยายามเริ่มกิจกรรมจากบริการหรือ Broadcast Receiver ที่ทำหน้าที่เป็นแทรมโพลีนการแจ้งเตือน ระบบจะป้องกันไม่ให้กิจกรรม เริ่มต้น และข้อความต่อไปนี้จะปรากฏใน Logcat

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

ระบุว่าองค์ประกอบใดของแอปที่ทำหน้าที่เป็นแทรมโพลีนการแจ้งเตือน

เมื่อทดสอบแอป คุณจะระบุการแจ้งเตือนได้หลังจากแตะการแจ้งเตือน บริการหรือ Broadcast Receiver ทำหน้าที่เป็นแทรมโพลีนการแจ้งเตือนในแอปของคุณ ในการดำเนินการนี้ ให้ดูเอาต์พุตของคำสั่งเทอร์มินัลต่อไปนี้

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

ส่วนของเอาต์พุตจะมีข้อความ "NotifInteractionLog" ส่วนนี้ มีข้อมูลที่จำเป็นต่อการระบุคอมโพเนนต์ที่เริ่ม ที่เกิดจากการแตะการแจ้งเตือน

อัปเดตแอป

หากแอปเริ่มกิจกรรมจากบริการหรือ Broadcast Receiver ที่ทำหน้าที่เป็น แทรมโพลีนการแจ้งเตือน ให้ทำตามขั้นตอนการย้ายข้อมูลต่อไปนี้

1. สร้างออบเจ็กต์ PendingIntent ที่ เชื่อมโยงกับกิจกรรมที่ผู้ใช้เห็นหลังจากแตะ การแจ้งเตือน
2. ใช้ออบเจ็กต์ PendingIntent ที่สร้างไว้ในขั้นตอนก่อนหน้าเป็นส่วนหนึ่งของ ของการสร้าง

ในการระบุที่มาของกิจกรรม เพื่อที่จะทำการบันทึก ตัวอย่างเช่น ใช้ตัวเลือกเพิ่มเติมเมื่อโพสต์การแจ้งเตือน สำหรับการบันทึกแบบรวมศูนย์ ให้ใช้ ActivityLifecycleCallbacks หรือผู้สังเกตการณ์วงจรของ Jetpack

สลับลักษณะการทำงาน

ขณะทดสอบแอปเวอร์ชันที่แก้ไขข้อบกพร่องได้ คุณจะเปิดและปิดใช้ฟีเจอร์นี้ได้ การจำกัดโดยใช้แฟล็กความเข้ากันได้ของแอป NOTIFICATION_TRAMPOLINE_BLOCK

การสำรองและคืนค่า

มีการเปลี่ยนแปลงวิธีการทำงานของการสำรองและกู้คืนข้อมูลในแอปที่ทำงานและกำหนดเป้าหมาย Android 12 (API ระดับ 31) การสำรองและกู้คืนข้อมูล Android มี 2 รูปแบบดังนี้

• การสำรองข้อมูลในระบบคลาวด์: ระบบจะเก็บข้อมูลผู้ใช้ไว้ใน Google ไดรฟ์ของผู้ใช้ สามารถคืนค่าได้ในภายหลังบนอุปกรณ์นั้นหรืออุปกรณ์เครื่องใหม่
• การโอนข้อมูลไปยังอุปกรณ์ (D2D): ระบบจะส่งข้อมูลผู้ใช้ไปยัง อุปกรณ์ใหม่ของผู้ใช้จากอุปกรณ์เครื่องเก่า เช่น การใช้สาย

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีสำรองและกู้คืนข้อมูลได้ที่สำรองข้อมูลผู้ใช้ ข้อมูลด้วยการสำรองข้อมูลอัตโนมัติและสำรองคู่คีย์-ค่าด้วย Android Backup Service

การเปลี่ยนแปลงฟังก์ชันการโอน D2D

สำหรับแอปที่ทำงานและกำหนดเป้าหมายเป็น Android 12 ขึ้นไป ให้ทำดังนี้

• การระบุกฎที่รวมและยกเว้นด้วย XML กลไกการกำหนดค่าจะไม่มีผลกับการโอน D2D ส่งผลต่อการสำรองและกู้คืนข้อมูลในระบบคลาวด์ (เช่น การสำรองข้อมูล Google ไดรฟ์) ถึง ระบุกฎสำหรับการโอน D2D คุณต้องใช้การกำหนดค่าใหม่ที่ครอบคลุม ในส่วนถัดไป

• ในอุปกรณ์จากผู้ผลิตอุปกรณ์บางราย โดยมีการระบุ android:allowBackup="false" ปิดใช้การสำรองข้อมูลไปยัง Google ไดรฟ์ แต่ ไม่ปิดใช้การโอนแบบ D2D สำหรับแอป

รูปแบบ "รวม" และ "ยกเว้น" ใหม่

แอปที่ใช้และกำหนดเป้าหมายเป็น Android 12 ขึ้นไปจะใช้ รูปแบบอื่นสำหรับการกำหนดค่า XML รูปแบบนี้สร้างความแตกต่าง ระหว่างการสำรองข้อมูล Google ไดรฟ์และการโอน D2D โดยต้องให้คุณดำเนินการ ระบุกฎรวมและยกเว้นแยกต่างหากสำหรับการสำรองข้อมูลระบบคลาวด์และ D2D การโอน

นอกจากนี้ คุณยังใช้เพื่อระบุกฎสำหรับการสำรองข้อมูลได้ ซึ่งในกรณีนี้ ระบบจะไม่สนใจการกำหนดค่าที่ใช้ก่อนหน้านี้ในอุปกรณ์ที่ใช้ Android 12 หรือ สูงขึ้น อุปกรณ์ที่ใช้ Android 11 ยังคงต้องใช้การกำหนดค่าเดิม หรือต่ำกว่า

การเปลี่ยนแปลงรูปแบบ XML

ต่อไปนี้เป็นรูปแบบที่ใช้สำหรับการกำหนดค่าการสำรองและกู้คืนข้อมูลใน Android 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>

สำหรับข้อมูลเพิ่มเติม โปรดดูส่วนที่เกี่ยวข้องใน คำแนะนำในการสำรองข้อมูลผู้ใช้ด้วยการสำรองข้อมูลอัตโนมัติ

Flag ไฟล์ Manifest สำหรับแอป

ชี้แอปไปยังการกำหนดค่า XML ใหม่โดยใช้ แอตทริบิวต์ android:dataExtractionRules ในไฟล์ Manifest เมื่อคุณชี้ไปที่การกำหนดค่า XML ใหม่ ระบบจะละเว้นแอตทริบิวต์ android:fullBackupContent ที่ชี้ไปยังการกำหนดค่าเก่า ในอุปกรณ์ที่ใช้ Android 12 ขึ้นไป ตัวอย่างโค้ดต่อไปนี้แสดง รายการไฟล์ 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>

การเชื่อมต่อ

สิทธิ์การใช้บลูทูธ

Android 12 เปิดตัว BLUETOOTH_SCAN BLUETOOTH_ADVERTISE, และ BLUETOOTH_CONNECT สิทธิ์ สิทธิ์เหล่านี้จะช่วยให้แอปที่กำหนดเป้าหมาย Android 12 เพื่อโต้ตอบกับบลูทูธ อุปกรณ์ โดยเฉพาะสำหรับแอปที่ไม่ ต้องเข้าถึงตำแหน่งของอุปกรณ์

หากต้องการเตรียมอุปกรณ์ให้พร้อมสําหรับการกําหนดเป้าหมายเป็น Android 12 ขึ้นไป ให้อัปเดต ตรรกะของแอปคุณ แทนที่จะประกาศชุดบลูทูธเดิม สิทธิ์ ประกาศว่าชุดบลูทูธที่ทันสมัยกว่า สิทธิ์

การเชื่อมต่อแบบเพียร์ทูเพียร์ + อินเทอร์เน็ตพร้อมกัน

สำหรับแอปที่กำหนดเป้าหมายเป็น Android 12 (API ระดับ 31) ขึ้นไป อุปกรณ์ที่รองรับ การเชื่อมต่อแบบ peer-to-peer และอินเทอร์เน็ตพร้อมกันจะรักษา Wi-Fi พร้อมกันได้ เชื่อมต่อกับทั้งอุปกรณ์เพียร์และเครือข่ายหลักที่ให้บริการอินเทอร์เน็ต ทำให้ผู้ใช้ได้รับประสบการณ์ ที่ราบรื่นยิ่งขึ้น การกำหนดเป้าหมายแอป Android 11 (API ระดับ 30) หรือต่ำกว่ายังคงใช้ลักษณะการทำงานเดิมอยู่ ซึ่ง ยกเลิกการเชื่อมต่อเครือข่าย Wi-Fi หลักก่อนจะเชื่อมต่อกับเครื่องเพียร์ อุปกรณ์

ความเข้ากันได้

WifiManager.getConnectionInfo() สามารถแสดงผล WifiInfo สำหรับ เครือข่ายเดียวเท่านั้น ด้วยเหตุนี้ ลักษณะการทำงานของ API จึงมีการเปลี่ยนแปลงใน โดยใช้วิธีต่อไปนี้ใน Android 12 ขึ้นไป

• หากมีเครือข่าย Wi-Fi เพียงเครือข่ายเดียว ระบบจะส่ง WifiInfo กลับมาให้
• หากมีเครือข่าย Wi-Fi มากกว่า 1 เครือข่ายและแอปการโทรทริกเกอร์ การเชื่อมต่อแบบเพียร์ทูเพียร์ WifiInfo ที่เกี่ยวข้องกับอุปกรณ์เพียร์คือ ส่งคืนแล้ว
• หากมีเครือข่าย Wi-Fi มากกว่า 1 เครือข่ายและแอปการโทรไม่สามารถใช้งานได้ จะทำการเชื่อมต่อแบบเพียร์ทูเพียร์ ซึ่งเป็นการเชื่อมต่อหลักของอินเทอร์เน็ต ส่งคืน WifiInfo แล้ว

เพื่อให้ประสบการณ์ของผู้ใช้ที่ดียิ่งขึ้นบนอุปกรณ์ที่รองรับการใช้งานพร้อมกันทั้ง 2 เครื่อง เครือข่าย 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;
    ...
  }
  ...
};

API ดั้งเดิมของ mDNSResponder

Android 12 จะเปลี่ยนแปลงเมื่อแอปสามารถโต้ตอบกับ Daemon ของ mDNSResponder โดยใช้ mDNSResponder Native API ก่อนหน้านี้เมื่อแอปลงทะเบียนบริการบนเครือข่าย และเรียก getSystemService() ว่า บริการ NSD ของระบบจะเริ่มต้น Daemon ของ mDNSResponder แม้ว่า แอปยังไม่ได้เรียกเมธอด NsdManager ใดๆ จากนั้น Daemon ได้สมัครรับข้อมูล อุปกรณ์ในกลุ่มมัลติแคสต์ทุกโหนด ทำให้ระบบทำงานมากขึ้น บ่อยๆ และใช้พลังงานเพิ่ม ใน Android 12 เพื่อลดการใช้งานแบตเตอรี่ และในระดับที่สูงกว่านี้ ระบบจะเริ่มต้น Daemon ของ mDNSResponder เมื่อจำเป็นเท่านั้น สำหรับเหตุการณ์ NSD และหยุดในภายหลัง

เนื่องจากการเปลี่ยนแปลงนี้จะส่งผลต่อเวลาที่ Daemon ของ mDNSResponder พร้อมใช้งาน แอปต่างๆ ที่สันนิษฐานว่าดีมอน mDNSResponder จะเริ่มทำงานหลังจากการเรียกฟังก์ชัน เมธอด getSystemService() อาจได้รับข้อความจากระบบซึ่งแจ้งว่า Daemon ของ mDNSResponder ไม่สามารถใช้ได้ แอปที่ใช้ NsdManager และไม่ใช้ ที่ใช้ mDNSResponder Native API จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงนี้

ไลบรารีของผู้ให้บริการ

ไลบรารีที่ใช้ร่วมกันแบบเนทีฟที่ผู้ให้บริการเป็นผู้จัดหา

ไลบรารีที่ใช้ร่วมกันแบบเนทีฟที่ไม่ใช่ NDK ที่ผู้ให้บริการซิลิคอนหรือผู้ผลิตอุปกรณ์ไม่สามารถเข้าถึงได้ โดยค่าเริ่มต้น หากแอปกำหนดเป้าหมายเป็น Android 12 (API ระดับ 31) ขึ้นไป สามารถเข้าถึงไลบรารีได้ต่อเมื่อได้รับคำขออย่างชัดแจ้งโดยใช้ <uses-native-library> แท็ก

หากแอปกำหนดเป้าหมายเป็น Android 11 (API ระดับ 30) หรือต่ำกว่า การตั้งค่า ไม่ต้องใช้แท็ก <uses-native-library> ในกรณีนี้ โฆษณาเนทีฟที่แชร์ สามารถเข้าถึงห้องสมุดดังกล่าว ไม่ว่าจะเป็นห้องสมุด NDK หรือไม่ก็ตาม

ข้อจำกัดที่ไม่ใช่ SDK ที่อัปเดต

Android 12 มีรายการอัปเดตของอุปกรณ์ที่ไม่ใช่ SDK ที่ถูกจำกัด บนการทำงานร่วมกันกับนักพัฒนาซอฟต์แวร์ Android และ การทดสอบภายใน ทุกครั้งที่เป็นไปได้ เราตรวจสอบให้แน่ใจว่าทางเลือกสาธารณะ พร้อมใช้งานก่อนที่เราจะจำกัดอินเทอร์เฟซที่ไม่ใช่ SDK

หากแอปไม่ได้กำหนดเป้าหมายเป็น Android 12 การเปลี่ยนแปลงบางอย่างเหล่านี้ อาจไม่ส่งผลกระทบต่อคุณโดยทันที อย่างไรก็ตาม แม้ว่าขณะนี้คุณสามารถใช้ อินเทอร์เฟซที่ไม่ใช่ SDK (ขึ้นอยู่กับระดับ API เป้าหมายของแอป) การใช้เมธอดหรือฟิลด์ที่ไม่ใช่ SDK มีความเสี่ยงสูงเสมอที่จะทำให้ แอป

หากไม่แน่ใจว่าแอปใช้อินเทอร์เฟซที่ไม่ใช่ SDK หรือไม่ คุณสามารถทดสอบ แอป เพื่อหาคำตอบ หากแอปใช้อินเทอร์เฟซที่ไม่ใช่ SDK คุณควรเริ่มวางแผน การย้ายข้อมูลไปใช้ทางเลือก SDK อย่างไรก็ตาม เราเข้าใจดีว่าบางแอป กรณีการใช้งานที่ถูกต้องสำหรับการใช้อินเทอร์เฟซที่ไม่ใช่ SDK หากไม่พบทางเลือก ในการใช้อินเทอร์เฟซที่ไม่ใช่ SDK สำหรับฟีเจอร์ในแอป คุณควรส่งคำขอ API สาธารณะใหม่

หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงใน Android รุ่นนี้ โปรดดูการอัปเดตเป็น ข้อจำกัดอินเทอร์เฟซที่ไม่ใช่ SDK ใน Android 12 เพื่อดูข้อมูลเพิ่มเติม เกี่ยวกับอินเทอร์เฟซที่ไม่ใช่ SDK โดยทั่วไปโปรดดูข้อจำกัดเกี่ยวกับอินเทอร์เฟซที่ไม่ใช่ SDK อินเทอร์เฟซ