Sideloading (instalacja aplikacji spoza sklepu)

Sideloading to instalacja aplikacji z pominięciem oficjalnego sklepu urządzenia: plik APK pobrany w przeglądarce, przysłany mailem, skopiowany z pendrive'a albo wgrany z komputera przez kabel. Android traktuje takie instalacje jako pochodzące z nieznanych źródeł. Według jego dokumentacji system blokuje instalacje spoza zaufanego sklepu producenta systemu, dopóki użytkownik się na nie nie zgodzi.

Sposób wyrażenia zgody zależy od wersji Androida. Od Androida 8.0 (API 26) zgodę daje się osobno dla każdego źródła: użytkownik włącza opcję Allow app installs dla jednej konkretnej aplikacji, na przykład przeglądarki albo menedżera plików, na ekranie ustawień Install unknown apps. W Androidzie 7.1.1 i starszych był jeden globalny przełącznik Unknown sources albo zgoda na pojedynczą instalację. Aplikacja, która uruchamia instalację, musi zadeklarować uprawnienie REQUEST_INSTALL_PACKAGES, a ponieważ użytkownik może w każdej chwili cofnąć zgodę, przed każdą próbą powinna wywołać canRequestPackageInstalls().

Pod spodem każdy instalator korzysta z PackageInstaller. Aplikacja otwiera sesję, przesyła do niej jeden lub kilka plików APK i zatwierdza instalację. Zatwierdzenie może wymagać potwierdzenia przez użytkownika, chyba że wywołującym jest właściciel urządzenia (device owner) albo powiązany właściciel profilu (affiliated profile owner). Wtedy instalacja kończy się automatycznie. Tak oprogramowanie MDM instaluje aplikacje na zarządzanych telefonach, nikogo nie pytając.

Android wymaga, żeby każdy plik APK był podpisany certyfikatem, zanim zostanie zainstalowany lub zaktualizowany. Gdy przychodzi nowa wersja, system porównuje jej certyfikaty z certyfikatami zainstalowanej aplikacji i pozwala na aktualizację tylko wtedy, gdy się zgadzają. Plik z właściwą nazwą pakietu, ale innym kluczem nie zastąpi istniejącej aplikacji. Podpis pokazuje, kto może aktualizować aplikację; nic nie mówi o tym, czy aplikacja jest bezpieczna.

Każda droga instalacji to wejście na urządzenie. We flocie zwykłych telefonów z Androidem każdą z nich zamyka albo kontroluje polityka MDM, a we własnym urządzeniu lub systemie operacyjnym ścieżka instalacji jest częścią produktu. Specyfikacja musi objąć każdą drogę:

• Decyzja zależy od modelu własności. Na urządzeniu firmowym właściciel urządzenia może ustawić DISALLOW_INSTALL_UNKNOWN_SOURCES albo wersję dla całego urządzenia, DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY (API 29), i wtedy użytkownik w ogóle nie włączy nieznanych źródeł. Na prywatnym telefonie z profilem służbowym ograniczenie obejmuje profil.
• Trzeba wiedzieć, czego ograniczenie nie obejmuje. Dokumentacja Androida mówi, że nie dotyczy instalacji uruchamianych przez zarejestrowane sklepy z aplikacjami ani instalacji samych tych sklepów, a adb nie jest nieznanym źródłem. Ostrzejsze ograniczenie, DISALLOW_INSTALL_UNKNOWN_SOURCES_INCLUDING_REGISTERED_APP_STORES, blokuje także zarejestrowane sklepy z aplikacjami; dokumentacja podaje, że dodano je w wersji 37.2, więc politykę trzeba przetestować na tych wersjach Androida, na których faktycznie działa flota.
• Trzeba zamknąć drogę przez kabel. Urządzenie z włączonym debugowaniem przyjmie aplikację z komputera. DISALLOW_DEBUGGING_FEATURES ustawione przez właściciela urządzenia wyłącza debugowanie, także przez USB.
• Własny sklep powinien być jedynym zarejestrowanym sklepem z aplikacjami. We własnym buildzie systemu trzeba zdecydować, który instalator może kończyć instalacje bez pytania, i trzymać tę listę w obrazie systemu, a nie w ustawieniu, które użytkownik może zmienić.
• Pakiety są sprawdzane przed publikacją. Backend sklepu przy wgrywaniu sprawdza nazwę pakietu, certyfikat podpisu, numer wersji i minimalne SDK, odrzuca to, co się nie zgadza, i prostymi słowami mówi wydawcy, dlaczego.
• Klucze podpisujące to infrastruktura produkcyjna. Jeśli klucz zginie albo wycieknie, żadnej nowej wersji nie da się wydać jako aktualizacji istniejącej aplikacji.
• Uprawnienia widać przed instalacją. Opis tego, do czego aplikacja będzie miała dostęp, napisany nietechnicznym językiem, pozwala użytkownikowi albo administratorowi podjąć decyzję, zanim plik APK trafi na urządzenie.
• Potrzebny jest spis aplikacji. Urządzenie raportuje zainstalowane aplikacje, ich wersje i to, który instalator je wgrał, więc konsola wychwyci aplikację, która nie przyszła z zatwierdzonego źródła.

