Android 11 AMA: ไม่มีการเลื่อนภาพหน้าจอ เปิดแอปเร็วขึ้น และอื่นๆ อีกมากมาย

เมื่อวาน Google เปิดตัว ระบบปฏิบัติการ Android 11 เบต้า 2โดยนำ SDK, NDK ที่สรุปผลแล้ว, พื้นผิวที่เชื่อมต่อกับแอป, ลักษณะการทำงานของแพลตฟอร์ม และข้อจำกัดเกี่ยวกับอินเทอร์เฟซที่ไม่ใช่ SDK สำหรับนักพัฒนา วันนี้ Google กำลังตอบคำถามที่เกี่ยวข้องกับ Android 11 ในชุมชน /r/AndroidDev ของ Reddit หลังจากตอบคำถามเมื่อสัปดาห์ที่แล้ว. นี่คือบทสรุปของทุกสิ่งที่เราเรียนรู้จาก AMA ของ Google (ถามอะไรก็ได้)

หนึ่งในคุณสมบัติที่คาดหวังมากที่สุดของ Android 11 จะไม่สามารถใช้งานได้เมื่อระบบปฏิบัติการ ออกจากเบต้าในวันที่ 8 กันยายน: การเลื่อนภาพหน้าจอ เริ่มแรก วางแผนเปิดตัวใน Android 11ขณะนี้ Google ได้ยืนยันแล้วว่าฟีเจอร์นี้ "ไม่ได้ตัดทอน R" ตัวอย่างนักพัฒนา Android 11 1 และ การเปิดตัว DP และเบต้าที่ตามมาทั้งหมดจะมีปุ่มตัวยึดสำหรับจับภาพหน้าจอแบบเลื่อนที่สามารถทำได้ ปรากฏขึ้นด้วยตนเองด้วยคำสั่งนักพัฒนาที่ซ่อนอยู่แต่การแตะปุ่มจะแสดงข้อความอวยพรที่ระบุว่าคุณลักษณะนี้ "ไม่ได้ใช้งาน"

เราหวังว่าฟีเจอร์นี้จะเข้าสู่รุ่นเบต้าหรือแม้แต่รุ่นเสถียร แต่ดูเหมือนว่าจะไม่เกิดขึ้น

ข่าวนี้อาจทำให้ผู้ใช้บางคนไม่พอใจ ท้ายที่สุดแล้ว OEM จำนวนมากมีฟีเจอร์นี้ในซอฟต์แวร์ของตัวเองมานานหลายปี แล้ว Google จะใช้เวลานานขนาดนี้ในการเพิ่มลงในโทรศัพท์ Pixel ได้อย่างไร ตามที่อธิบายโดย Dan Sandler จากทีม System UI ของ Google ปัญหาคือ Google ต้องการทำให้ถูกต้อง การใช้งานภาพหน้าจอแบบเลื่อนบางภาพเพียงแค่จำลองการเลื่อนแล้วต่อภาพหน้าจอหลายภาพเข้าด้วยกันในขณะที่หน้าจอเคลื่อนไหว หากคุณเคยจัดการกับ UI อัตโนมัติบน Android คุณจะรู้ว่าสิ่งนี้ไม่ได้ผลเสมอไป ดังที่ Mr. Sandler กล่าวถึงแอพต่างๆ สามารถใช้ "RecyclerView มาตรฐานบึงหรือใช้เอ็นจิ้นการเลื่อนแบบเร่งด้วย OpenGL ของตัวเอง" เนื่องจาก Google วางแผนที่จะ ใช้ฟีเจอร์นี้ไม่ใช่แค่สมาร์ทโฟน Pixel แต่สำหรับระบบนิเวศ Android ทั้งหมดซึ่งเป็นส่วนหนึ่งของ AOSP พวกเขาจำเป็นต้องทำให้แน่ใจ มันจะทำงานต่อไป ทั้งหมด ไม่ใช่แค่ "แอปที่เลือกสรรมาหนึ่งหรือสองแอปบนอุปกรณ์เฉพาะ"

เนื่องจากทีมต้อง "มุ่งเน้นทรัพยากรที่มีจำกัด [ของพวกเขา]" โดยเฉพาะอย่างยิ่งเนื่องจากความท้าทายที่เกิดขึ้น ในช่วงวิกฤตโควิด-19 ทีมงานจึงตัดสินใจวางภาพหน้าจอแบบเลื่อนไว้ที่แบ็คเบิร์นเนอร์สำหรับการเปิดตัว Android ในอนาคต

ข้อกำหนด CDD ใหม่เพื่อแจ้งให้ผู้ใช้ทราบถึงข้อจำกัดในเบื้องหลัง

