หากไม่มีซอร์สโค้ด นักพัฒนาจะได้รับส่วนประกอบฮาร์ดแวร์ เช่น กล้องที่ทำงานใน ROM แบบกำหนดเองได้อย่างไร คำตอบคือ BLOB, shim และการดีบักมากมาย
ด้วยการเปิดตัวระบบปฏิบัติการ Android Oreo และอุปกรณ์อีกมากมายเช่น เสี่ยวมี่ เรดมี่ โน๊ต 3, กูเกิล เน็กซัส 5 และ คนอื่น ๆ ได้รับมันอย่างไม่เป็นทางการอาจเป็นเรื่องที่ยุติธรรมที่จะสงสัยว่าเหตุใดคุณสมบัติเดียวกัน (ส่วนใหญ่เป็นกล้อง) จึงมีแนวโน้มที่จะใช้งานไม่ได้เมื่อนักพัฒนาพอร์ต ROM ที่ใช้ Android Open Source Project (AOSP) คุณคงเคยเห็นกระทู้ XDA ของ ROM ที่มีรายการฟีเจอร์ที่ใช้งานไม่ได้มากมายอยู่ด้านบน “อะไรได้ผล” ตามด้วยรายการฟีเจอร์การทำงาน จากนั้นด้านล่างจะมีสัญลักษณ์ “อะไรใช้ไม่ได้? คุณบอกฉัน!" เป็นสองประโยคที่ได้รับความนิยมในฟอรัมของเรา ซึ่งกลายมาเป็นมีมในสถานที่ต่างๆ เช่น Reddit และ Twitter
เหตุใดฟังก์ชันการทำงานมากมายจึงใช้งานไม่ได้ทุกครั้งที่นักพัฒนาพยายามพอร์ต AOSP ROM ไปยังอุปกรณ์ของตน คำตอบพื้นฐานก็คือ เนื่องจากฟังก์ชันต่างๆ เปลี่ยนไปใน Android เวอร์ชันต่างๆ ไดรเวอร์อุปกรณ์เก่าที่แพ็กเกจเป็น BLOB จะไม่ทำงานกับ Android เวอร์ชันใหม่กว่า หรือแม้แต่กับ AOSP ในสต็อกเท่านั้น เพื่อเอาชนะสิ่งนั้น นักพัฒนาจึงใช้สิ่งที่เรียกว่า "ชิม" แต่กระบวนการที่เกี่ยวข้องนั้นยุ่งยาก ใช้เวลานาน และบางครั้งก็ยากมากในการแก้ไข
ในบทความนี้ เราจะสรุปวิธีการทำงานของชิม โดยเฉพาะอย่างยิ่งในการทำให้กล้องทำงานอย่างถูกต้องบน ROM ที่ใช้ AOSP เราจะใช้ OnePlus 3T เป็นตัวอย่าง โปรดทราบว่าความยากลำบากในการทำให้ฟีเจอร์เหล่านี้ทำงานได้นั้นมีความเฉพาะเจาะจงกับอุปกรณ์เป็นอย่างมาก
OnePlus 3T รัน OxygenOS แม้ว่าโทรศัพท์ OnePlus จะขึ้นชื่อในเรื่องความเป็นมิตรต่อการพัฒนาแบบกำหนดเอง แต่ก็มีงานมากมายที่นักพัฒนาทำเบื้องหลังเพื่อสร้างพอร์ตที่เสถียรของ AOSP
ชิมหรือ BLOB คืออะไร?
เพื่อเริ่มเข้าใจส่วนหนึ่งของสิ่งที่นักพัฒนากำลังทำ เราต้องอธิบายบางสิ่งก่อน แม้ว่า Android OS จะเป็นโอเพ่นซอร์ส (เรียกว่า Android Open Source Project ด้วยเหตุผล) แต่ซอฟต์แวร์ (ไม่มีเคอร์เนล) ที่จัดส่งบนอุปกรณ์ Android นับพันเครื่องนั้นไม่ใช่ นักพัฒนาไม่สามารถเข้าถึงซอร์สโค้ดของ ประสบการณ์ซัมซุง, EMUI, อ็อกซิเจนโอเอสหรือรสชาติอื่นๆ ของบุคคลที่สามของ Android
ตอนนี้นักพัฒนาที่ย้ายสต็อก AOSP ไปยังอุปกรณ์ที่ไม่ใช่ของ Google อาจไม่สนใจซอร์สโค้ดของสกิน Android เหล่านี้เนื่องจากจะไม่ได้เป็นเช่นนั้น การแก้ไขและสร้าง ROM เหล่านี้ นั่นคงจะเป็นจริง หากไม่ใช่ด้วยเหตุผลใหญ่ๆ ประการเดียว นั่นคือชิ้นส่วนที่จำเป็นเพื่อให้กล้องทำงานได้อย่างถูกต้องเป็นหลัก ที่ กล้องฮาล (Hardware Abstraction Layer) ได้แก่ แหล่งปิดด้วย.
ปัญหาของการไม่เพียงแค่มีกล้อง HAL เท่านั้น แต่ยังรวมถึง ROM แบบปิดด้วยก็คือนักพัฒนาที่ทำงานเกี่ยวกับพอร์ต AOSP ไปยังอุปกรณ์ของพวกเขาจะ ทำงานตาบอด. OEM ROM แบบปิดสามารถเชื่อมต่อกับกล้อง HAL ได้ดีเนื่องจาก OEM สามารถเข้าถึงแหล่ง HAL ของกล้องได้ HAL ของกล้องคือสิ่งที่ทำให้ ROM สามารถ "พูดคุยกับ" ฮาร์ดแวร์ของกล้องได้ หากไม่มีมัน กล้องก็จะไม่ทำงาน คิดว่ากล้อง HAL เป็นพวงมาลัยและแป้นเหยียบของรถ พวงมาลัย/คันเหยียบช่วยให้สามารถควบคุมส่วนประกอบภายในของรถได้โดยการจัดให้มีอินเทอร์เฟซภายนอกสำหรับผู้ขับขี่ (ROM) เพื่อใช้ประโยชน์จากส่วนประกอบภายใน
เนื่องจากฮาร์ดแวร์ของกล้องมีความซับซ้อนมากขึ้นเรื่อยๆ (the การมาถึงของกล้องคู่) การเข้าถึงแหล่ง HAL ของกล้องจะทำให้การย้าย AOSP ROM ด้วยกล้องที่ใช้งานได้ง่ายกว่ามาก
อย่างไรก็ตาม OEM ไม่อนุญาตให้เข้าถึงแหล่ง HAL ของกล้องด้วยเหตุผลหลายประการ ประการแรก หากพวกเขาไม่มีสิทธิ์การเป็นเจ้าของกล้อง HAL ทั้งหมด (เช่น เมื่อรวมทรัพย์สินทางปัญญาจากบริษัทอื่น) พวกเขาจะไม่สามารถเผยแพร่แหล่งที่มาได้ ประการที่สอง การปล่อยแหล่ง HAL ของกล้องอาจเป็นอันตรายต่อทรัพย์สินทางปัญญาของตนเอง สุดท้ายนี้ บริษัทต่างๆ ไม่มีภาระผูกพันทางกฎหมายที่จะต้องจัดเตรียมซอร์สโค้ดนี้ (ไม่เหมือนกับซอร์สโค้ดเคอร์เนลที่เป็นอยู่) จำเป็นต้องปล่อยภายใต้ GPL) ดังนั้นพวกเขาจึงไม่มีแรงจูงใจที่จะปล่อยมัน ดังนั้นหากไม่มีการเข้าถึงแหล่ง HAL ของกล้อง นักพัฒนาจะทำให้กล้องทำงานบน AOSP ROM ได้อย่างไร คำตอบคือ BLOB, shim และการดีบักมากมาย
อุปกรณ์ หยด (Binary Large OBject) ประกอบด้วยไบนารีที่บรรจุไว้ล่วงหน้าซึ่งเป็นรูปแบบซอฟต์แวร์ที่คอมไพล์ ในกรณีนี้ แหล่งที่มา HAL ของกล้องจะถูกรวบรวมโดย OEM และจัดส่งบนอุปกรณ์ในรูปแบบไบนารี เมื่อนักพัฒนาพูดคุยเกี่ยวกับ BLOB พวกเขาอ้างถึงไบนารีเหล่านั้นที่จัดส่งบนอุปกรณ์สดที่พวกเขาสามารถแยกออกมาได้ ตอนนี้หัวข้อ "BLOB ของกล้อง" มี OnePlus ที่รบกวนมานาน เป็นเวลาหลายเดือนแล้ว แต่ความจริงก็คือนักพัฒนาสามารถเข้าถึง BLOB ของกล้องได้เสมอ ที่ ซอร์สโค้ดของกล้อง HAL คือตั๋วทอง สำหรับนักพัฒนาที่นี่ แต่นั่นจะเป็นอย่างนั้น ไม่เคยได้รับการปลดปล่อย เนื่องจากมีความเสี่ยงทางกฎหมาย บริษัทอย่าง OnePlus จึงต้องเข้ามา
ดังนั้น นักพัฒนาที่ต้องการนำ AOSP มาสู่อุปกรณ์จึงเหลือเพียง BLOB ของกล้อง HAL เท่านั้น ซึ่งพวกเขาไม่สามารถเข้าถึงซอร์สโค้ดได้ นักพัฒนาจะจับคู่โค้ด AOSP ROM ของตนกับกล้อง HAL BLOB ได้ยากและคาดหวังว่าจะทำงานได้ ดังนั้นเพื่อที่จะเชื่อมช่องว่างระหว่างทั้งสอง นักพัฒนาจึงสร้างสิ่งที่เรียกว่า "ชิม.”
การ "shim" คือการ "ลิ่ม (บางอย่าง) หรือเติมช่องว่าง" นี่คือสิ่งที่นักพัฒนาทำอย่างมีประสิทธิภาพเมื่อใด การเขียนชิม - พวกเขาเพิ่มโค้ดเพื่อให้ BLOB สามารถเชื่อมต่อกับซอร์สโค้ด AOSP ที่พวกเขากำลังทำงานอยู่ กับ. แผ่นชิมใช้เพื่อทำให้ BLOB ประเภทต่างๆ ทำงานร่วมกับ AOSP ได้ แต่โดยปกติแล้ว BLOB ของกล้องจะต้องการแผ่นชิมมากที่สุด ดังที่เราได้กล่าวไปแล้ว จำเป็นต้องมีการชิมมิงไม่เพียงแต่สำหรับการย้าย Android เวอร์ชันใหม่ไปยังอุปกรณ์เท่านั้น (เช่น ROM Android Oreo ที่ไม่เป็นทางการทั้งหมด) แต่ยังจำเป็นเมื่อย้าย AOSP ของ Android เวอร์ชันเดียวกันไปยังสิ่งนั้น อุปกรณ์.
การอ่านที่แนะนำ: จากร้านค้าสู่ชั้นวาง: การให้ข้อมูลเชิงลึกว่าทำไมอุปกรณ์ MSM8974 จึงถูกแยกออกจาก Nougat
ตัวอย่างเช่น OnePlus 2 ได้รับมัน การอัปเดตระบบปฏิบัติการหลักอย่างเป็นทางการครั้งล่าสุด ในรูปแบบของ Android 6.0 Marshmallow อย่างไรก็ตามอุปกรณ์นั้นมีอยู่จริง ROM ที่ใช้ AOSP แบบกำหนดเองที่ทำงานได้อย่างสมบูรณ์ อิงจาก Android Nougat และต้องขอบคุณการทำงานหนักของนักพัฒนาและทีมงานของพวกเขา เราจะแจกแจงตัวอย่างบางส่วนของชิม แต่ก่อนอื่น เราต้องพูดถึงวิธีการทำงานของชิมก่อน
การชิมมิงทำงานอย่างไร?
เนื่องจากนักพัฒนาไม่สามารถเข้าถึงแหล่ง HAL หรือ OEM ROM ของกล้องได้ (และมีเพียงไบนารีที่คอมไพล์แล้วเท่านั้น) พวกเขาจึงไม่รู้ว่ากล้อง HAL คาดหวังฟังก์ชั่นอะไร ด้วยเหตุนี้ ชื่อของฟังก์ชันที่กล้อง HAL กำลังมองหาจึงมักจะไม่ตรงกันกับชื่อจริงของฟังก์ชันในโค้ด AOSP ที่นักพัฒนาซอฟต์แวร์กำลังทำงานอยู่
เพื่อแก้ไขปัญหานี้ นักพัฒนาเพียงแค่สร้างฟังก์ชันใหม่ที่ใช้ชื่อเดียวกันกับ ฟังก์ชั่นที่กล้อง HAL BLOB คาดหวัง แต่ฟังก์ชั่นใหม่นี้เพียงดำเนินการตามที่นักพัฒนาต้องการ มันถึง ฟังก์ชันใหม่ที่ทำหน้าที่เป็นตัวกลางระหว่าง BLOB และ AOSP คือฟังก์ชันชิม สถานการณ์เฉพาะนี้ที่ BLOB ล้มเหลวในการค้นหาฟังก์ชันที่ต้องการเป็นหนึ่งในสถานการณ์ทั่วไปที่จำเป็นต้องใช้แผ่นรอง
บางทีสิ่งต่างๆ อาจดูสมเหตุสมผลขึ้นอีกเล็กน้อยด้วยตัวอย่างสมมุติที่เกี่ยวข้องกับ OnePlus 3T เราจะสร้างตัวอย่างโดยใช้ OxygenOS และกล้อง OnePlus หากเราใช้ BLOB ของกล้องที่นำมาจาก OxygenOS Nougat สำหรับ OnePlus 3T เพื่อสร้าง ROM Nougat ที่ใช้ AOSP เราอาจประสบปัญหา เนื่องจากกล้อง BLOB (ซึ่งเดิมรวบรวมโดย OEM) จะสามารถอ้างอิงฟังก์ชันทั้งหมดที่ต้องการภายใน OxygenOS ได้ แต่เนื่องจาก AOSP ROM ที่คอมไพล์แล้วอาจไม่มีฟังก์ชันเหล่านั้นหรืออาจคอมไพล์ภายใต้ชื่ออื่น (ซึ่งนำไปสู่ความไม่ตรงกันระหว่างสัญลักษณ์ฟังก์ชัน) จะมี ข้อผิดพลาด. ซึ่งสามารถแก้ไขได้โดยการสร้างฟังก์ชันใหม่ภายใน AOSP ROM ด้วยชื่อที่ BLOB คาดหวัง ซึ่งก็คือ shim ของเรา
สัญลักษณ์ในบริบทการเขียนโปรแกรมใช้เพื่ออ้างถึงฟังก์ชันเฉพาะในโค้ด สัญลักษณ์เป็นสิ่งจำเป็นเนื่องจากตำแหน่งของฟังก์ชันสามารถเปลี่ยนแปลงได้เมื่อมีการแก้ไขโค้ด และเพื่อหลีกเลี่ยงฮาร์ดโค้ด การอ้างอิงถึงฟังก์ชัน คอมไพลเลอร์จะสร้างตารางสัญลักษณ์ที่ฟังก์ชันอื่นสามารถใช้เพื่ออ้างอิงทางด้านขวาเสมอ การทำงาน. เมื่อคุณเปลี่ยนชื่อฟังก์ชันก่อนที่จะคอมไพล์ สัญลักษณ์ของฟังก์ชันก็จะเปลี่ยนไปด้วย ดังนั้นโดยพื้นฐานแล้วการเปลี่ยนแปลงใดๆ ก็ตาม ที่ OEM ทำกับแหล่ง HAL ของกล้องก่อนการคอมไพล์จะต้องให้นักพัฒนาสร้างใหม่ ชิม
คำอธิบายที่เรานำเสนอจนถึงตอนนี้ทำให้ดูเหมือนว่าการสร้างชิมเป็นเรื่องง่าย การเปลี่ยนชื่อฟังก์ชันบางส่วนที่นี่และฟังดูไม่ยากเกินไปใช่ไหม ถ้ามันง่ายขนาดนั้น ความเป็นจริงของ shims เกี่ยวข้องมากกว่าแค่การเปลี่ยนชื่อฟังก์ชัน เราได้พูดคุยกับ XDA Recognized Developer Sultanxda ซึ่งสามารถยกตัวอย่างหนึ่งในชิมเมอร์ที่ยากกว่าที่เขาเคยทำมาให้เราได้
Shimming - ไม่ง่ายอย่างที่คิด
สำหรับผู้ที่ไม่คุ้นเคยกับ OnePlus 3T กล้องหน้าค่อนข้างจะพังในตอนแรก ROM แบบกำหนดเองที่ใช้ AOSP ในการเริ่มต้น การพยายามถ่ายภาพที่มีขนาดเกิน 8MP จะส่งผลให้ได้ ล้มเหลว ในความพยายามที่จะแก้ไขปัญหานี้ Sultanxda ได้ทำหลายอย่าง แผ่นชิม เพื่อให้กล้องหน้าของ OnePlus 3T ทำงานได้อย่างถูกต้อง
Shim #1 - การเปลี่ยนชื่อแพ็คเกจกล้อง
เพื่อที่จะหยุดกล้องหน้าไม่ให้พังทุกครั้งที่ผู้ใช้ถ่ายภาพที่มีความละเอียดเกิน 8MP Sultanxda จึงบังคับให้กล้อง HAL ระบุกล้องทั้งหมดว่าเป็นกล้อง OnePlus ทำได้เพราะ OnePlus ตัดสินใจอุทิศฟังก์ชั่นตัวช่วยให้กับแอพพลิเคชั่นบางตัว (isOnePlusCamera, isFacebookCameraฯลฯ) ด้วยเหตุผลบางประการ Sultanxda แก้ไขปัญหานี้ด้วยการส่องกล้อง HAL เพื่อให้ชี้ไปที่ฟังก์ชันใหม่ที่คืนค่า "จริง" เสมอราวกับว่าผู้ใช้กำลังใช้กล้อง OnePlus แม้ว่าไม่ได้ใช้ก็ตาม
Shim #2 - ปิดการใช้งาน QuadraCfa
สำหรับชิมครั้งต่อไป เขาต้องปิดการใช้งาน QuadraCfa ซึ่งน่าจะเป็นเทคโนโลยี Qualcomm ที่เป็นกรรมสิทธิ์ที่เกี่ยวข้องกับกล้อง เราพูดน่าจะเป็นเพราะทั้งตัวฉันเองและ Sultanxda ไม่แน่ใจแน่ชัดว่า QuadraCfa คืออะไร แต่ Sultanxda รู้ว่ากล้องหน้าจะพังทุกครั้งที่เปิดใช้งาน
เขาสังเกตเห็นว่า QuadraCfa สามารถเปิดใช้งานตัวเองได้ แต่เขาไม่แน่ใจว่าทำไมหรืออย่างไร การแก้ปัญหานี้จำเป็นต้องมีการปรับเปลี่ยนที่ค่อนข้างแหวกแนวในส่วนของเขา ในแผ่นรองชิมทั่วไป เมื่อคอมไพล์แล้ว ฟังก์ชันแผ่นรองเม็ดมีดจะให้สัญลักษณ์ที่หายไปซึ่ง BLOB กำลังมองหา ในกรณีนี้ BLOB มีสัญลักษณ์ที่ต้องการอยู่แล้ว—สัญลักษณ์ที่สันนิษฐานว่าแสดงถึงฟังก์ชันที่กำลังเริ่มต้น QuadraCfa
ดังนั้น เขาจึงจำเป็นต้องแทนที่สัญลักษณ์ที่ใช้โดยกล้อง HAL และโดยพื้นฐานแล้ว ทำให้มัน "หายไป" ด้วย ของเขา แผ่นชิมจะให้สัญลักษณ์ "ที่หายไป" เหล่านั้น วิธีเดียวที่จะทำได้คือผ่าน hex แก้ไขกล้อง HAL เอง. โดยพื้นฐานแล้วการแก้ไขเลขฐานสิบหกคือการมองผ่านกลุ่มคำที่พูดพล่อยๆ ที่ไม่มีการรวบรวมกันในรูปแบบของข้อมูลไบนารี่ เพื่อค้นหาเข็มในกองหญ้า ไม่ว่าจะเป็นฟังก์ชันหรือสตริงที่คุณต้องการแก้ไข
การแก้ไขฟังก์ชันแบบ Hex นั้นยากกว่าการแก้ไขสตริงแบบ hex อย่างมาก แต่โชคดีที่ Sultanxda สามารถหลีกเลี่ยงการแก้ไขฟังก์ชันที่อยู่เบื้องหลัง QuadraCfa ในรูปแบบ hex แทนได้ ฐานสิบหกแก้ไขชื่อสัญลักษณ์เพื่อทำให้สัญลักษณ์เหล่านั้นเป็นโมฆะ.
Shim #3 - แก้ไขข้อขัดข้องด้วยแสงจ้า
ถัดไป Sultanxda ระบุว่าการถ่ายภาพจากกล้องหน้าเมื่ออยู่ภายใต้สภาพแสงจ้าอาจทำให้กล้องพังได้ เพื่อที่จะจำลองข้อผิดพลาดนี้บนอุปกรณ์ของเขาเอง Sultanxda จริงๆ เปิดฟังก์ชั่นไฟฉายของ OnePlus One และส่องแสงด้านหน้ากล้องหน้าของ OnePlus 3T เพื่อทำให้มันพังและสร้างบันทึกที่ใช้งานได้! เมื่อเขาค้นพบว่าฟังก์ชันใดที่ทำให้เกิดความผิดพลาด เขาก็ได้สร้างแผ่นชิมขึ้นมาเพื่อบังคับให้อุปกรณ์ใช้โหมดแสงน้อยตลอดเวลาสำหรับกล้องหน้า
Shim #4 - รูปภาพจากกล้องหน้าความละเอียดต่ำ
หลังจากแก้ไขการขัดข้องของแสงจ้าด้วยแผ่นชิมก่อนหน้า Sultanxda ได้ค้นพบข้อบกพร่องอีกประการหนึ่งซึ่งจริงๆ แล้วเกิดขึ้นเป็นผลโดยตรงจากแผ่นชิมนั้น นั่นก็คือ รูปภาพจากกล้องหน้าความละเอียดต่ำ แทนที่จะถ่ายรูปตามที่ผู้ใช้ร้องขอความละเอียด (เช่น 16MP) ผลลัพธ์ที่ได้จะถ่ายที่ 4MP
การแก้ปัญหานี้จำเป็นต้องให้เขาชิมฟังก์ชันต่างๆ handleSuperResolution และ isSuperResolution ให้คืนค่าเป็นจริงเสมอ แต่เฉพาะเมื่อมีการเปิดใช้งานกล้องหน้าเท่านั้น (เพราะไม่เช่นนั้นกล้องจะพังเมื่อถ่ายภาพจากเซ็นเซอร์ด้านหลัง)
บทเรียนที่ได้รับ - การส่องแสงอาจเป็นเรื่องยาก
Sultanxda ยอมรับว่าแผ่นรองที่เขาต้องสร้างเพื่อให้กล้องหน้า OnePlus 3T ทำงานไม่ได้แสดงถึงตัวอย่างแผ่นรองทั่วไปของคุณ เขาค่อนข้างภูมิใจกับชิมของเขาเนื่องจากความซับซ้อนและความจำเป็นที่หาได้ยากในการแก้ไข BLOB นั่นเอง แต่ตัวอย่างนี้แสดงให้เห็นว่าการทำให้ฮาร์ดแวร์กล้องทำงานบนอุปกรณ์บางชนิดได้ยากเพียงใด
ขอให้การผจญภัยที่ชิมกล้องของคุณเจ็บปวดน้อยกว่าของฉัน -สุลต่านดา
บันทึก บันทึก และบันทึกอื่นๆ หากไม่มีวิธีที่สอดคล้องกันในการสร้างข้อขัดข้องและไม่มีบันทึก นักพัฒนาแทบไม่มีความหวังที่จะค้นหาสาเหตุของปัญหา แม้ว่าพวกเขาจะพบสาเหตุของปัญหา แต่ก็ไม่ใช่วิธีแก้ปัญหาที่ตรงไปตรงมาเสมอไป กระบวนการทั้งหมดในการค้นหาและกำจัดจุดบกพร่องเหล่านี้อาจใช้เวลาหลายวันหรือหลายสัปดาห์ และเป็นเหตุผลว่าทำไมการแก้ไขกล้องบน AOSP ROM จึงเป็นหนึ่งในงานที่ยากกว่า
หากอุปกรณ์ของคุณมี AOSP ROM ที่เชื่อมต่อเข้ากับฮาร์ดแวร์ที่ทำงานได้อย่างสมบูรณ์ หวังว่าคุณคงสามารถเริ่มต้นได้ ชื่นชมการต่อสู้ที่นักพัฒนาเหล่านั้นอาจต้องเผชิญเพื่อนำสิ่งเหล่านี้มาสู่คุณ คุณสมบัติ. ชื่นชมพวกเขาสำหรับงานของพวกเขาเพราะมันไม่ใช่เรื่องง่าย เป็นงานที่ผู้ใช้ส่วนใหญ่ไม่สังเกตเห็นด้วยซ้ำ เนื่องจากนักพัฒนาที่มีความสามารถในฟอรัมของเรากำลังดูแลส่วนต่างๆ ที่มองไม่เห็นของ Android
เราขอขอบคุณเป็นพิเศษต่อ Sultanxda สำหรับความช่วยเหลือมากมายที่เขาแนะนำในการสร้างบทความนี้