Google ใช้เทคโนโลยี AI เพื่อแปลเนื้อหาเป็นภาษาที่คุณต้องการ การแปลโดย AI อาจมีข้อผิดพลาด

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

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

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

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

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

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

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

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

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

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

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

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

เปิดใช้การเปลี่ยนแปลงการแจ้งเตือนที่กำหนดเองโดยทำดังนี้
1. เปลี่ยน targetSdkVersion ของแอปเป็น S เพื่อเปิดใช้ลักษณะการทำงานใหม่
2. คอมไพล์ใหม่
3. ติดตั้งแอปในอุปกรณ์หรือโปรแกรมจำลองที่ใช้ Android 12
ทดสอบการแจ้งเตือนทั้งหมดที่ใช้มุมมองที่กำหนดเอง เพื่อให้แน่ใจว่าการแจ้งเตือนเหล่านั้นมีลักษณะตามที่คุณคาดหวังในหน้าต่างแจ้งเตือน ขณะทดสอบ ให้พิจารณาปัจจัยต่อไปนี้และทำการปรับเปลี่ยนที่จำเป็น
- ขนาดของมุมมองที่กำหนดเองมีการเปลี่ยนแปลง โดยทั่วไป ความสูงที่กำหนดให้กับการแจ้งเตือนที่กำหนดเองจะน้อยกว่าเดิม ในสถานะยุบ ความสูงสูงสุดของเนื้อหาที่กำหนดเองลดลงจาก 106 dp เป็น 48 dp นอกจากนี้ พื้นที่ในแนวนอนยังมีน้อยลงด้วย
- การแจ้งเตือนทั้งหมดขยายได้สำหรับแอปที่กำหนดเป้าหมายเป็น Android 12 โดยปกติแล้ว หมายความว่าหากคุณใช้ setCustomContentView คุณจะต้องใช้ setBigCustomContentView ด้วยเพื่อให้แน่ใจว่าสถานะยุบและขยายสอดคล้องกัน
- อย่าลืมเพิ่มความสำคัญของช่องทางการแจ้งเตือนเป็น "สูง" (ปรากฏบนหน้าจอ) เพื่อให้สถานะ "Heads Up" มีลักษณะตามที่คุณคาดหวัง

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

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

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

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

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

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

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

การออกแบบข้อความ Toast ใหม่

ใน Android 12 มุมมอง Toast ได้รับการออกแบบใหม่ ตอนนี้ข้อความโทสต์จะจำกัดไว้ที่ 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 และ Schemeful SameSite

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

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

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

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

เปิดใช้ลักษณะการทำงานของ SameSite ด้วยตนเองในอุปกรณ์ทดสอบโดยสลับแฟล็ก UI webview-enable-modern-cookie-same-site ใน WebView devtools

วิธีนี้ช่วยให้คุณทดสอบในอุปกรณ์ที่ใช้ 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 ได้ที่หน้าการอัปเดต SameSite ของ Chromium หากพบข้อบกพร่องใน WebView หรือ Chromium คุณสามารถรายงานข้อบกพร่องดังกล่าวในเครื่องมือติดตามปัญหาของ Chromium สาธารณะ

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

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

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

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

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

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

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

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 ขึ้นไปและมีกิจกรรม บริการ หรือ Broadcast Receiver ที่ใช้ตัวกรอง 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>

ข้อความใน Android Studio

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

Android Studio 2020.3.1 Canary 11 ขึ้นไป

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

คำเตือน Lint ต่อไปนี้จะปรากฏในไฟล์ Manifest
```
When using intent filters, please specify android:exported as well
```
เมื่อพยายามคอมไพล์แอป ข้อความแสดงข้อผิดพลาดในการบิลด์ต่อไปนี้จะปรากฏขึ้น
```
Manifest merger failed : Apps targeting Android 12 and higher are required \
to specify an explicit value for android:exported when the corresponding \
component has an intent filter defined.
```

Android 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 เพื่อกำหนดเวลาและเริ่มงานด่วนขณะที่แอปทำงานอยู่เบื้องหลัง หากต้องการดำเนินการที่ผู้ใช้ขอซึ่งต้องดำเนินการภายในเวลาที่กำหนด ให้เริ่มบริการที่ทำงานอยู่เบื้องหน้าภายในสัญญาณเตือนเจาะจง

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

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

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

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

เปิด/ปิดลักษณะการทำงาน

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

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

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

เพื่อมอบประสบการณ์ของผู้ใช้ที่ดียิ่งขึ้นในอุปกรณ์ที่รองรับเครือข่าย Wi-Fi พร้อมกัน 2 เครือข่าย เราขอแนะนำให้แอปทั้งหมด โดยเฉพาะแอปที่ทริกเกอร์การเชื่อมต่อแบบเพียร์ทูเพียร์ ย้ายจากการเรียกใช้ WifiManager.getConnectionInfo() ไปใช้ NetworkCallback.onCapabilitiesChanged() แทน เพื่อรับออบเจ็กต์ WifiInfo ทั้งหมดที่ตรงกับ NetworkRequest ที่ใช้ในการลงทะเบียน NetworkCallback 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 ของ mDNSResponder พร้อมใช้งาน แอปที่ถือว่า Daemon ของ mDNSResponder จะเริ่มทำงานหลังจากเรียกใช้เมธอด getSystemService() อาจได้รับข้อความจากระบบที่ระบุว่า Daemon ของ mDNSResponder ไม่พร้อมใช้งาน แอปที่ใช้ NsdManager และไม่ได้ใช้ API แบบเนทีฟ mDNSResponder จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงนี้

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

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

ไลบรารีที่ใช้ร่วมกันแบบเนทีฟที่ไม่ใช่ 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