เป็นที่ทราบกันดีว่า OEM ของ Android จำนวนมาก โดยเฉพาะชาวจีน มีข้อจำกัดเชิงรุกเกี่ยวกับแอปที่ทำงานอยู่เบื้องหลัง นักพัฒนาซอฟต์แวร์บางรายรู้สึกหงุดหงิดมากที่แอปของตนถูกปิดการทำงานในเบื้องหลัง จึงได้รวมตัวกันเพื่อสร้างเว็บไซต์ชื่อ "อย่าฆ่าแอปของฉัน" เพื่อจัดอันดับ OEM ตามความสามารถในการจัดการกระบวนการแอปเบื้องหลังได้แย่แค่ไหน นักพัฒนาคนเดียวกันเหล่านั้น แม้กระทั่งเพิ่งสร้างมาตรฐานขึ้นมา เพื่อให้ผู้ใช้สามารถทดสอบได้ว่าอุปกรณ์ของพวกเขาฆ่าแอปในเบื้องหลังได้รุนแรงเพียงใด เหตุผลที่ OEM จำนวนมากชอบที่จะฆ่ากระบวนการแอปพื้นหลังนั้นซับซ้อน แต่ฉันคิดว่ามันอธิบายได้ดีที่สุดในความคิดเห็นนี้โดย Redditor /u/อาจเป็นที่น่าสงสัย. ความคิดเห็นดังกล่าวสรุปถึงสถานะที่ซับซ้อนของการพัฒนาแอป Android ในประเทศจีน รวมถึงวิธีที่บริษัทเทคโนโลยีของจีน มีส่วนร่วมในการทำให้สิ่งต่าง ๆ ซับซ้อนยิ่งขึ้น และการขาดบริการของ Google มีส่วนทำให้เกิดความต่อเนื่องได้อย่างไร ความยุ่งเหยิง.

ไม่ว่านักพัฒนาแอปจำนวนมากจะรู้สึกหงุดหงิดกับการปรับแต่งพฤติกรรมแพลตฟอร์ม Android เหล่านี้ ซึ่งส่งผลให้นักพัฒนาแสดงความคิดเห็น ถาม Google ว่าพวกเขากำลังทำอะไรเกี่ยวกับเรื่องนี้ ไปที่ด้านบนของ Reddit AMA นี่คือคำตอบของ Google:

มีบางสิ่งที่ควรหลีกเลี่ยงจากการตอบกลับนี้ ประการแรก Google ต้องการให้ OEM มีความโปร่งใสมากขึ้นกับผู้ใช้เกี่ยวกับข้อจำกัดของแอปพื้นหลังที่พวกเขาบังคับใช้ ฉันตรวจสอบเอกสารคำจำกัดความความเข้ากันได้ของ Android 11 (CDD) (ยังไม่ได้เผยแพร่) และพบข้อเสนอเพิ่มเติมต่อไปนี้ในส่วนที่ 3.5 - ความเข้ากันได้ของพฤติกรรม API:

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

[C-1-5] ต้องแจ้งให้ผู้ใช้ทราบหากมีการใช้ข้อจำกัดของแอปกับแอปโดยอัตโนมัติ (ใหม่) ต้องไม่ให้ข้อมูลดังกล่าวก่อน 24 ชั่วโมงก่อนที่จะใช้ข้อจำกัดดังกล่าว

(หมายเหตุ) การบังคับให้หยุดถือว่ามีข้อจำกัดมากกว่า "หายาก" และต้องเป็นไปตามข้อกำหนดทั้งหมดภายใต้ 3.5.1 รวมถึง 3.5.1/C-1-5 ใหม่

โดยพื้นฐานแล้ว Google ไม่ได้หยุดไม่ให้ OEM ใช้งานฟีเจอร์การฆ่าแอปที่มีข้อจำกัดของตัวเองมากนัก พวกเขาเพียงต้องการให้ OEM แจ้งให้ผู้ใช้ทราบหากมีการนำข้อจำกัดของแอปไปใช้โดยอัตโนมัติ OEM สามารถแสดงกล่องโต้ตอบว่าพวกเขากำลังจะหยุดแอปพื้นหลังที่ดูดแบตเตอรี่ไม่ให้ทำงานใน พื้นหลัง และผู้ใช้สามารถยินยอมได้โดยไม่ทราบว่ามีแอปที่ต้องการทำงานในเบื้องหลังด้วย ได้รับผลกระทบ! Google มอบความรับผิดชอบให้กับนักพัฒนาซอฟต์แวร์ในการจัดการกับกรณีที่แอปของพวกเขาถูกหยุดทำงานโดยไม่คาดคิดในเบื้องหลัง อันที่จริงความคิดเห็นของ Reddit ยังคงเน้นย้ำถึงสิ่งใหม่ "เหตุผลในการออกจากกระบวนการแอป" API ที่สามารถบอกนักพัฒนาได้ว่าแอปของพวกเขาถูกฆ่าโดยผู้ใช้ ระบบปฏิบัติการ หรือเพียงแค่ขัดข้องเท่านั้น

