การเปลี่ยนแปลงลักษณะการทํางานของ Android 5.0

ระดับ API: 21

นอกจากฟีเจอร์และความสามารถใหม่ๆ แล้ว Android 5.0 ยังมีการเปลี่ยนแปลงระบบและลักษณะการทํางานของ API อีกมากมาย เอกสารนี้จะไฮไลต์การเปลี่ยนแปลงที่สำคัญบางอย่างที่คุณควรเข้าใจและนำมาพิจารณาในแอป

หากคุณเคยเผยแพร่แอปสำหรับ Android โปรดทราบว่าแอปของคุณอาจได้รับผลกระทบจากการเปลี่ยนแปลงเหล่านี้ใน Android 5.0

หากต้องการดูภาพรวมระดับสูงของฟีเจอร์ใหม่ในแพลตฟอร์ม ให้ดูไฮไลต์ของ Android Lollipop แทน

วิดีโอ

Dev Byte: มีอะไรใหม่ใน Android 5.0

Dev Byte: การแจ้งเตือน

Android Runtime (ART)

ใน Android 5.0 รันไทม์ ART จะแทนที่ Dalvik เป็นแพลตฟอร์มเริ่มต้น รันไทม์ ART เปิดตัวใน Android 4.4 แบบทดลอง

ดูภาพรวมฟีเจอร์ใหม่ของ ART ได้ที่หัวข้อขอแนะนำ ART ฟีเจอร์ใหม่ที่สำคัญๆ มีดังนี้

  • การคอมไพล์ล่วงหน้า (AOT)
  • ปรับปรุงการเก็บขยะ (GC)
  • การรองรับการแก้ไขข้อบกพร่องที่ปรับปรุงแล้ว

แอป Android ส่วนใหญ่ควรทำงานได้โดยไม่ต้องเปลี่ยนแปลงใดๆ ภายใต้ ART อย่างไรก็ตาม เทคนิคบางอย่างที่ใช้กับ Dalvik จะใช้กับ ART ไม่ได้ ดูข้อมูลเกี่ยวกับปัญหาที่สําคัญที่สุดได้ที่การยืนยันลักษณะการทํางานของแอปใน Android Runtime (ART) โปรดระมัดระวังเป็นพิเศษในกรณีต่อไปนี้

  • แอปของคุณใช้ Java Native Interface (JNI) เพื่อเรียกใช้โค้ด C/C++
  • คุณใช้เครื่องมือสำหรับการพัฒนาที่สร้างโค้ดที่ไม่เป็นไปตามมาตรฐาน (เช่น เครื่องมือสร้างความสับสนบางรายการ)
  • คุณใช้เทคนิคที่ใช้ร่วมกับการบีบอัดการเก็บขยะไม่ได้

การแจ้งเตือน

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

สไตล์ Material Design

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

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

เสียงและการสั่น

หากคุณกำลังเพิ่มเสียงและการสั่นให้กับการแจ้งเตือนโดยใช้คลาส Ringtone, MediaPlayer หรือ Vibrator ให้นำรหัสนี้ออกเพื่อให้ระบบแสดงการแจ้งเตือนได้อย่างถูกต้องในโหมดสำคัญ ให้ใช้วิธี Notification.Builder เพื่อเพิ่มเสียงและการสั่นแทน

การตั้งค่าอุปกรณ์เป็น RINGER_MODE_SILENT จะทำให้อุปกรณ์เข้าสู่โหมดความสำคัญใหม่ อุปกรณ์จะออกจากโหมดสำคัญหากคุณตั้งค่าเป็น RINGER_MODE_NORMAL หรือ RINGER_MODE_VIBRATE

ก่อนหน้านี้ Android ใช้ STREAM_MUSIC เป็นสตรีมหลักเพื่อควบคุมระดับเสียงในอุปกรณ์แท็บเล็ต ใน Android 5.0 นี้ สตรีมระดับเสียงหลักสำหรับทั้งอุปกรณ์โทรศัพท์และแท็บเล็ตจะรวมกันเป็นหนึ่งเดียว และควบคุมด้วย STREAM_RING หรือ STREAM_NOTIFICATION

