Az Android 14 arra készül, hogy az új API-knak köszönhetően még jobb élményt nyújtson a harmadik féltől származó alkalmazásboltok felhasználóinak.
A Google Play messze a legnépszerűbb alkalmazásbolt az Android-felhasználók körében, de egyesek azzal érvelhetnek, hogy nem szerezte meg tisztességesen az első helyet. A Google-t szabályozó ügynökségek és törvényhozó testületek vizsgálták világszerte, mert hogyan tartja meg az alkalmazásbolt-dominanciáját, és nincs jele annak, hogy ez a nyomás bármikor enyhülne hamar. Talán ezért is kezdeményezi a Google új funkciók bevezetését Android 14 amelyek javítják a harmadik féltől származó alkalmazásboltok felhasználóinak élményét.
A legtöbb harmadik féltől származó Android-alkalmazásbolt nem igazán versenyképes a Google Play-lel, és ez nem csak az alkalmazásválaszték miatt van így. Míg az első féltől származó, előre telepített alkalmazásboltok mindig is képesek voltak az alkalmazás automatikus frissítésére, a harmadik féltől származó alkalmazásboltok csak nemrégiben tudtak felügyelet nélkül frissíteni. A Google hozzátette
API az Android 12-ben amely lehetővé teszi, hogy a harmadik féltől származó alkalmazásboltok felhasználói beavatkozás nélkül frissítsék az alkalmazásokat, csökkentve ezzel a súrlódást harmadik féltől származó alkalmazásbolt használatával.Ez azonban továbbra is jelentős hátrányba hozta a harmadik féltől származó alkalmazásboltokat a funkcionalitás tekintetében, mivel nem tudták könnyen amikor biztonságos lenne valóban automatikus frissítést csinálni. Ezt próbálja megoldani a Google az Android 14-ben egy új API-val, amely lehetővé teszi a harmadik féltől származó alkalmazásboltok számára, hogy „szelíd frissítéseket” hajtsanak végre.
Gyengéd frissítések
Az Android 14 hozzáadott egy új API-t, amely lehetővé teszi a harmadik féltől származó alkalmazásboltok számára, hogy ellenőrizzék bizonyos feltételek teljesülését, mielőtt megkezdenék az alkalmazás automatikus frissítését. A Csomagtelepítő. InstallConstraints API "Az alkalmazásboltok használhatják automatikus frissítések biztosítására a felhasználói élmény megzavarása nélkül (ezt kíméletes frissítésnek nevezik) - például egy alkalmazásbolt visszatarthatja a frissítéseket, amikor megtudja [sic], hogy a frissítendő alkalmazás kölcsönhatásba lép a felhasználó.”
Ez az új API lehetővé teszi a harmadik féltől származó alkalmazásboltok számára, hogy ellenőrizzék, hogy a frissítésre készülő alkalmazás rendelkezik-e aktív előtér-szolgáltatással (isRequireAppNotForeground), valamilyen módon interakcióba lép a felhasználóval (isRequireAppNotInteracting), vagy a képernyőn van (isRequireAppNotTopVisible). A harmadik féltől származó alkalmazásboltok azt is ellenőrizhetik, hogy az eszköz szunyókálás módban (isRequireDeviceIdle) vagy telefonhívásban (isRequireNotInCall) van-e.
Míg az API lehetővé teszi annak meghatározását, hogy milyen feltételeket kell ellenőrizni, a dokumentáció az előre beállított kényszerek használatát javasolja, mivel a „rendszer tudja a legjobb, hogyan kell csinálni.” Ez logikus, mivel a Google-nek bőven volt ideje kidolgozni, hogyan kezelje a legjobban az automatikus frissítéseket a saját alkalmazásboltjában. Az előre beállított érték használata szintén előnyös, amint azt a dokumentáció is megjegyzi, mivel a kíméletes frissítések pontossága és hatékonysága javulhat a jövőbeli kiadásokban, ha a Google további megszorításokat ad az API-hoz.
Minden feltétel, amelyet a PackageInstaller. Az InstallConstaints API lehetővé teszi, hogy az ellenőrzés már meglévő API-kon keresztül is ellenőrizhető legyen, de sokkal egyszerűbb és kevésbé tolakodó, ha a rendszer kezeli ezeket az ellenőrzéseket. Például harmadik féltől származó alkalmazásboltok, amelyek ellenőrizni szeretnék, hogy egy általuk frissített alkalmazást aktívan használnak-e a felhasználónak jelenleg olyan API-t kell használnia, mint a UsageStats vagy az AccessibilityService, mindkettő érzékeny engedélyeket. Ha azonban ezt az új Android 14 API-t használják, akkor nem lenne szükségük ezekre az engedélyekre a munkájuk elvégzéséhez.
Frissítse a tulajdonjogot
A „szelíd frissítések” engedélyezése nem az egyetlen fejlesztés az Android 14-ben a harmadik féltől származó alkalmazásboltok számára. Van egy új „frissítési tulajdonjogi” mechanizmus is, amely lehetővé teszi, hogy a harmadik féltől származó alkalmazásboltok az általuk először telepített alkalmazások jövőbeni automatikus frissítéseinek kizárólagos forrásává váljanak. Ez azt jelenti, hogy ha harmadik féltől származó alkalmazásboltot használ, mert az azon keresztül elérhető alkalmazásokat a például, akkor a más alkalmazásboltokban elérhető, ellenőrizetlen frissítések nem kerülnek automatikusan A Te eszközöd.
Jelenleg, amikor egy alkalmazást harmadik féltől származó alkalmazásbolton keresztül telepít, semmi sem akadályozza meg, hogy egy belső alkalmazásbolt frissítse az alkalmazást. Míg az Android 12 felügyelet nélküli frissítési API-ja csak a harmadik féltől származó alkalmazásboltok számára teszi lehetővé az elsőként telepített alkalmazások csendes frissítését, a saját alkalmazásboltokat ez nem érinti, mivel rendelkeznek a kiváltságokkal. INSTALL_PACKAGES engedély.
A harmadik féltől származó alkalmazásboltok Android 14 rendszeren használhatják az újat setRequestUpdateOwnership módszer be Csomagtelepítő. SessionParams, azonban közölje a rendszerrel, hogy a frissítés tulajdonjogát követeli a telepíteni kívánt alkalmazás felett. Ha engedélyezve van egy alkalmazás frissítési tulajdonjogának betartatása, az összes többi alkalmazásboltnak – még az INSTALL_PACKAGES engedéllyel rendelkezőknek is – a felhasználótól kell intézkednie az alkalmazás frissítéséhez. A frissítés tulajdonjogát csak egy alkalmazás, tehát egy másik alkalmazásbolt kezdeti telepítése során lehet engedélyezni nem tudja átvenni a frissítéseket, kivéve, ha a kérdéses alkalmazást eltávolítják, és onnan újratelepítik bolt. Az alkalmazásboltok ellenőrizhetik, hogy a frissítési tulajdonjog engedélyezve van-e egy alkalmazáshoz, és ha igen, melyik alkalmazás a frissítés tulajdonosa az új InstallSourceInfo#getUpdateOwnerPackageName() API.
A harmadik féltől származó alkalmazásboltoknak rendelkezniük kell az új ENFORCE_UPDATE_OWNERSHIP engedélyt a frissítés tulajdonjogának érvényesítési API használatára, de mivel ennek az engedélynek a védelmi szintje „normál”, a rendszer a telepítéskor megadja. Azonban még várni kell, hogy a Google Play ellenőrzi-e ennek az engedélynek/API-nak a használatát.
Telepítse az előzetes jóváhagyást
Az utolsó új Android 14 API, amelyet szerettem volna kiemelni Csomagtelepítő. Session#requestUserPreapproval. Ez az API lehetővé teszi, hogy a harmadik féltől származó alkalmazásboltok felhasználói jóváhagyást kérjenek a telepítési munkamenet végrehajtása előtt. Úgy gondolom, hogy ez hasznos lesz a harmadik féltől származó alkalmazásboltok számára, amelyek szándékosan kérik a felhasználót, mielőtt frissítenének egy alkalmazást a háttérben.
Tegyük fel például, hogy egy biztonságra összpontosító alkalmazásbolt értesíteni szeretné a felhasználóját, ha egy alkalmazásfrissítés új engedélyeket ad hozzá; Ahelyett, hogy automatikusan frissítené az alkalmazást, és így automatikusan megadná az engedélyt, ha a védelmi szintje „normális”, az alkalmazásbolt kérheti a felhasználót a frissítés előtt. Jelenleg, ha egy felhasználó nincs jelen az automatikus frissítés során, akkor a harmadik féltől származó alkalmazásboltnak nyomon kell követnie a telepítési munkamenetet, és később fel kell kérnie őket. Ez az API leegyszerűsíti ezt a folyamatot.
Az Android 14 rengeteg új funkciót és API-t vezet be, amikor az év végén megjelenik a nyilvánosság számára. Bár ezek az új API-k nincsenek elrejtve, mint néhány más észrevett változás, nincs garancia arra, hogy ezek az API-k elérhetők lesznek a fejlesztők számára a stabil kiadásban. Ennek az az oka, hogy az API lefagyása nem fog megtörténni, amíg az Android 14 2023 júniusában el nem éri a „platformstabilitást” a Beta 3-mal, és jelenleg csak a DP1-et használjuk. Figyelni fogjuk a jövőbeli Android 14 DP és béta kiadásokat, hogy lássuk, megmaradnak-e ezek az API-k, vagy hozzáadódnak-e a harmadik féltől származó alkalmazásboltokhoz kapcsolódó új API-k.