ในทางกลับกัน ในที่สุด Google ก็จัดการกับแนวทางปฏิบัติที่ไม่เป็นธรรมของ OEM ที่อนุญาตให้แอปพลิเคชันที่ได้รับสิทธิ์บางรายการสามารถข้ามข้อจำกัดของแอปพื้นหลังได้ โพสต์ขนาดกลางนี้โดยนักพัฒนา ทิโมธี อาซิมเว ลงรายละเอียดเกี่ยวกับแอปต่างๆ เช่น WhatsApp, Facebook และแอปอื่นๆ จะได้รับการยกเว้นโดยอัตโนมัติจากข้อจำกัดพื้นหลังที่รุนแรงของซอฟต์แวร์ OEM บางตัว Google กล่าวว่าพวกเขา "กำหนดให้ผู้ผลิตอุปกรณ์ไม่สร้างรายการอนุญาตสำหรับแอปยอดนิยม" เราไม่รู้ว่าสิ่งนี้จะบังคับใช้อย่างไร แต่ เป็นเรื่องดีที่รู้ว่าในที่สุด OEM จะถูกบังคับให้ปฏิบัติต่อนักพัฒนาบุคคลที่สามอย่างเท่าเทียม ไม่ว่าแอปจะเล็กหรือใหญ่แค่ไหนก็ตาม เป็น.

ในที่สุด Google ยังกล่าวถึงวิธีที่ Android 11 ได้ "เพิ่มมาตรการพิเศษเพื่อป้องกันพฤติกรรมที่ไม่เหมาะสมโดยแอปที่ทำงานผิดปกติ" ทำให้ OEM ล่อลวงน้อยลงในการฆ่ากระบวนการในเบื้องหลังอย่างแข็งขัน อย่างไรก็ตาม บริษัทไม่ได้ให้รายละเอียดว่า "มาตรการพิเศษ" เหล่านี้เกี่ยวข้องกับอะไร

ปรับปรุงการสำรองข้อมูลแบบอุปกรณ์ต่ออุปกรณ์

เมื่อเดือนที่แล้ว เราพบการเปลี่ยนแปลงในเอกสารของ Android 11 บอกเป็นนัยถึงการสนับสนุนการสำรองข้อมูลในเครื่องที่ดีขึ้น. ใน Android 11 ระบบจะเพิกเฉยต่อแอตทริบิวต์ AllowBackup Manifest สำหรับแอปใดๆ ที่กำหนดเป้าหมาย API ระดับ 30 เมื่อผู้ใช้เริ่มต้นการย้ายไฟล์แอปแบบ "อุปกรณ์ต่ออุปกรณ์" Googler Eliot Stock กล่าวว่าคุณลักษณะนี้มีจุดมุ่งหมายเพื่อให้ "ผู้ผลิตโทรศัพท์สามารถสร้างเครื่องมือการย้ายอุปกรณ์ไปยังอุปกรณ์ได้ง่ายขึ้นมาก" เช่น "ผลิตภัณฑ์ Smart Switch ที่ยอดเยี่ยมของ Samsung" ช่วย "รับประกันว่าแอปจะถ่ายโอนระหว่างอุปกรณ์ได้อย่างน่าเชื่อถือมากขึ้นจากมุมมองของผู้ใช้" น่าเศร้าที่สิ่งนี้ใช้ไม่ได้กับการสำรองข้อมูลบนคลาวด์ เนื่องจาก Google ต้องการ "ให้นักพัฒนาซอฟต์แวร์ควบคุมสิ่งใดได้ เกิดขึ้นกับข้อมูลแอปของพวกเขา" ดังนั้น Android 11 จะยังคงเคารพแอตทริบิวต์ AllowBackup สำหรับการสำรองข้อมูลและกู้คืนบนคลาวด์ เช่น ผ่าน Google Drive ในตัวของ Google Play Service การสำรองข้อมูล สุดท้ายนี้ Google รับทราบว่าเพดานการสำรองข้อมูลขนาด 25MB ต่อแอปอาจไม่เพียงพอสำหรับนักพัฒนาบางราย ดังนั้นพวกเขาจึงมองหาวิธีแก้ปัญหาดังกล่าว อย่างไรก็ตาม การสำรองข้อมูลในเครื่องไปยังพีซีนั้นไม่ได้อยู่ภายใต้การพิจารณา และ Google ย้ำแผนของพวกเขาอีกครั้ง ยุติการสำรองข้อมูล adb ในการเปิดตัว Android ในอนาคต

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

