Android Q AMA შეჯამება: რა თქვა Google-მა Android 10-ის შესახებ Reddit-ზე

გასულ წელს Google-ის Android-ის გუნდმა უმასპინძლა Ask Me Anything (AMA) Reddit-ის /r/AndroidDev ქვერედიტზე საველე კითხვებზე. Android P დეველოპერის გადახედვა. წელს Android Q ბეტაზე მომუშავე საინჟინრო გუნდმა Reddit-ზე უპასუხა კითხვებს. AMA დაიწყო 1 აგვისტოს 12:00 საათზე PST და დასრულდა დაახლოებით საათნახევრის შემდეგ. AMA-ში ჩართული იყო Google-ის 33 ინჟინერი, რომლებმაც უპასუხეს უამრავ კითხვას იმ მოკლე დროში, რაც AMA გაგრძელდა. აქ არის ჩვენი შეჯამება ყველა ახალი ინფორმაციის შესახებ, რაც ჩვენ ვისწავლეთ.

Android Q AMA: ყველაფერი რაც ვისწავლეთ Google-ისგან

მონაწილეები Android Q ბეტა გუნდიდან

• ადამ კოენი: TLM Android Launcher / სისტემის ინტერფეისზე
• ადამ პაუელი: TLM UI ინსტრუმენტარიუმის/ჩარჩოების შესახებ; ხედები, სიცოცხლის ციკლი, ფრაგმენტები, დამხმარე ლიბები
• ალან ვივერეტი: TLM, Jetpack / AndroidX
• ალენ ჰუანგი: PM UI-სთვის, გამშვებისთვის, შეტყობინებებისთვის, საძიებო ინტეგრაციებისთვის და სხვა!
• ენდრიუ საპპირშტეინი: TLM Android-ის პარამეტრებზე
• ბრაჰიმ ელბუჩიხი: PM დირექტორი Android Machine Learning-ისთვის და კამერისთვის (NN API, ML Kit, CameraX, Camera Platform)
• ჩად ბრუბეიკერი: პროგრამული უზრუნველყოფის ინჟინერი, Android პლატფორმის უსაფრთხოება
• შარმენ დ’სილვა: PM კონფიდენციალურობისთვის
• ჩეტ ჰასე: Android-ის მთავარი ადვოკატი, დეველოპერებთან ურთიერთობა
• დიანა ვონგი: PM, აპის თავსებადობა, არა SDK API გამოყენება, ART, NDK
• დაიან ჰეკბორნი: Android Framework გუნდის მენეჯერი (რესურსები, ფანჯრის მენეჯერი, აქტივობის მენეჯერი, მრავალ მომხმარებლის, ბეჭდვა, ხელმისაწვდომობა და ა.შ.)
• ე.კ. ჩუნგი: UX-ის დირექტორი
• იან ლეიკი: პროგრამული უზრუნველყოფის ინჟინერი, Jetpack (ფრაგმენტები, ნავიგაცია, არქიტექტურის კომპონენტები)
• ილია მალჩევი: მთავარი პროგრამული უზრუნველყოფის ინჟინერი, Project Mainline
• იაკობ ლერბაუმი: დეველოპერებთან ურთიერთობის დირექტორი Android-ისთვის
• ჯეიკ უორტონი: პროგრამული უზრუნველყოფის ინჟინერი, Jetpack
• ჯამალ ისონი: PM, Android Studio
• ჯეფ ბეილი: TLM, Android ღია კოდის პროექტი (AOSP)
• ჯეფ შარკი: პროგრამული უზრუნველყოფის ინჟინერი, Android Framework
• ჯეფრი ვან გოგი: Android Studio, შემდგენელები
• ჯენ ჩაი: PM, მდებარეობა და კონტექსტი, ავტორიზაცია, ავტომატური შევსება, არა SDK API გამოყენება, ART
• კარენ ნგ: Group PM Android Developer Tools-ისთვის, Android Studio-სთვის, Android Tookit-ისთვის და Jetpack-ისთვის
• პოლ ბანკჰედი: პროდუქტის მენეჯმენტის დირექტორი, Google Play
• როჰან შაჰი: პროდუქტის მენეჯერი, Android სისტემის UI
• რომან გაი: Android Toolkit/Jetpack გუნდის მენეჯერი
• საგარ კამდარი: პროდუქტის მენეჯმენტის დირექტორი, Android
• შატ K: ინჟინერიის დირექტორი, Android Connectivity
• სელიმ ცინეკი: პროგრამული უზრუნველყოფის ინჟინერი, Android სისტემის UI
• სტეფანი საად კატბერტსონი: პროდუქტის მენეჯმენტის უფროსი დირექტორი, Android
• სუმირ კატარია: პროგრამული უზრუნველყოფის ინჟინერი, Jetpack (WorkManager)
• ტრევის მაკკოი: PM, Android პლატფორმა
• Trystan Upstill: გამორჩეული ინჟინერი, ლიდერი Android სისტემის UI და Intelligence-ისთვის
• ვინიტ მოდი: PM, Android კამერა

