Android 11 AMA: Nincsenek görgethető képernyőképek, gyorsabban indulnak el az alkalmazások, és így tovább

Tegnap a Google kiadta Android 11 Beta 2, amely a véglegesített SDK-t, NDK-t, az alkalmazások felé néző felületeket, a platform viselkedését és a nem SDK-n kívüli felületekre vonatkozó korlátozásokat hozza a fejlesztők számára. Ma a Google megválaszolja az Android 11-el kapcsolatos kérdéseket a Reddit /r/AndroidDev közösségében miután múlt héten feltett kérdéseket. Íme egy összefoglaló mindarról, amit a Google AMA (Ask Me Anything) programjából tanultunk.

Az Android 11 egyik legjobban várt funkciója nem lesz elérhető, amikor az operációs rendszer beáll szeptember 8-án kilép a bétából: képernyőképek görgetése. Alapvetően a tervek szerint Android 11-ben fog megjelenni, a Google most megerősítette, hogy a funkció "nem hozta meg az R-t." Android 11 Developer Preview 1 és minden további DP és Béta kiadásban van egy helyőrző gomb a görgető képernyőkép készítéséhez

kézzel előkerült egy rejtett fejlesztői paranccsal, de a gomb megérintésével egyszerűen egy pirítós üzenet jelenik meg, amely szerint a funkció "nincs implementálva".

Reméltük, hogy a funkció bekerül a bétaverzióba vagy akár csak a stabil kiadásba, de úgy tűnik, ez nem fog megtörténni.

Ez a hír érthető módon felkavaró lesz néhány felhasználó számára. Végül is sok OEM már évek óta rendelkezik ezzel a funkcióval a saját szoftverében, tehát mi tart ilyen sokáig a Google-nak, hogy hozzáadja a Pixel telefonokhoz? Amint azt Dan Sandler, a Google System UI csapatától kifejtette, a probléma az, hogy a Google jól akarja csinálni. Egyes görgető képernyőkép-megvalósítások egyszerűen emulálnak egy görgetést, majd a képernyő mozgása közben több képernyőképet is összefűznek. Ha valaha is foglalkozott a felhasználói felület automatizálásával Androidon, akkor tudja, hogy ez nem mindig működik, mivel – ahogyan Sandler úr is említi – az alkalmazások használhat "egy bog-szabványú RecyclerView-t, vagy saját OpenGL-gyorsított görgetőmotort valósít meg." Mivel a Google azt tervezi ezt a funkciót nem csak a Pixel okostelefonokon, hanem a teljes Android-ökoszisztémán is megvalósítani az AOSP részeként, gondoskodniuk kell arról, hogy működni fog minden alkalmazásokat, és nem csak „egy vagy két kézzel kiválasztott alkalmazást egy adott eszközön”.

Mert a csapatnak „korlátozott erőforrásaikra összpontosítania kellett”, különösen a kihívások miatt A COVID-19 miatt a csapat úgy döntött, hogy görgethető képernyőképeket helyez el a háttéríróba egy jövőbeli Android-kiadáshoz.

Új CDD-követelmény, amely tájékoztatja a felhasználókat a háttérbeli korlátozásokról

Nem titok, hogy sok Android OEM-nél, különösen a kínainál, agresszív korlátozások vonatkoznak a háttérben futó alkalmazásokra. Egyes fejlesztők annyira csalódottak voltak amiatt, hogy a háttérben elpusztulnak az alkalmazásaik, hogy összefogtak, és létrehoztak egy weboldalt "Ne öld meg az alkalmazásomat", hogy rangsorolja az OEM-eket az alapján, hogy milyen rosszul kezelik a háttéralkalmazás-folyamatokat. Ugyanazok a fejlesztők még a közelmúltban is mércét tett így a felhasználók tesztelhetik, milyen agresszívan öli meg eszközük az alkalmazásokat a háttérben. Bonyolult az oka annak, hogy sok OEM miért szereti megölni a háttérben futó alkalmazások folyamatait, de azt hiszem, ezt a Redditor ebben a megjegyzésében magyarázza meg a legjobban /u/esetleg megkérdőjelezhető. A megjegyzés felvázolja az Android-alkalmazások fejlesztésének bonyolult helyzetét Kínában, a kínai technológiai cégek mikéntjét részt vesznek a dolgok további bonyolításában, és hogy a Google-szolgáltatások hiánya hogyan járul hozzá a folyamathoz rendetlenség.