ความเร็วการเริ่มต้นแอปที่เร็วขึ้นด้วยกระบวนการอ่านล่วงหน้า I/O (IORap)

Google ทดลองวิธีปรับปรุงประสิทธิภาพใน Android อยู่เสมอ หนึ่งในคุณสมบัติที่รู้จักกันน้อยที่พวกเขาเพิ่มใน Android 10 เรียกว่า Unspecialized App Process Pool (USAP) ฟีเจอร์นี้ช่วยลดการฟอร์กไซโกตในระหว่างกระบวนการเริ่มต้นแอป ซึ่งช่วยประหยัดเวลาในการเริ่มแอปโดยเฉลี่ยประมาณ 5 มิลลิวินาทีบนอุปกรณ์ Pixel 2 คุณลักษณะนี้อยู่ในปัจจุบัน ปิดใช้งานตามค่าเริ่มต้นใน AOSPและ Google อธิบายว่าการใช้หน่วยความจำเพิ่มเติมยังคงต้องมีการทดสอบ สิ่งที่น่าสนใจกว่านั้นคือฟีเจอร์ใหม่ที่มากับ Android 11 ที่เรียกว่า I/O Read Ahead Process (ไอโอแร็พ). ตามที่ Googleคุณลักษณะนี้จะนำไปสู่ ​​"การเริ่มต้นเย็นที่เร็วขึ้นมากกว่า 5% พร้อมเคสฮีโร่ที่เร็วขึ้นถึง 20%" คุณสมบัตินี้ "จะดึงข้อมูลสิ่งประดิษฐ์ของแอปพลิเคชันล่วงหน้า (เช่น รหัสและทรัพยากร) ในระหว่างกระบวนการเริ่มต้น" เพื่อเพิ่มการเปิดตัวแอป ความเร็ว

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

การเปลี่ยนแปลงพื้นที่เก็บข้อมูลที่กำหนดขอบเขตของ Android 11 - เหตุใดการเข้าถึง / ดาวน์โหลดจึงถูกจำกัด

แอปที่กำหนดเป้าหมายเป็น Android 11 และใช้ความตั้งใจ ACTION_OPEN_DOCUMENT_TREE เพื่อขอการเข้าถึงไดเรกทอรีเฉพาะภายนอก ที่เก็บข้อมูลจะไม่สามารถขอให้ผู้ใช้เข้าถึงไดเร็กทอรีรากของที่จัดเก็บข้อมูลภายนอก (/data/media/{user}) การดาวน์โหลดได้อีกต่อไป ไดเร็กทอรี (/data/media{user}/Download) หรือไดเร็กทอรีข้อมูลเฉพาะแอปใดๆ บนที่จัดเก็บข้อมูลภายนอก (/Android/data หรือ /Android/obb). เหตุใดการเข้าถึงไดเร็กทอรีดาวน์โหลดจึงถูกจำกัด? อ้างอิงจาก Google Roxanna Aliabadiเนื่องจากโฟลเดอร์ดาวน์โหลด "มีความเสี่ยงที่จะมีข้อมูลส่วนตัวมากที่สุด" ตัวอย่างเช่น ผู้ใช้ที่ดาวน์โหลดภาษีของตน การคืนสินค้าหรือใบแจ้งยอดธนาคารไม่ควรต้องกังวลเกี่ยวกับความเป็นไปได้ที่แอปจะใช้การเข้าถึงการอ่านอย่างต่อเนื่องในทางที่ผิด ไดเรกทอรี Google บอกว่าตัวเลือกเอกสารจะมี "ข้อความที่อัปเดต...เพื่อระบุว่า Android ได้จำกัดบางโฟลเดอร์ ที่จะเลือก" หวังว่านี่จะช่วยลดความสับสนว่าทำไมพวกเขาจึงไม่สามารถให้สิทธิ์แอปเข้าถึงบางไดเร็กทอรีได้ อีกต่อไป.

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงนโยบาย Scoped Storage and Play ที่กำลังจะมีขึ้น อ้างถึงบทความนี้.

หัวข้อเบ็ดเตล็ด

