Google ปล่อย Android 17 QPR2 แล้ว ทีมพัฒนาแอปควรทดสอบอะไรบ้าง

Google ปล่อย Android 17 QPR2 แล้วหรือยัง? Google ได้เริ่มทยอยปล่อยอัปเดตเสถียรของ Android 17 QPR2 ไปยังอุปกรณ์ Pixel ที่รองรับแล้ว ในขณะที่นักพัฒนาสามารถประเมินพฤติกรรมการทำงานของเฟรมเวิร์กในระดับแพลตฟอร์มได้ผ่านการใช้บิลด์ Generic System Image ที่มีให้ใช้งาน การปล่อยอัปเดตนี้มาเร็วกว่ากำหนดการประจำไตรมาสปกติ โดยเป็นการผสานฟีเจอร์ Pixel Drop สำหรับผู้ใช้งานทั่วไปเข้ากับการเปลี่ยนแปลงพื้นฐานในด้านสิทธิ์การติดตั้งแพ็กเกจ การจัดการการแจ้งเตือน และการบันทึกข้อมูลความเป็นส่วนตัวบนอุปกรณ์ สำหรับทีมวิศวกรรมและทีมเติบโตทางธุรกิจที่ดูแลแอปพลิเคชัน Android การทำความเข้าใจว่าการปรับแต่งแพลตฟอร์มเหล่านี้ส่งผลอย่างไรต่อขั้นตอนการติดตั้ง การมองเห็นการแจ้งเตือนแบบพุช และการส่งผ่านพารามิเตอร์ตามบริบท ถือเป็นสิ่งสำคัญอย่างยิ่งสำหรับการวางแผนรอบการปล่อยอัปเดตที่จะมาถึง

ขอบเขตแพลตฟอร์มหลัก: การแยกแยะระหว่าง OTA แบบเสถียร, บิลด์ GSI และกำหนดเวลาของ OEM

สรุปภาพรวม

• Google ได้ปล่อยบิลด์อัปเดตแบบ Over-the-air ของ Android 17 QPR2 แบบเสถียรให้กับฮาร์ดแวร์ Pixel ที่รองรับ ซึ่งครอบคลุมตั้งแต่ Pixel 6a ไปจนถึงอุปกรณ์รุ่นเรือธงล่าสุด
• การทดสอบของนักพัฒนาในระดับแพลตฟอร์มอาศัยไบนารีทดลองของ Generic System Image ที่สร้างขึ้นบนสถาปัตยกรรมที่รองรับ Treble แทนที่จะเป็นเฟิร์มแวร์การผลิตเต็มรูปแบบของ OEM
• การอัปเดตหลักๆ ได้แก่ หน้าต่างการอนุมัติโปรแกรมติดตั้งแพ็กเกจแบบสามสถานะ การควบคุมการแสดงผลการแจ้งเตือนแบบรวมศูนย์ และการบันทึกโมเดลบนอุปกรณ์แบบโปร่งใส

การทำความเข้าใจเกี่ยวกับการปล่อยอัปเดตแพลตฟอร์ม Android จำเป็นต้องแยกแยะระหว่างฟีเจอร์เฉพาะของอุปกรณ์และการอัปเดตเฟรมเวิร์กของระบบปฏิบัติการที่มีร่วมกัน แม้ว่า Google จะปล่อยแพ็กเกจ Over-the-air ของ Android 17 QPR2 สำหรับสมาร์ทโฟนและแท็บเล็ต Pixel แล้ว แต่กำหนดเวลาในการปล่อยอัปเดตสำหรับฮาร์ดแวร์ที่ไม่ใช่ Pixel นั้นจะขึ้นอยู่กับแผนงานการปล่อยอัปเดตของผู้ผลิตแต่ละราย การทดสอบของผู้ให้บริการเครือข่ายในภูมิภาค และกำหนดเวลาตามระดับของฮาร์ดแวร์