การแสดงผลบนหน้าจอล็อก

ตอนนี้การแจ้งเตือนจะปรากฏในหน้าจอล็อกของผู้ใช้โดยค่าเริ่มต้นใน Android 5.0 ผู้ใช้สามารถเลือกที่จะปกป้องข้อมูลที่ละเอียดอ่อนไม่ให้เปิดเผยได้ ซึ่งในกรณีนี้ ระบบจะปกปิดข้อความที่แสดงโดยการแจ้งเตือนโดยอัตโนมัติ หากต้องการปรับแต่งการแจ้งเตือนที่มีการปกปิดบางส่วนนี้ ให้ใช้ setPublicVersion()

หากการแจ้งเตือนไม่มีข้อมูลส่วนบุคคล หรือคุณต้องการอนุญาตให้ควบคุมการเล่นสื่อในการแจ้งเตือน ให้เรียกใช้เมธอด setVisibility() และตั้งค่าระดับการมองเห็นของการแจ้งเตือนเป็น VISIBILITY_PUBLIC

การเล่นสื่อ

หากคุณกำลังใช้การแจ้งเตือนที่แสดงสถานะการเล่นสื่อหรือการควบคุมการนําทาง ให้พิจารณาใช้เทมเพลต Notification.MediaStyle ใหม่แทนออบเจ็กต์ RemoteViews.RemoteView ที่กําหนดเอง ไม่ว่าจะเลือกวิธีใด อย่าลืมตั้งค่าระดับการมองเห็นของการแจ้งเตือนเป็นVISIBILITY_PUBLICเพื่อให้เข้าถึงตัวควบคุมจากหน้าจอล็อกได้ โปรดทราบว่าตั้งแต่ Android 5.0 เป็นต้นไป ระบบจะไม่แสดงRemoteControlClientวัตถุบนหน้าจอล็อกอีกต่อไป ดูข้อมูลเพิ่มเติมได้ที่หากแอปใช้ RemoteControlClient

การแจ้งเตือนล่วงหน้า

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

ตัวอย่างเงื่อนไขที่อาจเรียกให้การแจ้งเตือนล่วงหน้าแสดงขึ้นมีดังนี้

  • กิจกรรมของผู้ใช้อยู่ในโหมดเต็มหน้าจอ (แอปใช้ fullScreenIntent)
  • การแจ้งเตือนมีลำดับความสำคัญสูงและใช้เสียงเรียกเข้าหรือการสั่น

หากแอปของคุณใช้การแจ้งเตือนในสถานการณ์ดังกล่าว โปรดตรวจสอบว่าการแจ้งเตือนล่วงหน้าแสดงอย่างถูกต้อง

Media Controls และ RemoteControlClient

เราเลิกใช้งานคลาส RemoteControlClient แล้ว เปลี่ยนไปใช้ MediaSession API ใหม่โดยเร็วที่สุด

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

Android 5.0 เปิดตัวเทมเพลตNotification.MediaStyleใหม่สำหรับวัตถุประสงค์นี้ Notification.MediaStyle จะแปลงการดำเนินการในการแจ้งเตือนที่คุณเพิ่มด้วย Notification.Builder.addAction() ให้เป็นปุ่มขนาดกะทัดรัดที่ฝังอยู่ในการแจ้งเตือนการเล่นสื่อของแอป ส่งโทเค็นเซสชันไปยังเมธอด setSession() เพื่อแจ้งให้ระบบทราบว่าการแจ้งเตือนนี้ควบคุมเซสชันสื่อที่ดำเนินอยู่

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

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

getRecentTasks()