წაიკითხე მეტი

OEM-ებს აღარ შეუძლიათ აპების მოკვლა, როდესაც მომხმარებელი აშორებს მათ ბოლო დროს

თუ ოდესმე გამოგიყენებიათ ჩინური ბრენდის სმარტფონი, მაშინ ალბათ შეგხვდათ შემაშფოთებელი "ბატარეის ოპტიმიზაციის" ფუნქციები, რომლებიც მოკალი ყველა თქვენი საყვარელი აპლიკაცია ფონზე. ეს ქცევა არა მხოლოდ შემაშფოთებელია მომხმარებლებისთვის, რომლებიც ელიან, რომ გარკვეული აპლიკაციები გააგრძელებენ მუშაობას ფონზე რაიმე მიზეზით, მაგრამ ეს ასევე შემაშფოთებელია დეველოპერებისთვის, რომლებსაც აქვთ ცუდი მიმოხილვა მომხმარებლებისგან, რომლებსაც არ ესმით, რომ ეს არ არის აპის ბრალია. სანამ Google არის ისევ სრულად არ განიხილავენ ამ საკითხს (მათ ხელი აარიდეს ამ საკითხს და განაცხადეს, რომ ეს არის სავარაუდოდ უკვე არღვევს Android თავსებადობის განსაზღვრის დოკუმენტის მოთხოვნებს), კომპანია არის მოქმედების განხორციელება ზოგიერთი OEM-ის მიერ გამოყენებული ქცევის ერთი "ბატარეის დაზოგვის" ცვლილების წინააღმდეგ.

"სიტუაციის დასახმარებლად, ჩვენ დავამატეთ CTS ტესტი Android Q-ში, რათა დავრწმუნდეთ, რომ აპი არ დაიღუპება უახლესებიდან გადასვლისას."

Android R-მა შეიძლება მოიტანოს მეტი ცვლილება ეკრანის სურათებში, ვიდრე ველოდით

Google გეგმავს დამატებას ეკრანის გადახვევა Android R-ში, მაგრამ ამავე დროს, ანდროიდის გუნდი არის „დაახლოებით დავაკვირდებით, თუ როგორ შეუძლიათ გააუმჯობესონ მთელი ეკრანის [X] გამოცდილება R-ისთვის“. ამრიგად, ჩვენ შეგვიძლია იხილეთ სკრინშოტის (და ეკრანის გადაცემის) ქცევის სხვა გაუმჯობესებები Android-ის შემდეგ მთავარ ვერსიაში.

Android Q-ის ახალი დესკტოპის რეჟიმის გარკვევა

The პირველი საჯარო ბეტა გამოშვება Android Q-მა AOSP-სა და Pixel Launcher-ში დამალული დესკტოპის რეჟიმის ინტერფეისი მოიტანა. მიუხედავად იმისა, რომ Google მოკლედ შეეხო თვისებას Google I/O სესიის დროს, ჩვენ არასოდეს გვსმენია პირდაპირ Google-ისგან, თუ როგორ ჯდება ახალი ფუნქცია Android-ის ეკოსისტემაში. Google ახლა განმარტავს:

Q AOSP-ში, დესკტოპ რეჟიმში არის დეველოპერის ვარიანტი, რომელიც გამიზნულია აპლიკაციის შემქმნელებისთვის. ეს საშუალებას აძლევს მათ შეამოწმონ თავიანთი აპლიკაციები მრავალ ეკრანზე და თავისუფალი ფორმის ფანჯრის რეჟიმში. ადრე არ არსებობდა მოსახერხებელი გზა აპის ქცევის შესამოწმებლად მეორად ეკრანზე და თავისუფლად შესაცვლელი ფანჯრებით საფონდო Android-ზე. ეს ფუნქცია დამოუკიდებლად არ არის წარმოებული და არ არის გათვლილი რეგულარული მომხმარებლებისთვის. მიუხედავად ამისა, ეს არის Android პლატფორმის საფუძველი OEM-ებისთვის ინოვაციებისა და შესანიშნავი პროდუქტების შესაქმნელად. ”