• จุดยืนของ Google เกี่ยวกับการรูท / การดัดแปลง
  • Jeff Bailey จากทีม AOSP ของ Google ย้ำจุดยืนของบริษัทในการสนับสนุนทางเลือก Google จะ "ดำเนินการเพื่อให้แน่ใจว่าการดัดแปลง/การรูทอุปกรณ์ Pixel line นั้นเป็นไปได้" แต่จะ "สนับสนุนตัวเลือกของ OEM ที่จะไม่อนุญาตให้อุปกรณ์ของพวกเขาด้วย ได้รับการรูท" นอกจากนี้ Google ยังให้ทางเลือกแก่นักพัฒนาซอฟต์แวร์ "ไม่อนุญาตให้ซอฟต์แวร์ทำงานบนอุปกรณ์ที่รูท" โดยอ้างอิงถึงการเปลี่ยนแปลงล่าสุดใน การตรวจจับการปลอมแปลงซอฟต์แวร์ของ SafetyNet Attestation API.
• เกิดอะไรขึ้นกับ "เปิดและตั้งค่าเป็นค่าเริ่มต้น"
  • สร้าง Android 10 แล้ว การตั้งแอปเป็นตัวจัดการเริ่มต้นเป็นเรื่องที่น่ารำคาญเล็กน้อย สำหรับลิงก์เฉพาะซึ่ง Google กล่าวว่าทำเพื่อปกป้องผู้ใช้จาก "แอปที่แสวงหาผลประโยชน์" Google สำรองลง เกี่ยวกับการเปลี่ยนแปลงนี้หลังจากคิดใหม่ทำ "การเปลี่ยนแปลงเบื้องหลังจำนวนหนึ่ง" เพื่อปกป้องผู้ใช้
• ใช้ Vulkan Graphics API เพื่อเรนเดอร์ UI หรือไม่
  • ในที่สุด Google ก็วางแผนที่จะใช้ Vulkan Graphics API เพื่อเรนเดอร์ UIซึ่งจะทำให้ประสิทธิภาพดีขึ้นบ้าง นี่คือ ยังอยู่ระหว่างการประเมินแต่บริษัทไม่มีข้อมูลเฉพาะเจาะจงที่จะเปิดเผย
• CallScreeningService หายไปในอุปกรณ์จำนวนมาก
  • แอพ Android สามารถใช้งาน CallScreeningService API เพื่อดักรับสายเรียกเข้าและโทรออกใหม่ ทำให้สามารถระบุผู้โทรและรับหรือปฏิเสธสายได้ แม้ว่านี่จะเป็น API ที่ได้รับการบันทึกไว้อย่างเป็นทางการ แต่ก็มี OEM จำนวนมากที่ใช้งานไม่ถูกต้อง ตามที่นักพัฒนา /u/_ศูนย์มด_. Google ยืนยัน API นี้ได้รับการตรวจสอบโดยชุดทดสอบความเข้ากันได้ (CTS) ซึ่งเป็นชุดทดสอบอัตโนมัติที่อุปกรณ์ทั้งหมดต้องผ่านจึงจะถือว่าเข้ากันได้กับ Android ไม่ว่าด้วยเหตุผลใดก็ตาม API นี้จะส่งคืนค่าว่างเมื่อเรียกใช้บนอุปกรณ์จาก OEM เช่น Huawei, Vivo, Xiaomi หรือ Samsung ดังนั้นจึงเป็นไปได้ว่า OEM เหล่านี้จะมีจุดบกพร่องในซอฟต์แวร์ของตน
• ไม่มีแผนสำหรับเฟรมเวิร์กปลั๊กอินเสียง
  • นักพัฒนาถาม Google ว่าพวกเขาวางแผนที่จะใช้เฟรมเวิร์กปลั๊กอินเสียงเช่น Audio Units ของ Apple หรือไม่ คำตอบ คือว่ามันไม่น่าจะเกิดขึ้นในอนาคตอันใกล้นี้

คุณสามารถอ่านคำตอบทั้งหมดได้จากทีมวิศวกร Android ที่นี่. ทีมงานพูดคุยเล็กน้อยเกี่ยวกับ Java, Kotlin, ระบบบิลด์ Android, CameraX API และหัวข้ออื่นๆ ในความคิดเห็นบางส่วน นอกจากนี้ยังมีความคิดเห็นหลายประการเกี่ยวกับ Wear OS, Android TV และ Android Auto แต่ Google ส่วนใหญ่ย้ำอีกครั้ง งานที่มีอยู่ของพวกเขาบนแพลตฟอร์มเหล่านี้และแจ้งให้นักพัฒนาคอยติดตามข้อมูลเพิ่มเติมในระหว่างนี้ "Android นอกเหนือจากโทรศัพท์สัปดาห์เริ่มต้นวันที่ 10 สิงหาคม