เราได้เลิกใช้งานเมธอด ActivityManager.getRecentTasks() แล้วเพื่อปรับปรุงความเป็นส่วนตัวของผู้ใช้ เนื่องจากมีการเปิดตัวฟีเจอร์เอกสารและกิจกรรมที่ทำงานพร้อมกันแบบใหม่ใน Android 5.0 (ดูเอกสารและกิจกรรมที่ทำงานพร้อมกันในหน้าจอล่าสุดด้านล่าง) เพื่อการทำงานร่วมกันได้ย้อนหลัง วิธีนี้จะยังคงแสดงผลชุดข้อมูลย่อยจำนวนเล็กน้อย ซึ่งรวมถึงงานของแอปพลิเคชันที่เรียกใช้เอง และอาจรวมถึงงานอื่นๆ ที่ไม่ละเอียดอ่อน (เช่น Home) หากแอปใช้เมธอดนี้เพื่อดึงข้อมูลงานของตัวเอง ให้ใช้ getAppTasks()แทนเพื่อดึงข้อมูลดังกล่าว

การรองรับ 64 บิตใน Android NDK

Android 5.0 รองรับระบบ 64 บิต การเพิ่มประสิทธิภาพแบบ 64 บิตจะเพิ่มพื้นที่ที่อยู่และปรับปรุงประสิทธิภาพ ในขณะเดียวกันก็ยังคงรองรับแอป 32 บิตที่มีอยู่อย่างเต็มรูปแบบ การรองรับ 64 บิตยังช่วยปรับปรุงประสิทธิภาพของ OpenSSL สําหรับวิทยาการเข้ารหัสด้วย นอกจากนี้ เวอร์ชันนี้ยังเปิดตัว NDK API สื่อแบบเนทีฟใหม่ รวมถึงการรองรับ OpenGL ES (GLES) 3.1 ในตัว

หากต้องการใช้การรองรับ 64 บิตที่มีให้ใน Android 5.0 ให้ดาวน์โหลดและติดตั้ง NDK ฉบับแก้ไข 10c จากหน้า Android NDK ดูข้อมูลเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงที่สำคัญและการแก้ไขข้อบกพร่องใน NDK ได้จากบันทึกประจำรุ่นฉบับที่ 10c

การเชื่อมโยงกับบริการ

ตอนนี้เมธอด Context.bindService()ต้องใช้ Intent อย่างชัดแจ้ง และระบบจะแสดงข้อยกเว้นหากได้รับ Intent โดยนัย ใช้ Intent แบบชัดแจ้งเมื่อเริ่มหรือเชื่อมโยง Service และไม่ประกาศตัวกรอง Intent สําหรับบริการ เพื่อให้แอปปลอดภัย

WebView

Android 5.0 เปลี่ยนลักษณะการทำงานเริ่มต้นของแอป

  • หากแอปกำหนดเป้าหมายเป็น API ระดับ 21 ขึ้นไป
    • ระบบจะบล็อกเนื้อหาแบบผสมและคุกกี้ของบุคคลที่สามโดยค่าเริ่มต้น หากต้องการอนุญาตเนื้อหาและคุกกี้ของบุคคลที่สามแบบผสม ให้ใช้วิธี setMixedContentMode() และ setAcceptThirdPartyCookies() ตามลำดับ
    • ตอนนี้ระบบจะเลือกส่วนของเอกสาร HTML ที่จะวาดอย่างชาญฉลาด ลักษณะการทำงานเริ่มต้นใหม่นี้ช่วยลดพื้นที่หน่วยความจําและเพิ่มประสิทธิภาพ หากต้องการแสดงผลทั้งเอกสารพร้อมกัน ให้ปิดใช้การเพิ่มประสิทธิภาพนี้โดยเรียกใช้ enableSlowWholeDocumentDraw()
  • หากแอปกำหนดเป้าหมายเป็น API ระดับต่ำกว่า 21: ระบบจะอนุญาตให้ใช้เนื้อหาแบบผสมและคุกกี้ของบุคคลที่สาม รวมถึงแสดงผลทั้งเอกสารพร้อมกันเสมอ

ข้อกำหนดที่ไม่ซ้ำกันสำหรับสิทธิ์ที่กำหนดเอง

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

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

Android 5.0 มีการเปลี่ยนแปลงลักษณะการทำงานเพื่อให้มั่นใจว่ามีเพียงแอปเดียวเท่านั้นที่กำหนดสิทธิ์ที่กำหนดเองได้ เว้นแต่ว่าจะมีการรับรองด้วยคีย์เดียวกับแอปอื่นๆ ที่กําหนดสิทธิ์