สำหรับการทดสอบในระบบนิเวศที่กว้างขึ้น Google ได้จัดเตรียมไบนารีตัวอย่างผ่าน เอกสารประกอบ GSI สำหรับนักพัฒนา Android และ บันทึกประจำรุ่น GSI ของ Android 17 QPR2 แพ็กเกจ Generic System Image (GSI) เหล่านี้สร้างขึ้นจาก AOSP และไลบรารีหลักที่ใช้ร่วมกัน ซึ่งช่วยให้สามารถทดสอบเบื้องต้นบนอุปกรณ์ที่รองรับ Treble ซึ่งเดิมจัดส่งมาพร้อมกับ Android 9 (API ระดับ 28) หรือสูงกว่า และมีการปลดล็อกบูตโลเดอร์ อย่างไรก็ตาม ทีมวิศวกรรมต้องตระหนักว่าบิลด์ GSI ทําหน้าที่เป็นสภาพแวดล้อมการทดลองสำหรับนักพัฒนาเท่านั้น โดยบิลด์ GSI ไม่ได้รับการรับรองจาก CTS ขาดบริการที่เป็นกรรมสิทธิ์เฉพาะของ OEM และไม่สามารถจำลองสภาพแวดล้อมรันไทม์ที่ปรับแต่งขั้นสุดท้ายของผู้ผลิตได้

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

เจาะลึกทางเทคนิค: การอนุญาต Sideloading และพฤติกรรมการแจ้งเตือน

การอัปเดตใน Android 17 QPR2 นำการปรับปรุงโครงสร้างมาใช้กับวิธีที่แอปพลิเคชันร้องขอสิทธิ์ในการติดตั้งและวิธีที่บริการของระบบควบคุมการแสดงผลการแจ้งเตือน

สถาปัตยกรรมการอนุมัติ Sideloading แบบสามสถานะ

เมื่อแอปพลิเคชัน—เช่น เว็บเบราว์เซอร์ ตัวจัดการไฟล์ หรือเครื่องมือแจกจ่ายสำหรับองค์กร—ริเริ่มการติดตั้งแพ็กเกจภายนอกโดยใช้โปรแกรมติดตั้งแพ็กเกจมาตรฐาน Android 17 QPR2 จะแทนที่ปุ่มสลับแบบไบนารีด้วยกล่องโต้ตอบสามสถานะ:

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

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

[โฟลว์การรับเข้าข้อมูลภายนอกแบบ Sideload ที่เป็นสมมติฐาน — เวิร์กฟลอกการทดสอบสำหรับนักพัฒนา]
ผู้ใช้เริ่มดาวน์โหลดไฟล์ APK โดยตรง (หน้า Landing Page ของเว็บ)
                       │
                       ▼
    [คำขออนุมัติโปรแกรมติดตั้งแพ็กเกจ]
                       │
         ┌─────────────┴─────────────┐
         │                                                      │
  [ครั้งนี้เท่านั้น]                                          [ไม่อนุญาต]
  (ให้สิทธิ์ชั่วคราว)                                              │
         │                                                      ▼
         ▼                                            [ยกเลิกการติดตั้ง]
  [ดำเนินการติดตั้ง]
         │
         ▼
  [เพิกถอนสิทธิ์เมื่อเสร็จสิ้น]
         │
         ▼
  [เปิดใช้งานแอปพลิเคชันครั้งแรก]
         │
         ▼
  [พยายามกู้คืนพารามิเตอร์ที่มีสิทธิ์]
         │
   ┌─────┴─────┐
   │                      │
(สำเร็จ)     (ไม่พร้อมใช้งาน / หมดเวลา)
   │                      │
   ▼                      ▼
[กำหนดเส้นทางเป้าหมาย]  [หน้าแรกเริ่มต้น]

การควบคุมการแสดงผลการแจ้งเตือนและระยะเวลาพัก (Cooldown)

การส่งการแจ้งเตือนแบบพุชเกี่ยวข้องกับขั้นตอนที่แตกต่างกัน ได้แก่ การส่งในชั้นการขนส่ง (transport-layer) การแสดงผลในระดับระบบ การแจ้งเตือนแบบเตือน และการโต้ตอบของผู้ใช้ Android 17 QPR2 ปรับเปลี่ยนวิธีการแสดงผลและจัดลำดับความสำคัญของการแจ้งเตือนบนอุปกรณ์ของลูกค้า

ภายใต้การตั้งค่าแถบสถานะที่อัปเดต ผู้ใช้สามารถเลือกได้ว่าระบบจะแสดงไอคอนการแจ้งเตือนทั้งหมด เฉพาะไอคอนลำดับความสำคัญ หรือไม่แสดงไอคอนเลย ในขณะเดียวกัน แพลตฟอร์มได้รวมการควบคุมการแจ้งเตือนเข้าเป็นระบบเดียวที่มีฟีเจอร์ระยะเวลาพักการแจ้งเตือนอัตโนมัติ ตามรายละเอียดใน เอกสารช่วยเหลือของ Google เกี่ยวกับการแจ้งเตือนของ Android ระยะเวลาพักการแจ้งเตือนจะช่วยลดระดับเสียงแจ้งเตือนและลดความถี่ของป๊อปอัปแบบ Heads-up เมื่อแอปพลิเคชันส่งข้อความรัวๆ ภายในระยะเวลาอันสั้น

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