ამრიგად, ჩვენ შეგვიძლია ველოდოთ OEM-ებს, რომლებიც აგებულია Android Q-ის დესკტოპის მშობლიურ რეჟიმში. მაგალითად, OnePlus 7 Pro მხარს უჭერს ჩვენებას HDMI-ზე, ასე რომ შესაძლებელია OxygenOS 10 Android Q-ზე დაფუძნებული მომავალში ექნება საკუთარი დესკტოპის რეჟიმის ინტერფეისი. ჩვენ ასევე ვიმედოვნებთ, რომ Google დაეყრდნობა მახასიათებლებს მომავალი პერიოდისთვის პიქსელი 4.

დროზე დაფუძნებული მუქი რეჟიმი

Android Q საბოლოოდ მოაქვს ფართოდ მოთხოვნილი ფუნქცია: სისტემური ბნელი რეჟიმი. ამჟამად, მუქი რეჟიმი შეიძლება ხელით ჩართოთ პარამეტრებში ან სწრაფი პარამეტრების ფილებით, ან ის ავტომატურად გააქტიურდეს, როდესაც ჩართულია ბატარეის დამზოგავი. Android Q-მდე არსებობდა მუქი რეჟიმის ჩართვის ვარიანტი დღის დროზე დაყრდნობით, მაგრამ ეს ვარიანტი მოძველდა. კრის ბეინსის მიხედვით:

"არსებობს რამდენიმე მიზეზი, რის გამოც ეს მოძველებულია (არ არის ამოღებული) AppCompat v1.1.0-ში: ის მოითხოვს აპებს, რომ მოითხოვონ მდებარეობის ნებართვები უნდა იყოს ზუსტი, და თუნდაც სწორი მდებარეობის შემთხვევაში, მზის ამოსვლის/ჩასვლის დროის გამოთვლები შეიძლება იყოს ბაგი."

როდესაც ჰკითხეს ამ შეცდომების შესახებ, ბ-ნი ბეინსი ამბობს, რომ „მზის ამოსვლის/ჩასვლის გამოთვლა საკმაოდ რთულია, განსაკუთრებით მახლობლად მდებარე მდებარეობებისთვის. ჩრდილოეთი/სამხრეთი პოლუსები." მომხმარებელი აჩენს ღამის განათებას, რომელიც ხელმისაწვდომია Android 7.1 Nougat-იდან, შეიძლება ავტომატურად გადართოს ჩასვლა/მზის ამოსვლაზე დაყრდნობით. განრიგი. ბატონი ბეინსი შემდეგ აცხადებს, რომ მას შემდეგ, რაც Night Light იყენებს CalendarAstronomer-ს ICU4J, ის იყენებს "კოდის დიდ ნაწილს, რომელზედაც არ გვინდა, რომ AppCompat დამოკიდებული იყოს." თუმცა, გუნდი ამას აკეთებს სახელმწიფო რომ ეს თვისება არის „რაღაც [ისინი] შეისწავლიან“.

სავალდებულო Camera2 API/Camera HAL3 მხარდაჭერა Android Q გაშვების მოწყობილობებისთვის

Google-მა გააცნო Camera2 API, რათა უკეთ განსაზღვროს, თუ როგორ შეუძლიათ აპებს ურთიერთქმედება თქვენს სმარტფონთან დაკავშირებულ ცალკეულ კამერებთან. სანამ Google ხელს უწყობს სმარტფონების გამყიდველებმა „დეველოპერებს აჩვენონ თავიანთი ფიზიკური კამერები“, ბევრი გამყიდველი არჩევს არ გააკეთოს ეს, მიუხედავად იმისა, რომ „თავად API არ არის მათი პრევენცია დღეს." ეს ნიშნავს, რომ მესამე მხარის კამერის ბევრ აპლიკაციას არ შეუძლია გამოიყენოს მეორადი ან მესამეული კამერის მოდულები თანამედროვეზე. სმარტფონები. თუმცა, პროგრესი მიღწეულია, რადგან Android Q გაუმჯობესდა LOGICAL_MULTI_CAMERA, API, რომელიც დეველოპერებს უკეთეს წვდომას აძლევს მოწყობილობის ყველა კამერაზე და რომელიც OEM-ებს აძლევს კონტროლს ენერგიის მოხმარებაზე და კამერის მრავალი მდგომარეობის მართვაზე.

