Android 12 มีการเปลี่ยนแปลงลักษณะการทำงานเช่นเดียวกับรุ่นก่อนหน้านี้ อาจส่งผลกระทบต่อแอปของคุณ การเปลี่ยนแปลงลักษณะการทำงานต่อไปนี้มีผลเฉพาะแอปเท่านั้น ที่กำหนดเป้าหมายเป็น Android 12 ขึ้นไป หากแอปของคุณคือ ที่กำหนดเป้าหมายเป็น Android 12 คุณควรแก้ไขแอปเพื่อรองรับลักษณะการทำงานเหล่านี้ อย่างเหมาะสม และเหมาะสม
โปรดตรวจสอบรายการการเปลี่ยนแปลงลักษณะการทำงานที่มีผลต่อแอปทั้งหมดด้วย ที่ทำงานใน Android 12
ประสบการณ์ของผู้ใช้
การแจ้งเตือนที่กำหนดเอง
Android 12 เปลี่ยนรูปลักษณ์และลักษณะการทำงานของการแจ้งเตือนที่กำหนดเองอย่างเต็มรูปแบบ ก่อนหน้านี้การแจ้งเตือนที่กำหนดเองจะใช้พื้นที่การแจ้งเตือนทั้งหมดได้ และระบุเลย์เอาต์และสไตล์ของตัวเอง ซึ่งส่งผลให้เกิดรูปแบบต่อต้าน อาจทำให้ผู้ใช้สับสนหรือทำให้เกิดปัญหาความเข้ากันได้ของเลย์เอาต์ในอุปกรณ์ที่แตกต่างกัน
สำหรับแอปที่กำหนดเป้าหมายเป็น Android 12 การแจ้งเตือนที่มีมุมมองเนื้อหาที่กำหนดเองจะไม่
ใช้พื้นที่การแจ้งเตือนแบบเต็มนานขึ้น แต่ระบบจะใช้มาตรฐาน
เทมเพลต เทมเพลตนี้จะตรวจสอบว่าการแจ้งเตือนที่กำหนดเอง
การตกแต่งเหมือนการแจ้งเตือนอื่นๆ ในทุกรัฐ เช่น ไอคอนการแจ้งเตือน
และความสามารถในการขยาย (ในสถานะยุบ) และไอคอนการแจ้งเตือน
ชื่อแอป และราคายุบ (ในสถานะการขยาย) ลักษณะการทำงานนี้
เกือบเหมือนกันทุกประการกับพฤติกรรมของ
Notification.DecoratedCustomViewStyle
ด้วยวิธีนี้ Android 12 จะช่วยให้การแจ้งเตือนทั้งหมดมีรูปลักษณ์ที่สอดคล้องกันและง่ายต่อการ โดยใช้การขยายการแจ้งเตือนที่คุ้นเคยและค้นพบได้สำหรับผู้ใช้
ภาพประกอบต่อไปนี้แสดงการแจ้งเตือนที่กำหนดเองในเทมเพลตมาตรฐาน
ตัวอย่างต่อไปนี้แสดงลักษณะการแสดงผลการแจ้งเตือนที่กำหนดเองเมื่อยุบ และสถานะที่ขยาย:
![](https://developer.android.google.cn/static/images/about/versions/12/custom-collapsed-view.png?authuser=6&hl=th)
![](https://developer.android.google.cn/static/images/about/versions/12/custom-expanded-view.png?authuser=6&hl=th)
การเปลี่ยนแปลงใน Android 12 ส่งผลต่อแอปที่กำหนดคลาสย่อยที่กำหนดเองของ
Notification.Style
หรือใช้
วิธีการของ Notification.Builder
setCustomContentView(RemoteViews)
,
setCustomBigContentView(RemoteViews)
,
และ setCustomHeadsUpContentView(RemoteViews)
หากแอปใช้การแจ้งเตือนที่กำหนดเองอย่างเต็มรูปแบบ เราขอแนะนำให้ทดสอบด้วย เทมเพลตใหม่โดยเร็วที่สุด
เปิดใช้การเปลี่ยนแปลงการแจ้งเตือนที่กำหนดเอง
- เปลี่ยน
targetSdkVersion
ของแอปเป็นS
เพื่อเปิดใช้ลักษณะการทำงานใหม่ - คอมไพล์ซ้ำ
- ติดตั้งแอปในอุปกรณ์หรือโปรแกรมจําลองที่ใช้ Android 12
- เปลี่ยน
ทดสอบการแจ้งเตือนทั้งหมดที่ใช้มุมมองที่กำหนดเองเพื่อให้มั่นใจว่าระบบจะแสดงมุมมองในแบบของคุณ อยู่ในเฉดสี โปรดคํานึงถึงข้อควรพิจารณาเหล่านี้ขณะทดสอบ และทำการปรับเปลี่ยนที่จำเป็น ดังนี้
มีการเปลี่ยนแปลงมิติข้อมูลของมุมมองที่กำหนดเอง โดยทั่วไป ความสูง การแจ้งเตือนที่กำหนดเองน้อยลงกว่าเดิม ในช่องยุบ ความสูงสูงสุดของเนื้อหาที่กำหนดเองลดลงจาก 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 มุมมองข้อความโทสต์ โฉมใหม่ ขณะนี้ข้อความโทสต์จำกัดข้อความไม่เกิน 2 บรรทัด และแสดงแอปพลิเคชัน ข้างข้อความ
![รูปภาพอุปกรณ์ Android แสดงการอ่านป๊อปอัปข้อความโทสต์
"กำลังส่งข้อความ" ข้างไอคอนแอป](https://developer.android.google.cn/static/images/toast.png?authuser=6&hl=th)
ดูรายละเอียดเพิ่มเติมได้ที่ภาพรวมของข้อความโทสต์
ความปลอดภัยและความเป็นส่วนตัว
ตำแหน่งโดยประมาณ
ในอุปกรณ์ที่ใช้ 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 ขึ้นไป
ข้อความต่อไปนี้จะปรากฏขึ้น
คำเตือนของ 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 เพื่อกำหนดเวลาและเริ่มต้น 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 ที่ทำหน้าที่เป็น แทรมโพลีนการแจ้งเตือน ให้ทำตามขั้นตอนการย้ายข้อมูลต่อไปนี้
- สร้างออบเจ็กต์
PendingIntent
ที่ เชื่อมโยงกับกิจกรรมที่ผู้ใช้เห็นหลังจากแตะ การแจ้งเตือน - ใช้ออบเจ็กต์
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
:
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; ... } ... };
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 อินเทอร์เฟซ