Android 14 เตรียมสร้างประสบการณ์ที่ดียิ่งขึ้นสำหรับผู้ใช้แอปสโตร์ของบุคคลที่สามด้วย API ใหม่
Google Play เป็นร้านแอปที่ได้รับความนิยมสูงสุดในหมู่ผู้ใช้ Android แต่บางคนอาจโต้แย้งว่า Google Play ไม่ได้รับตำแหน่งสูงสุดพอสมควร Google ได้รับการตรวจสอบโดยหน่วยงานกำกับดูแลและหน่วยงานด้านกฎหมายทั่วโลกเนื่องจาก มันรักษาความโดดเด่นของแอพสโตร์ได้อย่างไร และไม่มีสัญญาณว่าแรงกดดันนี้จะคลายลงได้ทุกเมื่อ เร็วๆ นี้. นั่นอาจเป็นเหตุผลว่าทำไม Google จึงริเริ่มที่จะแนะนำคุณลักษณะใหม่ๆ ใน แอนดรอยด์ 14 ที่ปรับปรุงประสบการณ์สำหรับผู้ใช้ร้านแอปของบุคคลที่สาม
ร้านค้าแอปของบุคคลที่สามส่วนใหญ่บน Android ไม่สามารถแข่งขันกับ Google Play ได้อย่างแท้จริง และไม่ใช่เพียงเพราะการเลือกแอปของพวกเขา ในขณะที่ร้านแอปของบริษัทแรกที่ติดตั้งไว้ล่วงหน้ามีความสามารถในการอัปเดตแอปอัตโนมัติเสมอ แต่ร้านแอปของบริษัทอื่นเพิ่งจะสามารถอัปเดตแบบอัตโนมัติได้ไม่นานมานี้ Google เพิ่ม API ใน Android 12 ที่ช่วยให้แอปของบุคคลที่สามจัดเก็บอัปเดตแอปโดยที่ผู้ใช้ไม่ต้องดำเนินการ ซึ่งช่วยลดความยุ่งยากของ โดยใช้ร้านแอปของบุคคลที่สาม.
อย่างไรก็ตาม สิ่งนี้ยังทำให้ร้านแอปของบุคคลที่สามเสียเปรียบอย่างมากในแง่ของฟังก์ชันการทำงาน เพราะพวกเขาไม่สามารถรู้ได้ง่ายๆ
เมื่อไร การอัปเดตอัตโนมัติจริง ๆ จะปลอดภัย นั่นคือสิ่งที่ Google พยายามแก้ไขใน Android 14 ด้วย API ใหม่ที่ช่วยให้ร้านแอปของบุคคลที่สามสามารถดำเนินการ "อัปเดตแบบนุ่มนวล" ได้การปรับปรุงที่อ่อนโยน
Android 14 ได้เพิ่ม API ใหม่ที่ช่วยให้ร้านค้าแอปของบุคคลที่สามตรวจสอบว่าตรงตามเงื่อนไขบางอย่างหรือไม่ก่อนที่จะดำเนินการอัปเดตแอปโดยอัตโนมัติ เดอะ ตัวติดตั้งแพ็คเกจ ติดตั้ง Constraints API “สามารถใช้โดยร้านแอปเพื่อส่งการอัปเดตอัตโนมัติโดยไม่รบกวนประสบการณ์ของผู้ใช้ (เรียกว่าการอัปเดตแบบนุ่มนวล) - ตัวอย่างเช่น ร้านแอปอาจระงับการอัปเดตเมื่อพบว่า [sic] แอปที่จะอัปเดตกำลังโต้ตอบกับ ผู้ใช้”
API ใหม่นี้ช่วยให้ร้านค้าแอปของบุคคลที่สามตรวจสอบว่าแอปที่พวกเขากำลังเตรียมอัปเดตมีบริการเบื้องหน้าที่ใช้งานอยู่หรือไม่ (isRequireAppNotForeground) กำลังโต้ตอบกับผู้ใช้ไม่ทางใดก็ทางหนึ่ง (isRequireAppNotInteracting) หรืออยู่บนหน้าจอ (isRequireAppNotTopVisible). ร้านค้าแอปของบุคคลที่สามยังสามารถตรวจสอบว่าอุปกรณ์อยู่ในโหมดงีบหลับ (isRequireDeviceIdle) หรืออยู่ในโทรศัพท์ (isRequireNotInCall)
ในขณะที่ API อนุญาตให้ระบุเงื่อนไขที่จะตรวจสอบ เอกสารแนะนำการใช้ข้อจำกัดที่กำหนดไว้ล่วงหน้าเป็น "ระบบรู้ ทำอย่างไรจึงจะดีที่สุด” นี่เป็นเหตุผลที่ Google มีเวลามากมายในการพัฒนาวิธีที่ดีที่สุดในการจัดการการอัปเดตอัตโนมัติใน App Store ของตนเอง การใช้ค่าที่ตั้งไว้ล่วงหน้ายังมีประโยชน์ ดังที่ระบุไว้ในเอกสารประกอบ เนื่องจากความแม่นยำและประสิทธิภาพของการอัปเดตแบบนุ่มนวลอาจได้รับการปรับปรุงในรุ่นต่อๆ ไป หาก Google เพิ่มข้อจำกัดเพิ่มเติมให้กับ API
ทุกเงื่อนไขที่ PackageInstaller. InstallConstaints API ช่วยให้การตรวจสอบสามารถตรวจสอบผ่าน API ที่มีอยู่ได้ แต่การมีระบบจัดการการตรวจสอบเหล่านี้ทำได้ง่ายกว่ามากและเป็นการรบกวนน้อยกว่ามาก ตัวอย่างเช่น ร้านแอปของบริษัทอื่นที่ต้องการตรวจสอบว่ามีการใช้งานแอปที่พวกเขากำลังอัปเดตอยู่หรือไม่ โดยปัจจุบันผู้ใช้จะต้องใช้ API อย่าง UsageStats หรือ AccessibilityService ซึ่งทั้ง Sensitive สิทธิ์ หากพวกเขาใช้ Android 14 API ใหม่นี้ พวกเขาไม่ต้องการสิทธิ์เหล่านี้ในการทำงาน
อัปเดตความเป็นเจ้าของ
การเปิดใช้งาน "การอัปเดตแบบนุ่มนวล" ไม่ใช่การปรับปรุงเฉพาะใน Android 14 สำหรับร้านค้าแอปของบุคคลที่สาม นอกจากนี้ยังมีกลไก "อัปเดตความเป็นเจ้าของ" แบบใหม่ที่ช่วยให้ร้านค้าแอปของบุคคลที่สามกลายเป็นแหล่งที่มาพิเศษสำหรับการอัปเดตอัตโนมัติในอนาคตสำหรับแอปที่พวกเขาติดตั้งครั้งแรก นี่หมายความว่าหากคุณใช้ร้านแอปของบุคคลที่สาม เนื่องจากแอปที่มีให้นั้นผ่านการตรวจสอบโดย ชุมชน ตัวอย่างเช่น การอัปเดตที่ยังไม่ได้ตรวจสอบซึ่งมีให้ใน App Store อื่นๆ จะไม่ได้รับการพุชโดยอัตโนมัติ อุปกรณ์ของคุณ
ในตอนนี้ เมื่อคุณติดตั้งแอปผ่านร้านแอปของบริษัทอื่น จะไม่มีสิ่งใดขัดขวางไม่ให้ร้านแอปของบริษัทอื่นอัปเดตแอปนั้น แม้ว่า API การอัปเดตแบบไม่ต้องใส่ข้อมูลของ Android 12 จะอนุญาตให้ร้านค้าแอปของบุคคลที่สามอัปเดตแอปที่ติดตั้งครั้งแรกอย่างเงียบ ๆ เท่านั้น แต่ร้านค้าแอปของบุคคลที่หนึ่งจะไม่ได้รับผลกระทบใด ๆ เนื่องจากพวกเขาถือสิทธิพิเศษ INSTALL_PACKAGES การอนุญาต.
แอพสโตร์ของบุคคลที่สามบน Android 14 สามารถใช้แอพใหม่ได้ setRequestUpdateOwnership วิธีการใน ตัวติดตั้งแพ็คเกจ พารามิเตอร์เซสชันอย่างไรก็ตาม เพื่อบอกระบบว่าพวกเขากำลังอ้างสิทธิ์การเป็นเจ้าของการอัปเดตผ่านแอปที่พวกเขากำลังจะติดตั้ง เมื่อเปิดใช้งานการบังคับใช้การเป็นเจ้าของอัปเดตสำหรับแอปแล้ว ร้านแอปอื่นๆ ทั้งหมด — แม้กระทั่งร้านที่ได้รับอนุญาต INSTALL_PACKAGES — จำเป็นต้องดำเนินการจากผู้ใช้เพื่ออัปเดตแอป อัปเดตความเป็นเจ้าของสามารถเปิดใช้งานได้เฉพาะระหว่างการติดตั้งแอปครั้งแรก ดังนั้นร้านแอปอื่น จะไม่สามารถรับการอัปเดตได้เว้นแต่แอปที่เป็นปัญหาจะถูกถอนการติดตั้งและติดตั้งใหม่จากนั้น เก็บ. ร้านแอปสามารถตรวจสอบได้ว่ามีการเปิดใช้งานการเป็นเจ้าของการอัปเดตสำหรับแอปหรือไม่ และหากเปิดใช้งาน แอปใดเป็นเจ้าของการอัปเดตผ่านแอปใหม่ ติดตั้งSourceInfo#getUpdateOwnerPackageName() เอพีไอ
ร้านค้าแอปของบุคคลที่สามต้องถือใหม่ ENFORCE_UPDATE_OWNERSHIP การอนุญาตให้ใช้ API การบังคับใช้การเป็นเจ้าของการอัปเดต แต่เนื่องจากการอนุญาตนี้มีระดับการป้องกันเป็น "ปกติ" ระบบจะอนุญาตเมื่อติดตั้ง อย่างไรก็ตาม ต้องรอดูว่า Google Play จะตรวจสอบการใช้สิทธิ์/API นี้หรือไม่
ติดตั้งการอนุมัติล่วงหน้า
Android 14 API ล่าสุดที่ฉันอยากจะเน้นคือ ตัวติดตั้งแพ็คเกจ Session#requestUserPreapproval. API นี้ช่วยให้ร้านค้าแอปของบุคคลที่สามร้องขอการอนุมัติจากผู้ใช้ก่อนที่จะยอมรับเซสชันการติดตั้ง ฉันคิดว่าสิ่งนี้จะเป็นประโยชน์สำหรับร้านแอปของบุคคลที่สามที่ต้องการแจ้งผู้ใช้โดยเจตนาก่อนที่จะอัปเดตแอปในเบื้องหลัง
ตัวอย่างเช่น ลองนึกภาพร้านแอปที่เน้นความปลอดภัยต้องการแจ้งให้ผู้ใช้ทราบเมื่อการอัปเดตแอปเพิ่มการอนุญาตใหม่ แทนที่จะอัปเดตแอปนั้นโดยอัตโนมัติ ดังนั้นจะให้สิทธิ์นั้นโดยอัตโนมัติหากระดับการป้องกันเป็น "ปกติ" ร้านแอปสามารถเตือนผู้ใช้ก่อนที่จะทำการอัปเดต ในปัจจุบัน หากไม่มีผู้ใช้อยู่ระหว่างการอัปเดตอัตโนมัติ ร้านแอปของบุคคลที่สามจะต้องติดตามเซสชันการติดตั้งและแจ้งผู้ใช้ในภายหลัง API นี้ทำให้กระบวนการนั้นง่ายขึ้น
Android 14 จะแนะนำคุณสมบัติและ API ใหม่มากมายเมื่อเปิดตัวสู่สาธารณะในปลายปีนี้ แม้ว่า API ใหม่เหล่านี้จะไม่ถูกซ่อนเหมือนการเปลี่ยนแปลงอื่นๆ ที่เราพบ แต่ก็ไม่มีการรับประกันว่า API เหล่านี้จะพร้อมใช้งานสำหรับนักพัฒนาซอฟต์แวร์ในรุ่นเสถียร นั่นเป็นเพราะว่า API ค้างจะไม่เกิดขึ้นจนกว่า Android 14 จะเข้าสู่ "ความเสถียรของแพลตฟอร์ม" ด้วยเบต้า 3 ในเดือนมิถุนายน 2023 และขณะนี้เรากำลังใช้ DP1 เท่านั้น เราจะจับตาดูการเปิดตัว Android 14 DP และเบต้าในอนาคตเพื่อดูว่า API เหล่านี้ยังคงอยู่หรือไม่ หรือมีการเพิ่ม API ใหม่ที่เกี่ยวข้องกับ App Store ของบุคคลที่สามหรือไม่