გარდა ამისა, Google ამბობს, რომ მათ დაამატეს მოთხოვნები Android Q-ით გაშვებული ყველა მოწყობილობისთვის, რათა მშობლიური მხარი დაუჭიროს Camera2 API/Camera HAL3-ს. ვინიტ მოდის თქმით:

„Android P-დან დაწყებული, ახალი მოწყობილობები, რომლებიც მიწოდებულნი არიან 1 GB ან მეტი ოპერატიული მეხსიერებით, საჭიროა HALv3/camera2-ის ბუნებრივი გამოყენებისთვის. Android Q-დან ყველა ახალ მოწყობილობას მოეთხოვება HALv3/camera2-ის ძირითადი მხარდაჭერა. სამწუხაროდ, განახლებები HALv1-დან HALv3-მდე საკმაოდ რთულია ჰაერში და შეიძლება მოჰყვეს მოულოდნელი შედეგები, ამიტომ მოგვიწია შეზღუდვა ახალი მოწყობილობებით. ”

საინტერესოა, რომ მოდის განცხადება ნორმალური ოპერატიული მეხსიერების Android P გაშვების მოწყობილობების შესახებ ეწინააღმდეგება რა გვითხრა ადრე Google-მა და რა გამოქვეყნდა Image Test Suite გვერდზე ონლაინ.

აპლიკაციის დინამიური თემა Jetpack Compose-ით

Sony-ს OMS თემების ჩარჩო დაემატა AOSP-ს რამდენიმე გამოშვებაში, მაგრამ ეს მხოლოდ განკუთვნილია OEM-ებისთვის ავაშენოთ. ეს უკვე ვიცით Google წინააღმდეგია მომხმარებლების მიერ გაშვების რესურსის გადაფარვის გამოყენება თემის აპებზე, მაგრამ დეველოპერებისთვის ეს კომპანიაა იმედით ეს არის Jetpack Compose UI ჩარჩო წამოაყენებს "დინამიური თემების საინტერესო მიდგომებს".

Vulkan-backend for Skia-სთვის UI-ის რენდერისთვის

Გასულ წელს, ჩვენ დავინახეთ დისკუსია Google-ის ინჟინრებს შორის, რომლებიც საუბრობენ თავიანთ გეგმებზე, რომ Android Framework გამოიყენონ Vulkan გრაფიკული API ინტერფეისის რენდერისთვის. მიუხედავად იმისა, რომ ახლა უკვე შესაძლებელია Vulkan-ის ტექნიკით დაჩქარებული backend-ის ჩართვა თქვენი ტელეფონის გარეშე კრახით, ჩვენ არ გვსმენია რაიმე კონკრეტული გეგმები Google-ისგან იმის შესახებ, თუ როდის აპირებენ მათ გამოშვებას ცვლილებები. ეს AMA არ პასუხობს ამ კითხვას, მაგრამ მაინც გვაქვს დადასტურება, რომ ის ჯერ კიდევ სამუშაოებშია. რომენ გაიის თქმით:

„გუნდი მუშაობდა Vulkan backend-ზე Skia-სთვის, 2D რენდერით, რომელსაც იყენებს Android, მაგრამ ის ამჟამად არ არის ჩართული ნაგულისხმევად. UI და Canvas კვლავ გადის OpenGL ES-ში."

Android Q-ის ჟესტების ზოლი უფრო დინამიური გახდება

ზოგიერთი XDA-ზე მაინც ასე ფიქრობს Android-ის ახალი ჟესტები არეულობაა, მაგრამ მე პირადად მიმაჩნია, რომ ისინი კარგად არიან. თუ Android Q-ში ახალ ჟესტებს ცოტა ხნით თამაშობთ, შეამჩნევთ, რომ ჟესტების ზოლი თითით არ მოძრაობს. ის ასევე ჩერდება ეკრანებზე, სადაც არ არის საჭირო, როგორიცაა საწყისი ეკრანი ან ბოლო აპების მიმოხილვა. ალენ ჰუანგი ამბობს რომ ისინი „სრულიად თანხმდებიან, რომ არსებობს შესაძლებლობები“, რათა „ნავიგაციის ხაზი ნაკლებად სტატიკური გახდეს“. ის დამატებით ამბობს რომ „ეს არის ის, რაზეც ჩვენ ვმუშაობთ - მაგრამ ასევე ვაწონასწორებთ ისე, რომ ყურადღების გაფანტვა არ იყოს გამოჩენა/გაქრობა“.