แอปที่ใช้สิทธิ์ที่กำหนดเองซ้ำ

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

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

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

ข้อควรพิจารณาสำหรับแอป

ใน Android 5.0 ขึ้นไป แอปจะกำหนดสิทธิ์ที่กำหนดเองของตนเองได้ต่อไปเช่นเดียวกับที่ผ่านมา และขอสิทธิ์ที่กำหนดเองจากแอปอื่นๆ ผ่านกลไก <uses-permission> อย่างไรก็ตาม คุณควรประเมินผลกระทบที่อาจเกิดขึ้นกับแอปอย่างรอบคอบเนื่องจากข้อกำหนดใหม่ใน Android 5.0

ประเด็นที่ควรพิจารณามีดังนี้

  • แอปของคุณประกาศองค์ประกอบ <permission> ในไฟล์ Manifest ไหม หากใช่ ฟีเจอร์ดังกล่าวจำเป็นต่อฟังก์ชันการทํางานของแอปหรือบริการอย่างถูกต้องหรือไม่ หรือจะใช้สิทธิ์เริ่มต้นของระบบแทนได้ไหม
  • หากคุณมีองค์ประกอบ <permission> ในแอป คุณทราบหรือไม่ว่าองค์ประกอบเหล่านั้นมาจากที่ใด
  • คุณตั้งใจให้แอปอื่นๆ ขอสิทธิ์ที่กำหนดเองผ่าน <uses-permission> จริงหรือไม่
  • คุณใช้โค้ดต้นฉบับหรือโค้ดตัวอย่างในแอปซึ่งมีองค์ประกอบ <permission> อยู่หรือไม่ องค์ประกอบสิทธิ์เหล่านั้นจำเป็นจริงไหม
  • สิทธิ์ที่กําหนดเองใช้ชื่อที่เข้าใจง่ายหรืออิงตามคําทั่วไปที่แอปอื่นๆ อาจใช้หรือไม่

การติดตั้งและการอัปเดตใหม่

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

การติดตั้งที่มีอยู่ซึ่งมีการอัปเดตระบบ Android 5.0

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

คำแนะนำ

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

  • หากคุณใช้สิทธิ์ที่กําหนดเองในแอป ให้พิจารณาแหล่งที่มาของสิทธิ์เหล่านั้นและพิจารณาว่าคุณจําเป็นต้องใช้สิทธิ์เหล่านั้นจริงหรือไม่ นำองค์ประกอบ <permission> ทั้งหมดออกจากแอป เว้นแต่คุณจะมั่นใจว่าองค์ประกอบดังกล่าวจำเป็นต่อการทำงานของแอป
  • ลองใช้สิทธิ์เริ่มต้นของระบบแทนสิทธิ์ที่กำหนดเอง หากเป็นไปได้
  • หากแอปของคุณต้องใช้สิทธิ์ที่กำหนดเอง ให้เปลี่ยนชื่อสิทธิ์ที่กำหนดเองเพื่อให้มีเอกลักษณ์เฉพาะสำหรับแอปของคุณ เช่น เพิ่มสิทธิ์ที่กำหนดเองต่อท้ายชื่อแพ็กเกจแบบเต็มของแอป
  • หากคุณมีชุดแอปที่ลงนามด้วยคีย์ที่แตกต่างกันและแอปเข้าถึงคอมโพเนนต์ที่แชร์ด้วยสิทธิ์ที่กำหนดเอง ให้ตรวจสอบว่าได้กำหนดสิทธิ์ที่กำหนดเองเพียงครั้งเดียวในคอมโพเนนต์ที่แชร์ แอปที่ใช้คอมโพเนนต์ที่แชร์ไม่ควรกำหนดสิทธิ์ที่กำหนดเองเอง แต่ควรขอสิทธิ์เข้าถึงผ่านกลไก <uses-permission> แทน
  • หากคุณมีชุดแอปที่ลงนามด้วยคีย์เดียวกัน แอปแต่ละแอปจะกำหนดสิทธิ์ที่กำหนดเองเดียวกันได้ตามต้องการระบบจะอนุญาตให้ติดตั้งแอปด้วยวิธีปกติ

