By: mk 
on 20 December 2017 - 09:47
Tags:
ข่าวสำคัญที่นักพัฒนาสาย Android ควรทราบ กูเกิลประกาศนโยบายใหม่สำหรับ Play Store หลายข้อ กำหนดเวอร์ชันของ API (ในที่นี้คือ targetSdkVersion) ในปี 2018, กำหนดว่าต้องเป็นแอพแบบ 64 บิตเท่านั้นในปี 2019, และบังคับให้ต้องมี metadata ด้านความปลอดภัย
Target API level ขั้นต่ำ
- สิงหาคม 2018 แอพใหม่ จะต้องกำหนด API level เป็นเวอร์ชัน 26 (Android 8.0) ขึ้นไป
- พฤศจิกายน 2018 แอพเก่าที่อยู่บน Play Store แล้ว จะต้องกำหนด API level เป็นเวอร์ชัน 26 ขึ้นไป
- ปี 2019 เป็นต้นไป กูเกิลจะขยับเลข targetSdkVersion ตามขึ้นไปเรื่อยๆ
ข้อกำหนดนี้ไม่ได้แปลว่า กูเกิลจะไม่รองรับการใช้แอพกับ Android รุ่นเก่ากว่า 8.0 เพราะกูเกิลจะไม่ยุ่งอะไรกับค่า minSdkVersion และแนะนำให้นักพัฒนารองรับ Android เวอร์ชันเก่าตามสมควร ส่งผลให้แอพสามารถรันได้บน Android เวอร์ชันเก่า แต่อาจทำงานได้ไม่เต็มประสิทธิภาพหรือเข้าไม่ถึงฟีเจอร์บางอย่างของ API เวอร์ชันใหม่ๆ
กูเกิลยังระบุว่าในอนาคต Android เวอร์ชันใหม่ๆ (เช่น Android P หรือ Q) จะจำกัดไม่ให้รันแอพที่ตั้ง targetSdkVersion เก่าจนเกินไป จนส่งผลต่อประสิทธิภาพหรือความปลอดภัยด้วย สิ่งที่กูเกิลต้องการคือพยายามให้แอพใช้ API เวอร์ชันใหม่ๆ ให้มากขึ้น ลด fragmentation ในระบบ แต่ก็จะมีเวลาให้นักพัฒนาปรับตัว และประกาศแผนล่วงหน้าให้นานพอ
64 บิต
นอกจากเรื่อง API กูเกิลยังประกาศแผนการเปลี่ยนผ่านโลก Android เข้าสู่ยุค 64 บิตเต็มตัว (แอปเปิลทำเสร็จไปแล้วเมื่อกลางปีนี้) โดยปัจจุบันอุปกรณ์ Android ประมาณ 40% ของตลาดรองรับ 64 บิตเรียบร้อยแล้ว และอนาคตระยะยาว Android จะรองรับเฉพาะ 64 บิตเพียงอย่างเดียว
แผนการเตรียมพร้อมของกูเกิลคือ ในเดือนสิงหาคม 2019 แอพใหม่และแอพเก่าที่มีอัพเดตบน Play Store จะต้องมีเวอร์ชัน 64 บิตด้วย (จะมี 32 บิตหรือไม่นั้นไม่บังคับ)
- ในกรณีที่แอพมีโค้ดแบบเนทีฟที่ต้องคอมไพล์เอง นักพัฒนาจะเลือกการทำ APK ไฟล์เดียวรันได้ทั้งสองสถาปัตยกรรม หรือจะแยก APK ก็ได้
- ถ้าแอพมาเป็นซอร์สโค้ดอย่างเดียว ไม่มีไบนารีติดมาด้วย (งานคอมไพล์เป็นหน้าที่ของกูเกิล) ก็ไม่ต้องทำอะไรเพิ่มเติม
กูเกิลบอกว่าประกาศแผนการล่วงหน้าให้นานเกือบ 2 ปี เพื่อให้นักพัฒนามีเวลาเตรียมตัว
Security Metadata
ประกาศข้อสุดท้ายคือ Play Store จะเพิ่มข้อมูล metadata เกี่ยวกับความปลอดภัยลงในไฟล์ APK ทุกไฟล์ เพื่อยืนยันว่าเป็นแอพที่ดาวน์โหลดจาก Play Store จริงๆ (ไม่ได้ sideload มาจากแหล่งอื่น)
ตรงนี้นักพัฒนาไม่ต้องทำอะไรเพิ่ม เพราะกูเกิลจะเพิ่ม metadata ให้อัตโนมัติ (และกูเกิลจะขยายขนาดสูงสุดของไฟล์ APK ให้อีกเล็กน้อยด้วย) การเปลี่ยนแปลงนี้จะมีผลช่วงต้นปี 2018
ที่มา - Android Developers Blog
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- Kubernetes คืออะไร [Part 1] เกิดขึ้นมาอย่างไร? ทำไมต้องใช้มัน? | Cloudnone EP.14
- CI/CD ยังไงดี ตั้งเซิร์ฟเวอร์เอง vs เช่าคลาวด์ | Cloudnone EP.13
- รู้จักโน้ตบุ๊กบนคลาวด์ เช่าใช้งาน Jupyter Notebook ที่ไหนดี | Cloudnone Ep.12
- สรุปข่าวใหญ่ปี 23 และคาดการณ์เทรนด์ปี 24 ในวงการ Cloud | Cloudnone EP.11
- สรุปของใหม่และสาระสำคัญจาก AWS re:Invent 2023 | Cloudnone Special EP
Comments
เล็งเห็นเลยว่าพอถึงวันเส้นตายนักพัฒนาส่วนใหญ่ก็จะแค่ปรับเลข target แล้วก็ compile ส่งขึ้นไปใหม่อย่างเดียวเพื่อให้ผ่านเงื่อนไข แล้วเนื่องจาก Play Store ไม่มีด่านตรวจเหมือน App Store ก็จะไปเจอปัญหาเอาตอน user ใช้งานเช่นไม่ได้ check permission ตอน runtime ก่อนเรียกใช้งานจริง ฯลฯ
ถ้านักพัฒนาทำมักง่ายแบบนั้นแล้วเจอ app crash ก็ต้องรับผลกรรม 1-star review ไปนะครับ :)
ต่อให้แก้ภายหลังผู้ใช้ก็ไม่ค่อยมาแก้คะแนนรีวิวหรอก ;)
ถ้าเป็น app ที่เป็น product ของตัวเองทำเองอาจจะไม่ค่อยมีปัญหาเท่าไหร่ แต่ว่าถ้าเป็นบริษัทที่จ้างคนอื่นทำ app ให้อาจจะเจอปัญหาแบบนี้เพราะว่าพอจะเปลี่ยนจะเพิ่มอะไรใหม่ก็จ้างทำเป็นครั้ง ๆ ไปแล้วก็ไม่มีงบ maintenance รายเดือนรายปีให้ พอเจอกรณีอย่างนี้เค้าก็จะไม่ยอมจ่ายคนทำ app หรือจ่ายน้อยเพราะเค้าก็จะคิดว่าไม่มี feature อะไรใหม่ซักหน่อย ทำยังไงก็ได้ให้ app ไม่โดนถอดออกจาก store ก็พอ คนทำก็จะทำแบบแค่พอผ่านเพราะว่าคนจ้างก็ให้งบมาแค่นี้ ก็เลยคุณภาพตามราคา
เรื่องของเรื่องคือ แอพใหม่และแอพเก่าที่มีอัพเดตบน Play Store จะต้องมีเวอร์ชัน 64 บิตด้วย "ส่วนจะมี 32 บิตหรือไม่นั้นไม่บังคับ"
... คิดว่า google เริ่มต้องการเพิ่ม performance ให้ app ต่างๆ แผนระยะยาวเลยจะบังคับให้ compile เป็น 64 bit ด้วย ก็เท่านั้น
samsung ใหญ่แค่ใหน ?
https://youtu.be/6Afpey7Eldo
โค้ดเดิมนั่นแหล่ะครับ แต่บังคับว่าต้องคอมไพล์และนำส่งสำหรับรุ่น 64 บิตด้วย ส่วนถ้าจะคอมไพล์และนำส่งรุ่น 32 บิตก็ไม่ว่ากัน