Storage Access Framework-ის გაუმჯობესება

Android Q-ში განხორციელებულმა მრავალმა ცვლილებამ მნიშვნელოვნად გააუმჯობესა ის პლატფორმის უსაფრთხოება და კონფიდენციალურობა. ერთ-ერთი ასეთი ცვლილება, სახელწოდებით "Scoped Storage", ზღუდავს აპების წვდომას გარე მეხსიერებაზე არსებულ ფაილებზე ისე, რომ გონივრული იყოს; მაგალითად, მუსიკალურ აპებს არ სჭირდებათ თქვენი გალერეის ნახვა. Android Q-ში გაშვებული ფაილების მენეჯერის აპებმა უნდა გამოიყენონ API, სახელწოდებით Storage Access Framework, რათა განაგრძონ მუშაობა ჩვეულებრივად, მაგრამ ზოგიერთი დეველოპერი ამ API-ს არასრულფასოვნად ხედავს რაც ადრე იყო ხელმისაწვდომი. ჯეფ შარკი Google-იდან ამბობს გუნდმა განიხილა დეველოპერების ზოგიერთი საჩივარი:

„ჩვენ განვახორციელეთ SAF-ის მუშაობის გაუმჯობესება უახლესი Android Q Beta გამოშვებებში; შეგიძლიათ შეამოწმოთ თქვენი კრიტერიუმები უახლესი ბეტას წინააღმდეგ? ასევე დარწმუნდით, რომ იყენებთ ContentProviderClient-ს ნებისმიერი ნაყარი ოპერაციების გაშვებისას."

Project Treble-მა გააუმჯობესა Android Pie-ის მიღება Android Oreo-სთან შედარებით

ჩვენ უკვე ვნახეთ, თუ როგორ გააუმჯობესა Project Treble-მა, ანდროიდის ფრეიმერიკზე დაბალი დონის რეარქიტექტურამ, გააუმჯობესა Android OS-ის უფრო ახალი ვერსიების მიღება. Google აკრედიტებს Treble-ს უკან სმარტფონების გამყიდველების გამრავლების უკან Android P ბეტა გასულ წელს და Android Q ბეტა ამ წელს. ილიან მალჩევი, წამყვანი Project Treble და Მთავარი ხაზი ინჟინერი, ამბობს რომ Android Pie-ის მიღება იყო "3-ჯერ" ვიდრე Android Oreo-ს 2018 წლის ბოლოს.

იმავე კომენტარში, დიკ დოჰერტი ამტკიცებს, რომ უფრო სასარგებლო მეტრიკა მუშაობს Android ვერსიის განაწილების სქემისთვის. სქემა იყო ბოლოს განახლდა მაისში, მაგრამ მისი მონაცემები უფრო სასარგებლოა ჟურნალისტებისთვის, ვიდრე აპლიკაციების დეველოპერებისთვის.

ეკრანის ჩაწერა კვლავ WIP არის

Android Q-ის ადრეულმა ბეტაებმა დაამატეს ფუნქციის დროშა ძირითადი ეკრანის ჩამწერისთვის, მაგრამ თავად პლატფორმამ მნიშვნელოვნად გააუმჯობესა ეკრანის ჩაწერის სარგებლობა. საშუალებას აძლევს აპებს სხვა აპებიდან აუდიოს გადაღება. სტეფანი საად კუტბერტსონმა თქვა, რომ გუნდი განიხილავს "როგორ შეგვეძლო უკეთესის გაკეთება ეკრანზე ჩაწერის საჭიროებებზე გუშინდელ დღეს". სმარტფონების სხვა ბრენდები მოსწონს OnePlus, ASUS-ს, Huawei-სა და Samsung-ს აქვთ ძლიერი ეკრანის ჩამწერები, რომლებსაც შეუძლიათ შიდა აუდიოს ჩაწერა, ასე რომ, Google აქ ითამაშებს catch up-ს.