การเปลี่ยนแปลงการกำหนดค่าเริ่มต้นของ TLS/SSL

Android 5.0 เปลี่ยนแปลงการกำหนดค่า TLS/SSL เริ่มต้นที่แอปใช้สำหรับ HTTPS และการรับส่งข้อมูล TLS/SSL อื่นๆ ดังนี้

  • โปรโตคอล TLSv1.2 และ TLSv1.1 เปิดใช้งานแล้ว
  • ชุดการเข้ารหัส AES-GCM (AEAD) เปิดใช้งานแล้ว
  • ตอนนี้ชุดการเข้ารหัส MD5, 3DES, Export และ ECDH ที่คีย์แบบคงที่ปิดใช้งานแล้ว
  • แนะนำให้ใช้ชุดการเข้ารหัส Forward Secrecy (ECDHE และ DHE)

การเปลี่ยนแปลงเหล่านี้อาจทำให้การเชื่อมต่อ HTTPS หรือ TLS/SSL หยุดชะงักในบางกรณีตามที่ระบุไว้ด้านล่าง

โปรดทราบว่า ProviderInstaller ความปลอดภัยจากบริการ Google Play เสนอการเปลี่ยนแปลงเหล่านี้ในแพลตฟอร์ม Android เวอร์ชันต่างๆ ย้อนกลับไปตั้งแต่ Android 2.3 แล้ว

เซิร์ฟเวอร์ไม่รองรับชุดการเข้ารหัสที่เปิดใช้

เช่น เซิร์ฟเวอร์อาจรองรับชุดการเข้ารหัส 3DES หรือ MD5 เท่านั้น การแก้ไขที่แนะนำคือการปรับปรุงการกำหนดค่าเซิร์ฟเวอร์เพื่อใช้ชุดการเข้ารหัสและโปรโตคอลที่ทันสมัยและรัดกุมยิ่งขึ้น โดยควรเปิดใช้ TLSv1.2 และ AES-GCM รวมถึงเปิดใช้ชุดการเข้ารหัสการรักษาความลับแบบส่งต่อ (ECDHE, DHE) และแนะนำให้ใช้

อีกทางเลือกหนึ่งคือการแก้ไขแอปให้ใช้ SSLSocketFactory ที่กําหนดเองเพื่อสื่อสารกับเซิร์ฟเวอร์ ควรออกแบบโรงงานเพื่อสร้างอินสแตนซ์ SSLSocket ที่เปิดใช้ชุดการเข้ารหัสบางชุดที่เซิร์ฟเวอร์ต้องการนอกเหนือจากชุดการเข้ารหัสเริ่มต้น

แอปทำการคาดเดาที่ไม่ถูกต้องเกี่ยวกับชุดการเข้ารหัสที่ใช้เชื่อมต่อกับเซิร์ฟเวอร์

ตัวอย่างเช่น แอปบางแอปมี X509TrustManager ที่กําหนดเองซึ่งใช้งานไม่ได้เนื่องจากคาดว่าพารามิเตอร์ authType จะเป็น RSA แต่พบ ECDHE_RSA หรือ DHE_RSA

เซิร์ฟเวอร์ไม่รองรับ TLSv1.1, TLSv1.2 หรือส่วนขยาย TLS ใหม่

เช่น กระบวนการแฮนด์เชค TLS/SSL กับเซิร์ฟเวอร์ถูกปฏิเสธอย่างไม่ถูกต้องหรือหยุดชะงัก การแก้ไขที่แนะนำคือการอัปเกรดเซิร์ฟเวอร์ให้เป็นไปตามโปรโตคอล TLS/SSL ซึ่งจะทำให้เซิร์ฟเวอร์เจรจาโปรโตคอลที่ใหม่กว่าเหล่านี้ได้สําเร็จ หรือเจรจา TLSv1 หรือโปรโตคอลเก่ากว่า และละเว้นส่วนขยาย TLS ที่ไม่เข้าใจ ในบางกรณี การปิดใช้ TLSv1.1 และ TLSv1.2 ในเซิร์ฟเวอร์อาจใช้เป็นมาตรการชั่วคราวได้จนกว่าจะมีการอัปเกรดซอฟต์แวร์เซิร์ฟเวอร์