Ettől függetlenül sok alkalmazásfejlesztő érthetően frusztrált az Android-platform viselkedését érintő változtatások miatt, aminek következtében a fejlesztők megjegyzéseket tettek. megkérdezi a Google-t, mit csinálnak ezzel a Reddit AMA tetejére. Íme a Google válasza:

Néhány dolgot le kell vonni ebből a válaszból. Először is, a Google azt szeretné, ha az OEM-ek átláthatóbbá válnának a felhasználók számára az általuk alkalmazott háttéralkalmazás-korlátozásokkal kapcsolatban. Ellenőriztem a (kiadatlan) Android 11 kompatibilitási definíciós dokumentumot (CDD), és a következő javasolt kiegészítést találtam a 3.5. szakasz – API viselkedési kompatibilitás című részhez:

Ha az eszközmegvalósítások szabadalmaztatott mechanizmust alkalmaznak az alkalmazások korlátozására, és ez a mechanizmus szigorúbb, mint az AOSP „ritka” készenléti csoportja, akkor:

[C-1-5] Tájékoztassa a felhasználókat, ha az alkalmazáskorlátozások automatikusan alkalmazásra kerülnek. (ÚJ) Az ilyen információkat nem KELL megadni a korlátozások alkalmazása előtt 24 óránál korábban.

(Megjegyzés) A Force Stop szigorúbbnak tekintendő, mint a "Ritka", és meg kell felelnie a 3.5.1 összes követelményének, beleértve az új 3.5.1/C-1-5

Alapvetően a Google nem akadályozza meg az OEM-eket abban, hogy bevezessék saját korlátozó alkalmazásgyilkos funkcióikat. Csak azt követelik meg, hogy az OEM-ek tájékoztassák a felhasználókat, ha alkalmazáskorlátozásaikat automatikusan alkalmazzák. Egy OEM megjeleníthet egy párbeszédpanelt, amelyben leállítja az akkumulátort szívó háttéralkalmazások futását a rendszerben háttérben, és a felhasználó beleegyezhet anélkül, hogy észrevenné, hogy valójában milyen alkalmazásokat akar futtatni a háttérben érintett! A Google a fejlesztőkre hárítja a felelősséget, hogy kezeljék azokat az eseteket, amikor alkalmazásukat váratlanul megölik a háttérben. Valójában a Reddit megjegyzés tovább emeli az új "alkalmazásfolyamat-kilépési okok" API, amely meg tudja mondani a fejlesztőknek, hogy alkalmazásukat a felhasználó, az operációs rendszer ölte-e meg, vagy egyszerűen összeomlott.

Másrészt a Google végre foglalkozik az OEM-ek tisztességtelen gyakorlatával, amelyek lehetővé teszik bizonyos kiemelt alkalmazások számára, hogy megkerüljék a háttérben alkalmazott alkalmazáskorlátozásaikat. Ez a közepes bejegyzés a fejlesztőtől Timothy Asiimwe részletesen ismerteti az olyan alkalmazásokat, mint a WhatsApp, a Facebook és más alkalmazások automatikusan mentesülnek egyes OEM-szoftverek szigorú háttérkorlátozásai alól. A Google szerint "megkövetelik, hogy az eszközgyártók ne hozzanak létre engedélyezési listákat a legnépszerűbb alkalmazásokhoz". Nem tudjuk, hogyan fogják ezt betartatni, de jó tudni, hogy az OEM-ek végre kénytelenek lesznek egyenlően kezelni a külső fejlesztőket – függetlenül attól, hogy milyen nagyok vagy kicsik az alkalmazásaik vannak.

Végül a Google azt is megemlíti, hogy az Android 11 „kiegészítő intézkedéseket adott hozzá a helytelenül működő alkalmazások általi visszaélések megelőzésére”, így kevésbé csábítja az OEM-eket a háttérfolyamatok agresszív megölésére. A cég azonban nem részletezte, hogy ezek az "extraintézkedések" mit jelentenek.

Továbbfejlesztett eszközök közötti biztonsági mentések