მუქი თემა ყველა რამ!

თუ ეს გამოტოვეთ, Google ამატებს ბნელ რეჟიმს თავისი აპების უმეტესობას. სტეფანი საად კატბერტსონი ამბობს ველით, რომ ყველა "ძირითადი აპი" მხარს დაუჭერს ბნელ თემას "ოფიციალური [Android Q] გამოშვებით." თუნდაც Google Chrome, რომელიც ამჟამად აიძულებს გვერდის გადატვირთვას, როდესაც ჩართულია სისტემური მუქი თემა, განახლდება ისე, რომ აღარ განახლდეს, როცა თემა ჩართულია შეიცვალა.

დიახ, მესამე მხარის გამშვებები იმუშავებენ ჟესტებით (საბოლოოდ)

Android-ის ჟესტები ერთგვარია გატეხილია, როდესაც იყენებთ მესამე მხარის გამშვებს. ეს იმიტომ, რომ ბოლო აპების ინტერფეისი შეიცავს საფონდო გამშვებ აპს და Google-ს ჯერ არ აქვს შეიმუშავა გზა, რომ გვქონდეს იგივე უწყვეტი გადასვლები, რასაც ვხედავთ ჟესტების გამოყენებისას საფონდო Pixel-თან გამშვები. ადამ კოენი ამტკიცებს Google-ის გეგმავს ამ საკითხების გადაჭრას „რაც შეიძლება სწრაფად გამოქვეყნების შემდეგ“. ის ამას დამატებით ამბობს შეუთავსებლობა განიხილება Q-ის შემდგომი განახლების დროს და დარეგისტრირებული იქნება ახალი მოწყობილობებისთვის, რომლებიც გაშვებულია Q."

დინამიური/ლოგიკური ტიხრები აქ არ არის მორგებული ROM-ების მოსაკლავად

მხარდაჭერის მიზნით დინამიური სისტემის განახლებები Android Q-ში გარკვეული მოწყობილობები, როგორიცაა Google Pixel 3 და Pixel 3 XL, იყენებენ ლოგიკურ ტიხრებს. ამ ტიხრების ზომა შეიძლება დინამიურად შეიცვალოს. ამ ცვლილებას აქვს დადასტურებული გამოწვევაა root წვდომის მუშაობადა ზოგიერთი დეველოპერი შეშფოთებულია, რომ საბაჟო ROM-ები მიზანმიმართულია. ილიან მალჩევი გვარწმუნებს, რომ მიზანი არ არის საბაჟო ROM-ების შეზღუდვა. როგორც ის განმარტავს:

"დინამიური ტიხრები არ არის გამიზნული, რომ შეზღუდოს ის, რისი გაკეთებაც შეგიძლიათ Custom ROM-ებით. ისინი უბრალოდ არის ფიქსირებული დანაყოფების ზომების პრობლემის გადაჭრა და მოწყობილობების გადანაწილების უსაფრთხო გზის არარსებობა OTA. დინამიური ტიხრების დაწყებამდე, თუ OEM-მა დაუშვა შეცდომა ზომაში, ე.ი. სისტემის დანაყოფი, შემდეგ ისინი შეზღუდული იქნებოდა ამ არჩევანით, რაც პრაქტიკულად შეუძლებელს გახდის მოწყობილობის განახლებას გარკვეული დროის შემდეგ წერტილი. ზოგიერთი OEM პრაქტიკაში ანაწილებს თავის მოწყობილობებს OTA-ზე, მაგრამ ეს ა) ოფიციალურად არ არის მხარდაჭერილი Android-ში და ბ) დანაყოფის ცხრილის შეცვლა საკმაოდ სარისკოდ ითვლება. დინამიური დანაყოფები მიზნად ისახავს პრობლემის შემსუბუქებას ფიზიკური დანაყოფების ცხრილსა და OS-ის ხედებს შორის არამიმართულების დონის დანერგვით. ეს თავის მხრივ საშუალებას გვაძლევს უსაფრთხოდ დავარეგულიროთ დანაყოფების ზომები OTA-ზე. რაც შეეხება საბაჟო ROM-ებს, თქვენ არ უნდა იყოთ უფრო მეტად შეზღუდული, ვიდრე დღეს ხართ იმით, რისი გაკეთებაც შეგიძლიათ. საბაჟო ROM-ების მხარდაჭერა არის და კვლავაც არის ის, რასაც თითოეული OEM გადაწყვეტს ჩართოს. ”