อีกทางเลือกหนึ่งคือการแก้ไขแอปให้ใช้ SSLSocketFactory ที่กําหนดเองเพื่อสื่อสารกับเซิร์ฟเวอร์ ควรออกแบบโรงงานเพื่อสร้างอินสแตนซ์ SSLSocket โดยเปิดใช้เฉพาะโปรโตคอลที่เซิร์ฟเวอร์รองรับอย่างถูกต้อง

การสนับสนุนโปรไฟล์ที่มีการจัดการ

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

การจัดการ Intent

ผู้ดูแลระบบอุปกรณ์สามารถจํากัดการเข้าถึงแอปพลิเคชันของระบบจากโปรไฟล์ที่จัดการได้ ในกรณีนี้ หากแอปเรียกใช้ Intent จากโปรไฟล์ที่มีการจัดการซึ่งโดยปกติแอปพลิเคชันนั้นจะจัดการ และไม่มีตัวแฮนเดิลที่เหมาะสมสำหรับ Intent ในโปรไฟล์ที่มีการจัดการ Intent จะทำให้เกิดข้อยกเว้น ตัวอย่างเช่น ผู้ดูแลระบบอุปกรณ์สามารถจำกัดไม่ให้แอปในโปรไฟล์ที่มีการจัดการเข้าถึงแอปพลิเคชันกล้องของระบบได้ หากแอปของคุณทำงานในโปรไฟล์ที่มีการจัดการ และเรียกใช้ startActivityForResult() สำหรับ MediaStore.ACTION_IMAGE_CAPTURE แต่ไม่มีแอปในโปรไฟล์ที่มีการจัดการที่จัดการ Intent ได้ ผลลัพธ์ที่ได้คือ ActivityNotFoundException

คุณป้องกันปัญหานี้ได้โดยตรวจสอบว่ามีตัวแฮนเดิลอย่างน้อย 1 รายการสําหรับ Intent ใดก็ตามก่อนเรียกใช้ หากต้องการตรวจสอบตัวแฮนเดิลที่ถูกต้อง ให้โทรไปที่ Intent.resolveActivity() คุณดูตัวอย่างการดำเนินการนี้ได้ในส่วนถ่ายภาพ ง่ายๆ: ถ่ายภาพด้วยแอปกล้อง

การแชร์ไฟล์ข้ามโปรไฟล์

แต่ละโปรไฟล์จะมีพื้นที่เก็บข้อมูลไฟล์ของตัวเอง เนื่องจาก URI ของไฟล์หมายถึงตำแหน่งที่เฉพาะเจาะจงในที่จัดเก็บไฟล์ URI ของไฟล์ที่ถูกต้องในโปรไฟล์หนึ่งจึงใช้ไม่ได้ในอีกโปรไฟล์หนึ่ง โดยทั่วไปแล้ว แอปจะไม่มีปัญหานี้ เนื่องจากมักจะเข้าถึงเฉพาะไฟล์ที่สร้างขึ้น อย่างไรก็ตาม หากแอปแนบไฟล์กับ Intent การแนบ URI ของไฟล์นั้นไม่ปลอดภัย เนื่องจากในบางกรณี ระบบอาจจัดการ Intent ในโปรไฟล์อื่น ตัวอย่างเช่น ผู้ดูแลระบบอุปกรณ์อาจระบุให้แอปกล้องในโปรไฟล์ส่วนตัวจัดการเหตุการณ์การจับภาพ หากแอปในโปรไฟล์ที่มีการจัดการเรียกใช้ Intent กล้องจะต้องเขียนรูปภาพไปยังตำแหน่งที่แอปของโปรไฟล์ที่มีการจัดการอ่านได้

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

นำการรองรับวิดเจ็ตหน้าจอล็อกออกแล้ว

Android 5.0 เลิกรองรับวิดเจ็ตในหน้าจอล็อก แต่ยังคงรองรับวิดเจ็ตในหน้าจอหลัก