A múlt hónapban változást észleltünk az Android 11 dokumentációjában utalt a jobb helyi adatmentések támogatására. Az Android 11 rendszerben a rendszer figyelmen kívül hagyja az allowBackup Manifest attribútumot minden olyan alkalmazásnál, amely a 30. API-szintet célozza meg, amikor a felhasználó kezdeményezi az alkalmazásfájlok „eszközről eszközre” migrációját. Eliot Stock Google-alkalmazott szerint ennek a funkciónak az a célja, hogy "sokkal könnyebbé tegye a telefongyártók számára az eszközök közötti migrációs eszközök létrehozását", mint például a "Samsung kiváló Smart Switch terméke". segít "biztosítani, hogy az alkalmazások felhasználói szemszögből megbízhatóbban kommunikáljanak az eszközök között." Sajnos ez nem vonatkozik a felhő alapú biztonsági mentésekre, mivel a Google azt akarja, hogy „a szoftverfejlesztők szabályozzák, az alkalmazásadataikkal történik." Ennek megfelelően az Android 11 továbbra is tiszteletben tartja az allowBackup attribútumot minden felhőalapú biztonsági mentésnél és visszaállításnál, például a Google Play szolgáltatás beépített Google Drive-ján keresztül. biztonsági mentés. Végül a Google elismeri, hogy az alkalmazásonkénti 25 MB biztonsági mentési plafon egyes fejlesztők számára nem biztos, hogy elegendő, ezért keresik a megoldást. A PC-re történő helyi biztonsági mentések azonban nincsenek mérlegelés alatt, és a Google megismétli a tervét fokozatosan megszünteti az adb biztonsági mentést egy jövőbeli Android-kiadásban.

A fejlesztőket arra ösztönzik, hogy súrlódásmentes adatmigrációs módszereket alkalmazzanak. A új Block Store könyvtár, amely a Google Identity Services Library része, és célja, hogy megkönnyítse a visszaállított alkalmazásokba való bejelentkezést. a felhőből az új eszközökön, de a fejlesztők maguk dönthetik el, hogy kívánják-e ezt megvalósítani vagy sem könyvtár.

Gyorsabb alkalmazásindítási sebesség az I/O előreolvasási folyamattal (IORAp)

A Google folyamatosan kísérletezik az Android teljesítményének javításának módszereivel. Az egyik kevéssé ismert funkció, amelyet az Android 10-hez adtak hozzá, az Unspecialized App Process Pool (USAP) nevet viseli. Ez a funkció kiküszöböli a Zygote elágazását az alkalmazásindítási folyamat során, így körülbelül ~5 ms-t takarít meg az átlagos alkalmazásindítási sebességben egy Pixel 2 eszközön. A funkció jelenleg alapértelmezés szerint le van tiltva az AOSP-ben, és a Google elmagyarázza, hogy a hozzáadott memóriahasználatot még tesztelni kell. Ennél is érdekesebb azonban, hogy az Android 11-be érkezik egy új funkció, az I/O Read Ahead Process (IORap). A Google szerint, ez a funkció "több mint 5%-kal gyorsabb hidegindítást eredményez, és a hős esetek 20%-kal gyorsabban érik el." Ez a funkció "előlekéri az alkalmazások melléktermékeit (például a kódot és az erőforrásokat) az indítási folyamat során" az alkalmazásindítás felgyorsítása érdekében sebességek.

A Google emellett "javításokat végzett a rendszerindítási osztály elérési útjának és rendszerképének optimalizálására használt profilokon" amely javítja az alkalmazások teljesítményét, és csökkenti a rendszerhez kapcsolódó memória- és tárolási költségeket műtárgyak. Ezek a változtatások leginkább a nagyobb mennyiségű RAM-mal rendelkező eszközöket érintik, bár a Google nem közölte, hogy mi a küszöb, ahol a legtöbb előnyt fogjuk látni.

Az Android 11 hatálya alá tartozó tárhely változásai – Miért korlátozott a hozzáférés a /Letöltésekhez?