Project Mainline - ART მოდული და მხარდაჭერის სიგრძე

Mainline არის Google-ის ახალი ინიციატივა, რომელიც მიზნად ისახავს გარკვეული ბიბლიოთეკებისა და პაკეტების სტანდარტიზაციას, რათა მათი განახლება შესაძლებელი იყოს პლატფორმის განახლებისგან დამოუკიდებლად. ზოგიერთს აინტერესებს, რატომ არ არის Android Runtime (ART) ჯერ კიდევ მთავარი მოდული, მაგრამ Google I/O-ზე მითხრეს, რომ ART-ის მოდულარიზაციასთან დაკავშირებული სირთულემ ხელი შეუშალა მათ მის ერთ-ერთ საწყის APEX პაკეტად ჩართვისგან. როგორც განმარტა ილიან მალჩევისა და დიანა ვონგის მიერ:

"Runtime-ის განახლებების შეტანა (განსაკუთრებით შესრულების და GC შესწორებები და ძირითადი ბიბლიოთეკები) ნამდვილად არის ის, რასაც ჩვენ ვიკვლევთ მთავარი ხაზის კონტექსტში. ჩვენ ვხედავთ უამრავ სარგებელს, რომ შევძლოთ ამ განახლებების თანმიმდევრულობა ყველა მოწყობილობაში და მრავალ გამოშვებაში მთავარი ხაზით. ეს ასევე უზარმაზარი ტექნიკური გამოწვევაა, რადგან ჩვენ ვფიქრობთ იმაზე, თუ როგორ გავაკეთოთ ეს საუკეთესოდ დეველოპერებისთვის და, სავარაუდოდ, მრავალწლიანი ძალისხმევა. ეს არ არის ის, რისი გაკეთებაც Mainline-ს შეუძლია, მაგრამ რა თქმა უნდა, რაზეც ჩვენ ვფიქრობთ. ”

თუ მიჰყვებით AOSP Gerrit-ს, ნახავთ, რომ Google მაინც ყოფილა მძიმე სამუშაო Runtime APEX-ის გაკეთება. ამჟამად, როგორც ჩანს, არიან Bionic-ისა და ART/libcore-ის გაყოფა ცალკეულ APEX მოდულებად.

Project Mainline-ის უპირატესობებთან დაკავშირებით, ერთმა მომხმარებელმა ჰკითხა Mainline განახლებების ხანგრძლივობას. პასუხად ილიან მალჩევი ამბობს რომ "ეს არის პოლიტიკის საკითხი, რომელსაც ჩვენ ჯერ კიდევ ვაფასებთ, მაგრამ გვსურს განაახლონ Mainline მოდულები მოწყობილობაზე რაც შეიძლება დიდხანს." XDA აღიარებული დეველოპერი luca020400 იკითხა, იქნება თუ არა წინასწარ აშენებული Mainline მოდულები, რათა მორგებული ROM-ის დეველოპერებმა შეძლონ განახლებების შერწყმა და საპასუხოდ, ჯეფ ბეილი იმეორებს რომ "მოდულებს, რომლებიც იშლება AOSP-ს, ექნებათ წყაროს გამოშვებები, რომლებიც შეესაბამება თითოეულ მოდულის გამოშვებას." ჩვენ უკვე შეგვიძლია დავინახოთ ახალი APEX მოდულების პროგრესი AOSP-ში, როგორიცაა ერთი ნერვული ქსელების API.

CameraX ხვდება ML Kit-ს

წელს I/O-ზე Google-მა წარადგინა CameraX Jetpack ბიბლიოთეკა. ეს ბიბლიოთეკა შექმნილია იმისთვის, რომ დეველოპერებს გაუადვილოს Android-ის Camera2 API-ის მხარდაჭერა, ხოლო Android Lollipop-თან თავსებადობის შენარჩუნება. ვინიტ მოდი ცელქი რომ კომპანია მუშაობს CameraX-ის ინტეგრირებაზე ML ნაკრები, Google-ის მანქანური სწავლების Firebase SDK, ასე რომ, დეველოპერებს შეუძლიათ გამოსახულების ჩარჩოები შეიყვანონ ML Kit-ში ანალიზისთვის.

CameraX გამყიდველის გაფართოებები და გამოშვების თარიღი