W UE akt o rynkach cyfrowych (Digital Markets Act), rozporządzenie (UE) 2022/1925, stosuje się od 2 maja 2023 r. do dużych platform wyznaczonych jako strażnicy dostępu (gatekeepers). Komisja Europejska wyznaczyła pierwszych sześciu strażników 6 września 2023 r. i dała im sześć miesięcy na dostosowanie się, więc art. 6 ust. 4 wiąże ich od marca 2024 r. Art. 6 ust. 4 wymaga, żeby strażnik dostępu zezwalał na instalację i skuteczne używanie aplikacji i sklepów z aplikacjami osób trzecich w swoim systemie operacyjnym i umożliwiał to technicznie, a także pozwalał korzystać z nich inaczej niż przez własne usługi platformy. Strażnik może nadal stosować środki ściśle niezbędne i proporcjonalne, żeby chronić integralność sprzętu lub systemu operacyjnego, oraz ustawienia, które pomagają użytkownikom chronić bezpieczeństwo, jeśli należycie je uzasadni. Ten obowiązek ciąży na strażniku dostępu, a nie na firmie, która wypuszcza własne urządzenie albo zabezpiecza własną flotę.

Google dodaje do Androida osobną warstwę. Według przewodników o weryfikacji deweloperów Android wymaga, żeby wszystkie aplikacje instalowane na certyfikowanych urządzeniach z Androidem były zarejestrowane przez zweryfikowanych deweloperów, niezależnie od tego, skąd zostały pobrane. Sideloading nadal jest możliwy: aplikacje niezarejestrowanych deweloperów przechodzą zaawansowaną ścieżkę z dodatkowymi zabezpieczeniami, a praca z adb się nie zmienia. Kontrole ruszyły 30 września 2026 r. dla użytkowników w Brazylii, Indonezji, Singapurze i Tajlandii, a w 2027 r. Google planuje rozszerzyć je na cały świat i wszystkie aplikacje na certyfikowanych urządzeniach z Androidem.

Dla Raw Control zbudowaliśmy RAW Secure Phone, utwardzony system telefonu oparty na Androidzie, z własnym sklepem z aplikacjami RAW Store, w którym są tylko zatwierdzone aplikacje. W październiku 2021 r. poprawiliśmy komunikat wyświetlany, gdy RAW Store odrzucał importowaną aplikację zbudowaną na zbyt starym SDK. W listopadzie 2021 r. w warstwie systemowej RAW OS dodaliśmy blokadę instalacji z każdego źródła innego niż RAW Store. Zlecenie klienta obejmowało też instalację aplikacji spoza RAW Store po stronie Androida i tę część zrobiliśmy między grudniem 2021 r. a styczniem 2022 r.; klient zaakceptował ją w styczniu 2022 r.

Dla Mudity nasi inżynierowie pracują nad sklepem z aplikacjami dla telefonu Mudita Kompakt. W 2026 r. ta praca objęła dostęp do sklepu z poziomu urządzenia (ukończony w marcu), wgrywanie plików APK przez deweloperów (kwiecień), widok raportu skanera APK (czerwiec) oraz nietechniczne opisy uprawnień Androida (wrzesień). Systemu operacyjnego Mudity nie budowaliśmy.