การเปลี่ยนแปลงลักษณะการทำงาน: แอปที่กำหนดเป้าหมายเป็น 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 เพื่อให้มั่นใจว่าสถานะที่ยุบและขยายสอดคล้องกัน

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

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

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

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

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

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

ดูข้อมูลเพิ่มเติมได้ที่การปรับปรุง โหมดภาพซ้อนภาพ

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

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

รูปภาพอุปกรณ์ Android แสดงป๊อปอัปข้อความโทสต์ที่ระบุว่า "กำลังส่งข้อความ" ข้างไอคอนแอป

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

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

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

ในอุปกรณ์ที่ใช้ 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

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

ดูคำแนะนำฉบับสมบูรณ์สำหรับนักพัฒนาเว็บเกี่ยวกับการเปลี่ยนแปลงเหล่านี้ได้ที่ SameSite Cookie Explained และ Schemeful SameSite

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

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

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

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

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

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

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

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

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

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

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

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

ดูข้อมูลเพิ่มเติมได้ในคู่มือเกี่ยวกับการพักแอป

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

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

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

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

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

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

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

หากแอปกำหนดเป้าหมายเป็น Android 12 ขึ้นไปและมี activities, services หรือ broadcast receivers ที่ใช้ intent filters คุณต้องประกาศแอตทริบิวต์ 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'

ความสามารถในการเปลี่ยนแปลงได้ของ PendingIntent

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

ทดสอบการเปลี่ยนแปลงการเปลี่ยนแปลงได้ของ PendingIntent

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

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

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

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

ประสิทธิภาพ

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

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

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

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

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

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

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

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

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

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

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

    adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME

ข้อจำกัดของ Notification Trampoline

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

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

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

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

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

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

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

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

อัปเดตแอป

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

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

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

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

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

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

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

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

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

การเปลี่ยนแปลงฟังก์ชันการโอน 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) ขึ้นไป อุปกรณ์ที่รองรับ การเชื่อมต่อแบบเพียร์ทูเพียร์และอินเทอร์เน็ตพร้อมกันจะสามารถรักษาการเชื่อมต่อ 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ของการเชื่อมต่อที่ให้ อินเทอร์เน็ตหลัก

เราขอแนะนำให้แอปทั้งหมด โดยเฉพาะแอปที่ทริกเกอร์การเชื่อมต่อแบบเพียร์ทูเพียร์ ย้ายจากการเรียกใช้ WifiManager.getConnectionInfo() ไปใช้ NetworkCallback.onCapabilitiesChanged() แทน เพื่อรับออบเจ็กต์ WifiInfo ทั้งหมดที่ตรงกับ NetworkRequest ที่ใช้ลงทะเบียน NetworkCallback เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีขึ้นในอุปกรณ์ที่รองรับเครือข่าย Wi-Fi แบบคู่พร้อมกัน getConnectionInfo() เลิกใช้งานแล้วตั้งแต่ Android 12

ตัวอย่างโค้ดต่อไปนี้แสดงวิธีรับ WifiInfo ใน NetworkCallback

Kotlin

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

Java

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

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

เนื่องจากการเปลี่ยนแปลงนี้ส่งผลต่อเวลาที่ Daemon mDNSResponder พร้อมใช้งาน แอปที่สมมติว่า Daemon 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 อย่างไรก็ตาม เราเข้าใจว่าแอปบางแอปมี Use Case ที่ถูกต้องสำหรับการใช้อินเทอร์เฟซที่ไม่ใช่ SDK หากไม่พบวิธีอื่นแทนการใช้อินเทอร์เฟซที่ไม่ใช่ SDK สำหรับฟีเจอร์ในแอป คุณควรขอ API สาธารณะใหม่

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