A Google mérnökei a minap elvégeztek egy AMA-t a Redditen. Az AMA az Android Q béta verziójáról szólt. Íme egy összefoglaló, amit a válaszaikból tanultunk.
Tavaly a Google Android-csapata adott otthont egy Ask Me Anything (AMA) programnak a Reddit /r/AndroidDev alredditjén, hogy kérdéseket tegyen fel a Android P fejlesztői előnézet. Idén az Android Q bétaverzióján dolgozó mérnökcsapat válaszolt a kérdésekre a Redditen. Az AMA augusztus 1-jén 12:00 PST-kor kezdődött és körülbelül másfél órával később ért véget. 33 Google mérnök vett részt az AMA-ban, és rengeteg kérdésre válaszoltak az AMA rövid ideje alatt. Íme az összes megtudott új információ összefoglalása.
Android Q AMA: Minden, amit a Google-tól tanultunk
Az Android Q béta csapatának résztvevői
- Adam Cohen: TLM az Android Launcheren/rendszer felhasználói felületén
- Adam Powell: TLM a felhasználói felület eszköztárán/keretrendszerén; nézetek, életciklus, töredékek, támogatási könyvtárak
- Alan Viverette: TLM, Jetpack / AndroidX
- Allen Huang: PM a felhasználói felülethez, az indítóhoz, az értesítésekhez, a keresési integrációkhoz és még sok máshoz!
- Andrew Sappirstein: TLM az Android beállításaiban
- Brahim Elbouchikhi: PM igazgató az Android gépi tanulásért és kameráért (NN API, ML Kit, CameraX, Camera Platform)
- Chad Brubaker: Szoftvermérnök, Android Platform Security
- Charmaine D’Silva: PM az adatvédelemért
- Chet Haase: Android vezető szószóló, fejlesztői kapcsolatok
- Diana Wong: PM, alkalmazás-kompatibilitás, nem SDK API használat, ART, NDK
- Dianne Hackborn: Az Android keretrendszer csapatának menedzsere (Erőforrások, Ablakkezelő, Tevékenységkezelő, Többfelhasználós, Nyomtatás, Kisegítő lehetőségek stb.)
- E.K. Chung: UX igazgatója
- Ian Lake: Szoftvermérnök, Jetpack (töredékek, navigáció, architektúra komponensek)
- Iliyan Malchev: Vezető szoftvermérnök, Project Mainline
- Jacob Lehrbaum: Az Android fejlesztői kapcsolatokért felelős igazgatója
- Jake Wharton: Szoftvermérnök, Jetpack
- Jamal Eason: PM, Android Studio
- Jeff Bailey: TLM, Android nyílt forráskódú projekt (AOSP)
- Jeff Sharkey: Szoftvermérnök, Android Framework
- Jeffrey van Gogh: Android Studio, fordítók
- Jen Chai: PM, hely és kontextus, hitelesítés, automatikus kitöltés, nem SDK API használat, ART
- Karen Ng: Group PM Android Developer Tools, Android Studio, Android Tookit és Jetpack számára
- Paul Bankhead: A Google Play termékmenedzsment igazgatója
- Rohan Shah: Termékmenedzser, Android rendszer felhasználói felület
- Romain Guy: Az Android Toolkit/Jetpack csapat menedzsere
- Sagar Kamdar: Az Android termékmenedzsment igazgatója
- Szo K: Mérnöki igazgató, Android-kapcsolatok
- Selim Cinek: Szoftvermérnök, Android rendszer felhasználói felület
- Stephanie Saad Cuthbertson: Az Android termékmenedzsmentért felelős vezető igazgatója
- Sumir Kataria: Szoftvermérnök, Jetpack (WorkManager)
- Travis McCoy: PM, Android platform
- Trystan Upstill: Kiváló mérnök, az Android rendszer felhasználói felületének és intelligenciájának vezetője
- Vinit Modi: PM, Android kamera
Olvass tovább
Az OEM-ek már nem tudják megölni az alkalmazásokat, ha a felhasználó a közelmúltban ellopja őket
Ha valaha is használt kínai márkától származó okostelefont, akkor valószínűleg olyan bosszantó „akkumulátor-optimalizálási” funkciókkal kellett megküzdenie, öld meg az összes kedvenc alkalmazásodat a háttérben. Ez a viselkedés nemcsak azon felhasználók számára bosszantó, akik arra számítanak, hogy bizonyos alkalmazások a háttérben bármilyen okból továbbra is futnak, de bosszantó a fejlesztők számára is, akiknek rossz véleményeket kell elszenvedniük azoktól a felhasználóktól, akik nem értik, hogy ez nem az alkalmazásé. hiba. Míg a Google az még mindig nem foglalkoztak teljesen ezzel az üggyel (kézzel elhárították a problémát, kijelentve, hogy ez a viselkedés igen valószínűleg már megsértette az Android kompatibilitási meghatározási dokumentum követelményeit), a vállalat van cselekszik egyes OEM-ek által alkalmazott "akkumulátorkímélő" viselkedésmódosítással szemben.
"A helyzet segítése érdekében hozzáadtunk egy CTS-tesztet az Android Q-hoz, hogy megbizonyosodjunk arról, hogy egy alkalmazás ne öljön meg, amikor a Legutóbbiakból lehúzzák."
Az Android R több változtatást hozhat a képernyőképeken, mint azt vártuk
A Google tervezi hozzáadni képernyőképek görgetése Android R-ben, de ugyanakkor a Android csapat "Gondosabban megvizsgálva, hogyan javíthatják [X] a teljes képernyő-[X] élményt az R számára." Így lehet tekintse meg a képernyőkép (ÉS screencast) viselkedésének további fejlesztéseit a következő nagyobb Android-verzióban.
Az Android Q új asztali módjának tisztázása
A első nyilvános béta kiadás Az Android Q rejtett asztali módú felületet hozott az AOSP-hez és a Pixel Launcherhez. Bár a Google röviden érintette a funkciót A Google I/O munkamenete során soha nem hallottuk közvetlenül a Google-tól, hogy az új funkció hogyan illeszkedik az Android ökoszisztémájába. Google most tisztázza:
„A Q AOSP-ben az „asztali mód” egy fejlesztői lehetőség, amely az alkalmazásfejlesztőket célozza meg. Lehetővé teszi számukra, hogy teszteljék alkalmazásaikat többképernyős és szabad formájú ablakmódos környezetben. Korábban nem volt kényelmes módja az alkalmazások viselkedésének tesztelésére másodlagos kijelzőn és szabadon átméretezhető ablakokkal az Androidon. Ez a funkció nem önmagában készült, és jelenleg nem a rendszeres felhasználók számára készült. Mindazonáltal ez az Android platform alapja az OEM-ek számára, hogy innovációt és nagyszerű termékeket készítsenek."
Így várható, hogy az OEM-ek az Android Q natív asztali módjára építenek. Például a A OnePlus 7 Pro támogatja a HDMI-n keresztüli megjelenítést, szóval lehetséges Android Q alapú OxygenOS 10 a jövőben saját asztali módú felülettel fog rendelkezni. Azt is reméljük, hogy a Google a közelgő szolgáltatásra épít Pixel 4.
Időalapú sötét mód
Az Android Q végre elhoz egy széles körben kért funkciót: rendszerszintű sötét mód. Jelenleg a sötét mód manuálisan engedélyezhető a Beállításokban vagy a Gyorsbeállítások csempén keresztül, vagy automatikusan aktiválható, ha az Akkumulátorkímélő engedélyezve van. Az Android Q előtt lehetőség volt a sötét mód engedélyezésére a napszak alapján, de ez a lehetőség megszűnt. Chris Banes szerint:
"Van néhány oka annak, hogy ez az AppCompat v1.1.0-s verziójában elavult (nem távolított) el: ehhez az alkalmazásoknak kérniük kell A helymeghatározási engedélyek pontosak legyenek, és még érvényes hely esetén is lehetséges a napkelte/napnyugta időszámítása bricska."
Amikor ezekről a hibákról kérdezik, Banes úr azt mondja, hogy "a napkelte/napnyugta kiszámítása köztudottan nehéz, különösen a közeli helyeken. északi/déli pólusok." A felhasználó előhozza, hogy az Android 7.1 Nougat óta elérhető Night Light automatikusan átkapcsolható a naplemente/napkelte alapján menetrendek. Mr. Banes ezután kijelenti, hogy mivel a Night Light a CalendarAstronomer from ICU4J, akkor "nagy darab kódot használ, amelytől nem szeretnénk, ha az AppCompat függne". A csapat azonban igen állapot hogy ez a funkció "valami, amit [ők] megvizsgálnak".
Kötelező Camera2 API/Camera HAL3 támogatás az Android Q indítóeszközökhöz
A Google bevezette a Camera2 API-t, hogy jobban meghatározza, hogyan kommunikálhatnak az alkalmazások az okostelefonhoz csatlakoztatott egyedi kamerákkal. Miközben a Google bátorítja az okostelefon-gyártók "az összes fizikai kamerájukat kiteszik a fejlesztők elé", sok gyártó úgy dönt, hogy nem teszi ezt, bár "maga az API nem megakadályozza őket ma." Ez azt jelenti, hogy sok harmadik féltől származó kameraalkalmazás nem tudja használni a másodlagos vagy harmadlagos kameramodulokat a modern eszközökön okostelefonok. Az Android Q fejlődésével azonban előrelépés történik LOGICAL_MULTI_CAMERA, egy API, amely jobb hozzáférést biztosít a fejlesztőknek az eszköz összes kamerájához, és amely lehetővé teszi az OEM-ek számára az energiafogyasztás és a több kameraállapot kezelésének szabályozását.
Ezenkívül a Google azt állítja, hogy az összes Android Q-val induló eszközhöz követelményeket támasztott a Camera2 API/Camera HAL3 natív támogatásához. Vinit Modi szerint:
"Az Android P-től kezdődően az 1 GB vagy több RAM-mal szállított új eszközöknek natív módon kell használniuk a HALv3/camera2-t. Az Android Q-tól kezdve minden új eszköznek natívan támogatnia kell a HALv3/camera2-t. Sajnos a HALv1-ről HALv3-ra történő frissítés meglehetősen bonyolult, és váratlan következményekkel járhat, ezért a hatókört az új eszközökre kellett korlátoznunk."
Érdekes módon Modi nyilatkozata a normál RAM-mal rendelkező Android P indítóeszközökről ellentmond mit mondott nekünk korábban a Google, és mi van közzétéve az Image Test Suite online oldalán.
Dinamikus alkalmazástéma a Jetpack Compose segítségével
A Sony OMS keretrendszerét jó néhány kiadással ezelőtt hozzáadták az AOSP-hez, de ez csak az OEM-eknek szánták rá építeni. Ezt már tudjuk A Google ellene van futásidejű erőforrás-fedvények használata a felhasználók által a témaalkalmazásokhoz, de a fejlesztők számára a vállalat igen remélve hogy annak Jetpack Compose UI keretrendszer "érdekes megközelítéseket hoz a dinamikus témaalkotáshoz".
Vulkan-backend a Skia számára a felhasználói felület megjelenítéséhez
Tavaly, vitát észleltünk A Google mérnökei arról beszélnek, hogy az Android keretrendszer a Vulkan grafikus API-t használja a felhasználói felület megjelenítéséhez. Míg a Vulkan hardveres gyorsítású háttérrendszert a telefon nélkül is engedélyezheti összeomlik, nem hallottunk konkrét terveket a Google-tól arról, hogy mikor tervezik ezek bevezetését változtatások. Ez az AMA nem válaszol erre a kérdésre, de legalább megerősítettük, hogy még mindig készül. Romain Guy szerint:
"A csapat a Skia Vulkan háttérrendszerén dolgozik, az Android által használt 2D-s rendereren, de ez jelenleg alapértelmezés szerint nincs engedélyezve. A felhasználói felület és a Canvas továbbra is az OpenGL ES-en keresztül megy."
Az Android Q gesztussávjának dinamikusabbá tétele
Néhányan az XDA-n még mindig ezt gondolják Az Android új gesztusai káosz, de személy szerint úgy gondolom, hogy jól vannak. Ha azonban egy kicsit játszol az Android Q új gesztusaival, észre fogod venni, hogy a gesztussáv nem mozog az ujjaddal. Olyan képernyőkön is megmarad, ahol nincs rá szükség, például a kezdőképernyőn vagy a legutóbbi alkalmazások áttekintésén. Allen Huang mondja hogy "teljesen egyetértenek abban, hogy vannak lehetőségek" a "navigációs vonal kevésbé statikussá tételére". A továbbiakban azt mondja hogy „ez egy olyan dolog, amin dolgozunk – de egyben egyensúlyozunk is, hogy ne legyen zavaró megjelenik/eltűnik."
A Storage Access Framework fejlesztései
Az Android Q számos változása jelentősen javította a a platform biztonsága és adatvédelme. Az egyik ilyen változtatás, az úgynevezett „Scoped Storage”, ésszerű módon korlátozza az alkalmazások hozzáférését a külső tárolón lévő fájlokhoz; például a zenei alkalmazásoknak nem kell látniuk a galériát. Az Android Q-ban futó fájlkezelő alkalmazásoknak a Storage Access Framework nevű API-t kell használniuk, hogy továbbra is a megszokott módon működjenek, de egyes fejlesztők ezt az API-t alsóbbrendűnek látják ahhoz, ami korábban elérhető volt. Jeff Sharkey a Google-tól mondja a csapat a fejlesztői panaszok közül néhányat kezelt:
"Néhány SAF-teljesítménybeli fejlesztést hajtottunk végre a legújabb Android Q Beta kiadásokban; össze tudnád hasonlítani a benchmarkokat a legújabb béta verzióval? Győződjön meg arról is, hogy ContentProviderClient programot használ tömeges műveletek futtatásakor."
A Project Treble javította az Android Pie alkalmazását az Android Oreo-hoz képest
Már láttuk, hogy a Project Treble, az Android keretrendszer alacsony szintű újraépítése, hogyan javította az Android operációs rendszer újabb verzióinak elfogadását. A Google a Treble-nek tulajdonítja, hogy rengeteg okostelefon-gyártó csatlakozott a programhoz Android P béta tavaly és Android Q béta idén. Iliyan Malchev, a projekt vezető Treble és Fő vonal mérnök, mondja hogy 2018 végén az Android Pie bevezetése „háromszorosa” volt az Android Oreoénak.
Ugyanebben a megjegyzésben Dick Dougherty azzal ugratja, hogy további hasznos mérőszámok készülnek az Android verzió terjesztési táblázatára. A diagram az volt utoljára májusban frissítve, de adatai hasznosabbak az újságíróknak, mint az alkalmazásfejlesztőknek.
A képernyőrögzítés továbbra is WIP
A korai Android Q béták egy funkciójelzőt adtak hozzá az alapvető képernyőrögzítőhöz, de maga a platform jelentősen javította a képernyőrögzítés hasznosságát lehetővé teszi az alkalmazások számára, hogy más alkalmazások hangját rögzítsék. Stephanie Saad Cuthbertson elmondta, hogy a csapat azt fontolgatja, "hogyan tudnánk jobban teljesíteni a képernyőrögzítési igényeket a tegnapi nap folyamán". Más okostelefon márkák, mint pl OnePlus, az ASUS, a Huawei és a Samsung robusztus képernyőrögzítőkkel rendelkezik, amelyek képesek rögzíteni a belső hangot, így a Google itt fog játszani.
Dark Theme All The Things!
Ha lemaradt volna, a Google sötét módot ad a legtöbb alkalmazásához. Stephanie Saad Cuthbertson mondja elvárja, hogy az összes „nagy alkalmazás” támogassa a sötét témát „a hivatalos [Android Q] kiadásban”. Még a Google Chrome is, amely jelenleg oldal újratöltését kényszeríti, ha a rendszerszintű sötét téma engedélyezve van, a rendszer úgy frissíti, hogy a téma nem frissít megváltozott.
Igen, a harmadik féltől származó indítók működni fognak a gesztusokkal (végül)
Az Android gesztusai amolyan elromlik, ha harmadik féltől származó indítót használ. Ennek az az oka, hogy a legutóbbi alkalmazások felhasználói felülete az állományindító alkalmazásban található, a Google pedig még nem kidolgozott egy módszert arra, hogy ugyanazokat a zökkenőmentes átmeneteket biztosítsa, mint a Pixel mozdulatainak használatakor Indító. Adam Cohen megerősíti A Google azt tervezi, hogy a lehető leggyorsabban orvosolja ezeket a problémákat a megjelenés után. A továbbiakban azt mondja az inkompatibilitást "a Q utáni frissítésben kezeljük, és visszaportálják a vele induló új eszközökhöz K."
A dinamikus/logikai partíciók nem az egyéni ROM-ok megölésére szolgálnak
A támogatás érdekében Dinamikus rendszerfrissítések Az Android Q-ban bizonyos eszközök, például a Google Pixel 3 és a Pixel 3 XL logikai partíciókat használnak. Ezek a partíciók dinamikusan átméretezhetők. Ez a változás megvan kihívásnak bizonyult a root hozzáférés működése, és néhány fejlesztő aggódik amiatt, hogy egyedi ROM-okat céloznak meg. Iliyan Malchev biztosít bennünket, hogy a szándék nem korlátozza az egyéni ROM-okat. Mint Magyarázza:
"A dinamikus partíciók nem korlátozzák az egyéni ROM-okkal végzett műveleteket. Ezek egyszerűen egy megoldás a rögzített partícióméretek és az eszközök újraparticionálásának biztonságos módja hiányára OTA. A dinamikus partíciók előtt, ha egy OEM hibázott a méretezésnél pl. a rendszerpartíciót, majd ők korlátozná ez a választás, ami gyakorlatilag lehetetlenné teszi az eszköz frissítését egy bizonyos idő után pont. Egyes OEM-ek a gyakorlatban újraparticionálják eszközeiket OTA-n, de ezt a) hivatalosan nem támogatja az Android, és b) a partíciós tábla megváltoztatása meglehetősen kockázatosnak számít. A dinamikus partíciók célja a probléma enyhítése a fizikai partíciós tábla és az operációs rendszer nézetei közötti indirekt szint bevezetésével. Ez viszont lehetővé teszi számunkra, hogy biztonságosan módosítsuk a partíciók méretét az OTA-n. Ami az egyedi ROM-okat illeti, egyáltalán nem szabad korlátoznia, mint manapság azzal, hogy mit tehet. Az egyéni ROM-ok támogatása minden egyes OEM-gyártó úgy dönt, hogy engedélyezi, és továbbra is az lesz."
Projekt fővonal - ART modul és támogatás hossza
A Mainline a Google új kezdeményezése, amelynek célja egyes könyvtárak és csomagok szabványosítása, hogy azok a platformfrissítésektől függetlenül frissíthetők legyenek. Egyesek azon tűnődtek, hogy az Android Runtime (ART) miért nem még fővonali modul, de a Google I/O-n azt mondták, hogy az ART modularizálásának összetettsége megakadályozta őket abban, hogy az egyik kezdeti APEX-csomagot beépítsék. Mint magyarázta Iliyan Malchev és Diana Wong is:
"A Runtime frissítése (különösen a teljesítmény- és GC-javítások és az alapvető könyvtárak) minden bizonnyal olyan dolog, amelyet a fővonal kontextusában vizsgálunk. Rengeteg előnyt láthatunk annak, ha ezeket a frissítéseket minden eszközön és több kiadáson is konzisztenssé tehetjük a fővonalon. Ez egyben hatalmas technikai kihívás is, mivel azon gondolkodunk, hogyan tehetjük ezt a legjobban a fejlesztők számára, és valószínűleg több éves erőfeszítést igényel. A Mainline jelenleg nem képes erre, de minden bizonnyal azon gondolkodunk."
Ha követi az AOSP Gerrit-et, látni fogja, hogy a Google ennek ellenére az keményen dolgozik Runtime APEX készítése. Jelenleg úgy tűnik a Bionic és az ART/libcore felosztása külön APEX modulokba.
A Project Mainline előnyeivel kapcsolatban egy felhasználó megkérdezte a Mainline frissítések hosszát. Válaszul Iliyan Malchev mondja hogy "ez egy olyan politikai kérdés, amelyet még értékelünk, de szeretnénk frissíteni a Mainline modulokat egy eszközön, ameddig csak lehetséges." XDA elismert fejlesztő luca020400 arról érdeklődött, hogy lesznek-e előre elkészített Mainline modulok, hogy az egyéni ROM-fejlesztők egyesíthessék a frissítéseket, és válaszul Jeff Bailey megismétli hogy "az AOSP-ből leválasztott modulok forráskiadásai megfelelnek az egyes modulkiadásoknak." Már láthatjuk az új APEX modulok fejlődését az AOSP-ben, mint például az a Neurális hálózatok API.
A CameraX találkozik az ML Kittel
Az idei I/O-n a Google bemutatta a CameraX Jetpack könyvtár. Ez a könyvtár célja, hogy megkönnyítse a fejlesztők számára az Android Camera2 API támogatását, miközben a kompatibilitást az Android Lollipopig visszamenőleg megőrzi. Vinit Modi kötekedik hogy a cég a CameraX integrálásán dolgozik ML Kit, a Google gépi tanulási Firebase SDK-ja, így a fejlesztők képkereteket tölthetnek be az ML Kitbe elemzés céljából.
CameraX szállítói bővítmények és megjelenési dátum
A kameraalkalmazás fejlesztője nehezményezi, hogy a fejlett kamerafunkciók, mint például a Google Pixel Night Sight, nem érhetők el harmadik féltől származó kameraalkalmazások számára. Ez állítólag megoldható CameraX gyártói bővítményekkel, amelyekhez Jeff Sharkey a Google-tól mondja hogy "minden Pixel eszköz CameraX Core-ra van optimalizálva". Azt ugratta, hogy "a bővítményeket támogatni fogják az új és a közelgő eszközökön." Ráadásul a Google az "több gyártóval együttműködve, hogy eszközeiket a fejlesztők és a felhasználók számára egyaránt el tudják juttatni." Bár közvetlenül nem erősítették meg, lehetséges, hogy látunk funkciókat mint Éjszakai látás a Google Pixel 4 elérhetővé válnak a CameraX könyvtárat használó, harmadik féltől származó kameraalkalmazások számára.
Mr. Sharkey kijelenti, hogy a Google a béta kiadást célozza meg ez év végére.
Memóriakezelési fejlesztések az Android Q-ban
A Pixel 3-at elítélték számos probléma az indulás után, de a Google rengeteget tett ezeknek a problémáknak a megoldása érdekében bevezetés utáni frissítések. A memóriakezelés a Pixel 3 egyik leggyengébb oldala, de a dolgoknak egy kicsit jobbnak kell lenniük az Android Q kiadásban. Selim Cinek szerint:
"Például a SystemUI-ban számos nagy átalakítási erőfeszítést tettünk a Q-ban, hogy csökkentsük az értesítések és más felületek RAM-használatát."
Kapunk végre vezeték nélküli ADB-t?
Ha vezeték nélkül szeretné hibakeresni a telefont, rootolnia kell az eszközt. Jamal Eason az Android Studio csapatától mondja hogy jelenleg foglalkoznak a funkció megvalósíthatóságával.
A Google továbbra is tesztel táblagépeken?
XDA elismert fejlesztő Luk1337 megkérdezte, hogy a Google még mindig teszteli-e az AOSP UX-et táblagépeken. Ez egy jogos kérdés, figyelembe véve a jó Android táblagépek hiánya és a hibák jelen vannak az aktuális kiadásokban. Allen Huang mondja hogy a Google továbbra is "évente teszteli és javításokat végez", és hogy a vállalat szorosan együttműködik partnereivel "a jó Android-táblagép-élmény biztosítása érdekében".
A Redditen sokkal több bejegyzés található a teljes szálban. Az itt leírtak összefoglalják az összes új információt, amelyet megtudtunk, de több Google-alkalmazott is (különösen Dianne Hackborn) belemennek az X funkció levágása vagy az Y megvalósítása mellőzésének okaiba engedély. Azt javaslom, hogy olvassa el a teljes AMA-t, ha egy kicsit jobban meg szeretné érteni az Android csapat döntéshozatalát.
Olvassa el a teljes AMA-t az /r/AndroidDev oldalon