Azok az alkalmazások, amelyek az Android 11-et célozzák, és az ACTION_OPEN_DOCUMENT_TREE szándékot használják, hogy hozzáférést kérjenek bizonyos könyvtárakhoz a külső eszközön A tárhely többé nem tud hozzáférést kérni a felhasználóktól a külső tároló gyökérkönyvtárához (/data/media/{user}), a letöltés könyvtárban (/data/media{user}/Download), vagy a külső tárolón lévő bármely alkalmazás-specifikus adatkönyvtárban (/Android/data vagy /Android/obb). Miért van korlátozva a hozzáférés a letöltési könyvtárhoz? A Google szerint Roxanna Aliabadi, ez azért van, mert a letöltési mappa "a legnagyobb veszélynek van kitéve, hogy személyes adatokkal rendelkezik". Például a felhasználók, akik letöltik az adójukat visszaküldések vagy bankszámlakivonatok esetén nem kell aggódniuk amiatt, hogy az alkalmazások visszaélnek a Könyvtár. A Google azt mondja, hogy a dokumentumválasztó "frissített szöveggel... jelezni fogja, hogy az Android korlátozott bizonyos mappákat Ez remélhetőleg csökkenti a zavart azzal kapcsolatban, hogy miért nem tudnak hozzáférést biztosítani az alkalmazásoknak bizonyos könyvtárakhoz többé.

Ha további információra van szüksége a Scoped Storage and Play szabályzat közelgő változásairól, olvassa el ezt a cikket.

Vegyes témák

• A Google álláspontja a rootolással/módosítással kapcsolatban
  • Jeff Bailey, a Google AOSP csapatának tagja megismétli a vállalat álláspontját a választás támogatásával kapcsolatban. A Google "továbbra is gondoskodni fog arról, hogy a Pixel eszközcsalád módosítása/rootolása lehetséges legyen", de emellett "támogatja az OEM-ek választását, hogy ne engedélyezzék eszközeiket Ezen túlmenően a Google választási lehetőséget ad a szoftverfejlesztőknek, hogy „ne engedjék, hogy szoftvereik rootolt eszközökön fussanak”, hivatkozva a legutóbbi változásokra a SafetyNet Attestation API szoftver szabotázs észlelése.
• Mi történt a "megnyitás és alapértelmezettre állítás" funkcióval?
  • Android 10 készült kicsit bosszantó egy alkalmazást alapértelmezett kezelőként beállítani konkrét linkekre, ami a Google szerint azért történt, hogy megvédjék a felhasználókat a "kizsákmányoló alkalmazásoktól". A Google meghátrált ezen a változtatáson, miután újragondolta, „a színfalak mögött számos változtatást” hajt végre a felhasználó védelme érdekében.
• A Vulkan Graphics API-t használja a felhasználói felület megjelenítéséhez?
  • A Google végül azt tervezi, hogy használja a Vulkan Graphics API-t a felhasználói felület megjelenítéséhez, ami némi teljesítményjavulást eredményez. Ez még értékelés alatt áll, de a cégnek semmilyen konkrétumot nem tudott megosztani.
• Számos eszközről hiányzik a CallScreeningService
  • Az Android alkalmazások megvalósíthatják a CallScreeningService API az új bejövő és kimenő hívások lehallgatására, lehetővé téve számukra a hívó azonosítását és a hívás elfogadását vagy elutasítását. Bár ez egy hivatalosan dokumentált API, a fejlesztő /u/ szerint láthatóan sok OEM nem implementálja megfelelően._zeromod_. Google megerősíti hogy ezt az API-t a Compatibility Test Suite (CTS) ellenőrzi, egy automatizált tesztcsomag, amelyen minden eszköznek át kell mennie ahhoz, hogy Android-kompatibilis legyen. Bármilyen okból kifolyólag, ez az API nullát ad vissza, amikor olyan OEM-ek hívják, mint a Huawei, a Vivo, a Xiaomi vagy a Samsung, így valószínűleg ezeknek az OEM-eknek van egy hibája a szoftverükben.
• Nincs terve audio beépülő keretrendszer
  • Egy fejlesztő megkérdezte a Google-tól, hogy terveznek-e olyan audio beépülő modult megvalósítani, mint az Apple Audio Units, de a válasz nem valószínű, hogy ez a közeljövőben megtörténik.

Elolvashatja az Android mérnöki csapatának összes válaszát itt. A csapat néhány megjegyzésben beszél egy kicsit a Java-ról, a Kotlinról, az Android build rendszerről, a CameraX API-ról és más témákról. Számos megjegyzés érkezett a Wear OS-ről, az Android TV-ről és az Android Auto-ról is, de a Google többnyire megismétli meglévő munkájukat ezeken a platformokon, és arra kéri a fejlesztőket, hogy maradjanak velünk a további információkért "Android Beyond Phonesaugusztus 10-től kezdődő hét.