นอกจากนี้ การบันทึกข้อมูลของ Private Compute Core ช่วยให้มองเห็นคำขอที่รองรับซึ่งส่งออกจาก PCC ตามที่ระบุไว้ใน เอกสารช่วยเหลือของ Google เกี่ยวกับ Private Compute Core เอกสารระบบปัจจุบันระบุว่าคำขอความช่วยเหลือเชิงรุก (Proactive Assistance) เป็นขอบเขตการบันทึกที่มีอยู่ ฟีเจอร์นี้ไม่ควรตีความว่าเป็นการตรวจสอบการทำงานของโมเดลทั้งหมดบนอุปกรณ์ในแอปพลิเคชันของบุคคลที่สามอย่างละเอียดถี่ถ้วน

การจัดการบริบทแคมเปญผ่าน APK โดยตรงและช่องทางการแจกจ่ายทางเลือก

เมื่อแคมเปญการตลาดแจกจ่ายแอปพลิเคชันนอกเหนือจาก App Store หลักผ่านการดาวน์โหลดเว็บโดยตรง การรักษาบริบทของแคมเปญจะก่อให้เกิดความท้าทายทางวิศวกรรมที่ไม่เหมือนใคร ในการแจกจ่ายผ่าน Google Play Store นักพัฒนาสามารถดึงข้อมูลพารามิเตอร์แคมเปญผ่าน เอกสารประกอบ Google Play Install Referrer API ที่จัดเตรียมโดยแอปพลิเคชันไคลเอนต์ Google Play Store อย่างไรก็ตาม การดาวน์โหลดผ่านเว็บเบราว์เซอร์โดยตรงจะข้ามโครงสร้างพื้นฐานของ Google Play Store ไปอย่างสิ้นเชิง

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

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

ในเวิร์กโฟลว์การแจกจ่ายโดยตรงที่รองรับ เครื่องมือเฉพาะทาง เช่น เอกสารประกอบ OpoInstall มีความสามารถในการเชื่อมโยงลึกแบบหน่วงเวลา (Deferred Deep Linking) เพื่อเชื่อมช่องว่างของบริบทระหว่างแคมเปญเว็บและการเปิดใช้งานแอปเนทีฟ เมื่อผู้ใช้ดาวน์โหลดไฟล์ APK ผ่านหน้า Landing Page ของเว็บ เฟรมเวิร์กจะสามารถจับตัวระบุแคมเปญที่มีสิทธิ์หรือพารามิเตอร์การกำหนดเส้นทางแบบกำหนดเอง และทำให้แอปพลิเคชันสามารถใช้งานได้เมื่อมีการเรียกใช้งานหลังการติดตั้งครั้งแรก

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

เมทริกซ์การทดสอบสำหรับนักพัฒนา: การตรวจสอบทีละขั้นตอนสำหรับ Android 17 QPR2

ทีมวิศวกรรม QA และทีมเติบโตควรโครงสร้างการทดสอบการถดถอยรอบพฤติกรรมของแพลตฟอร์มที่สังเกตได้ แทนที่จะใช้สมมติฐานทางทฤษฎี

การตรวจสอบการอนุมัติ Sideloading

• กรณีทดสอบ: เริ่มต้นการติดตั้ง APK โดยตรงจากเว็บเบราว์เซอร์และเลือก "ครั้งนี้เท่านั้น"
• พฤติกรรมที่คาดหวัง: โปรแกรมติดตั้งแพ็กเกจควรทำการติดตั้งให้เสร็จสมบูรณ์ แต่ความพยายามในการติดตั้งครั้งต่อๆ ไปจากเบราว์เซอร์เดิมจะต้องแจ้งเตือนผู้ใช้อีกครั้ง
• กรณีเกิดข้อผิดพลาด (Fallback): ตรวจสอบว่ากิจวัตรการติดตั้งแบบโมดูลาร์หรือหลาย APK จัดการกับการเพิกถอนสิทธิ์ได้อย่างราบรื่นโดยไม่โยนข้อยกเว้นด้านความปลอดภัยที่ไม่ได้รับการจัดการ