კამერის აპლიკაციის შემქმნელი წუხს იმ ფაქტზე, რომ კამერის მოწინავე ფუნქციები, როგორიცაა Google Pixel's Night Sight, მიუწვდომელია მესამე მხარის კამერის აპებისთვის. სავარაუდოდ, ეს გადაიჭრება CameraX გამყიდველის გაფართოებებით, რომლებსაც ჯეფ შარკი Google-იდან ამბობს რომ "ყველა Pixel მოწყობილობა ოპტიმიზებულია CameraX Core-სთვის." ის ამბობს, რომ "გაფართოების ასპექტი იქნება მხარდაჭერილი ახალ და მომავალ მოწყობილობებზე." გარდა ამისა, Google არის "ვმუშაობთ რამდენიმე მწარმოებელთან, რათა შევძლოთ მათი მოწყობილობის შესაძლებლობების დეველოპერებისთვის და მომხმარებლებისთვის ერთნაირად მიწოდება." მიუხედავად იმისა, რომ პირდაპირ არ არის დადასტურებული, შესაძლებელია ფუნქციები დავინახოთ მოსწონს ღამის ხედვა ზე Google Pixel 4 ხელმისაწვდომი გახდება მესამე მხარის კამერის აპებისთვის, რომლებიც იყენებენ CameraX ბიბლიოთეკას.

ბ-ნი შარკი აცხადებს, რომ Google მიზნად ისახავს ბეტა გამოშვებას ამ წლის ბოლოსთვის.

მეხსიერების მართვის გაუმჯობესება Android Q-ში

Pixel 3 გააკრიტიკეს იმის გამო, რომ ჰქონდა მრავალი საკითხი გაშვების შემდეგ, მაგრამ Google-მა ბევრი გააკეთა ამ საკითხების გადასაჭრელად მრავალი გზით გაშვების შემდგომ განახლებები. მეხსიერების მენეჯმენტი Pixel 3-ის ერთ-ერთი ყველაზე სუსტი ასპექტი იყო, მაგრამ Android Q გამოშვებაში ყველაფერი ოდნავ უკეთესი უნდა იყოს. სელიმ ცინეკის თქმით:

"მაგალითად SystemUI-ში, ჩვენ გვქონდა სხვადასხვა დიდი რეფაქტორირების მცდელობები Q-ში, შეტყობინებების და სხვა ზედაპირების ოპერატიული მეხსიერების გამოყენების შესამცირებლად."

საბოლოოდ მივიღებთ უკაბელო ADB-ს?

თუ გსურთ თქვენი ტელეფონის უსადენოდ გამართვა, თქვენ უნდა დააყენოთ თქვენი მოწყობილობა. Jamal Eason Android Studio-ს გუნდიდან ამბობს რომ ისინი ამჟამად განიხილავენ ამ ფუნქციის მიზანშეწონილობას.

Google ჯერ კიდევ ტაბლეტებზე ტესტირებას ახდენს?

XDA აღიარებული დეველოპერი ლუკ1337 ჰკითხეს, კვლავ ამოწმებს თუ არა Google AOSP UX-ს ტაბლეტებზე. სამართლიანი კითხვაა იმის გათვალისწინებით კარგი Android ტაბლეტების ნაკლებობა და არსებული შეცდომები მიმდინარე გამოშვებებში. ალენ ჰუანგი ამბობს რომ Google ჯერ კიდევ „ამოწმებს და ასწორებს ყოველწლიურად“ და რომ კომპანია მჭიდროდ თანამშრომლობს პარტნიორებთან „ანდროიდის ტაბლეტების კარგი გამოცდილების უზრუნველსაყოფად“.

---

კიდევ ბევრი პოსტია სრულ თემაში Reddit-ზე. ის, რაც მე აქ გავაშუქე, აჯამებს ყველა ახალ ინფორმაციას, რომელიც ჩვენ ვისწავლეთ, მაგრამ რამდენიმე Google-ის თანამშრომელი (განსაკუთრებით დაიან ჰეკბორნი) გადადით თავიანთ მსჯელობაში X ფუნქციის მოჭრის ან Y-ის არ განხორციელების უკან ნებართვა. გირჩევთ, წაიკითხოთ სრული AMA, თუ გსურთ უკეთ გაიგოთ Android-ის გუნდის გადაწყვეტილების მიღება.

წაიკითხეთ სრული AMA /r/AndroidDev-ზე