ระยะเวลาพักการแจ้งเตือนและการแสดงผลแถบสถานะ

• กรณีทดสอบ: ส่งชุดการทดสอบการแจ้งเตือนพุชโปรโมชันจำนวน 5 รายการภายใน 60 วินาทีไปยังอุปกรณ์ทดสอบ
• พฤติกรรมที่คาดหวัง: สังเกตว่าระบบปิดเสียงการแจ้งเตือนหรือระงับแบนเนอร์แสดงผลแบบ Heads-up หลังจากการแจ้งเตือนครั้งแรกหรือไม่ โปรดทราบว่าช่องทางที่มีความสำคัญสูงไม่ได้มีความหมายเหมือนกับการสนทนาที่มีลำดับความสำคัญซึ่งได้รับการยกเว้นจากระยะเวลาพักโดยอัตโนมัติ
• การออกแบบกรณีเกิดข้อผิดพลาด: ตรวจสอบให้แน่ใจว่าการแจ้งเตือนธุรกรรมที่สำคัญถูกจัดหมวดหมู่ภายใต้ช่องทางลำดับความสำคัญที่เหมาะสม เพื่อหลีกเลี่ยงการปิดเสียงโดยไม่ได้ตั้งใจ

การกำหนดเส้นทาง Intent และลิงก์แอป

• กรณีทดสอบ: ทริกเกอร์ URL ลิงก์ลึกที่มีพารามิเตอร์โปรโมชันทั้งในเว็บเบราว์เซอร์เนทีฟและเว็บวิวภายนอก
• พฤติกรรมที่คาดหวัง: Android App Links ที่กำหนดค่าไว้อย่างถูกต้องสามารถแก้ไขไปยัง Activity ปลายทางได้โดยตรงเมื่อได้รับการสนับสนุนจากเบราว์เซอร์ เปิดใช้งานในการตั้งค่าผู้ใช้ และตรวจสอบความถูกต้องอย่างถูกต้องโดยเจ้าของโดเมน
• การออกแบบกรณีเกิดข้อผิดพลาด: จัดเตรียมมุมมองเริ่มต้นที่มีความทนทานเมื่อพารามิเตอร์ Intent ที่เข้ามามีความผิดพลาด ขาดหายไป หรือล่าช้า

ข้อคิดสำคัญสำหรับทีมวิศวกรรม

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

สำหรับทีมพัฒนา การเตรียมตัวสำหรับการอัปเดตแพลตฟอร์มจำเป็นต้องมีการตรวจสอบวงจรการติดตั้งและแยกสถานะแอปพลิเคชันที่สำคัญออกจากสมมติฐานฝั่งไคลเอนต์ที่เปราะบาง เมื่อเส้นทางของผู้ใช้ยังคงอยู่ภายในเว็บวิวเดียวหรือแอปพลิเคชันเนทีฟ การส่งผ่านพารามิเตอร์การติดตั้งก็ไม่มีความจำเป็น อย่างไรก็ตาม เมื่อแคมเปญนำผู้ใช้จากหน้า Landing Page ของเว็บภายนอกไปสู่การดาวน์โหลด APK โดยตรง การรักษาความต่อเนื่องของการแปลงอาจต้องอาศัย API ผู้อ้างอิงแพลตฟอร์ม การรักษาพารามิเตอร์ฝั่งเซิร์ฟเวอร์ หรือกลไกการส่งต่ออื่นที่รองรับ ควบคู่ไปกับการตรวจสอบความถูกต้องของธุรกรรมอย่างเข้มงวดบนแบ็กเอนด์

ข้อมูลอ้างอิง

• Android Developers: เอกสารและข้อกำหนดของ Generic System Image

• Android Developers: บันทึกประจำรุ่น GSI ของ Android 17 QPR2

• Google Developers: เอกสารประกอบ Google Play Install Referrer API

• Google Help: จัดการการแจ้งเตือนบนอุปกรณ์ Android

• Google Help: เรียนรู้วิธีที่ Private Compute Core ปกป้องความเป็นส่วนตัวของคุณ

• 9to5Google: รายละเอียดการปล่อยอัปเดต Android 17 QPR2 และสรุปฟีเจอร์

• Droid-Life: ภาพรวม UI ระบบ Android 17 QPR2 และการควบคุมแถบสถานะ

• OpoInstall Documentation: การเชื่อมโยงลึกแบบหน่วงเวลาและการส่งผ่านพารามิเตอร์