Elementy aplikacji
Android zapewnia platformę open source i środowisko aplikacji dla urządzeń mobilnych. Podstawowy system operacyjny oparty jest na jądrze Linux. Aplikacje na Androida są najczęściej pisane w języku programowania Java i uruchamiane na maszynie wirtualnej Dalvik. Jednak aplikacje można również pisać w kodzie natywnym. Aplikacje są instalowane z jednego pliku z rozszerzeniem .apk.
Główne bloki konstrukcyjne aplikacji na Androida to:
AndroidManifest.xml : plik AndroidManifest.xml to plik kontrolny, który informuje system, co należy zrobić ze wszystkimi składnikami najwyższego poziomu (w szczególności działaniami, usługami, odbiornikami emisji i dostawcami treści opisanymi poniżej) w aplikacji. Określa to również, jakie uprawnienia są wymagane.
Działania : działanie jest ogólnie kodem pojedynczego zadania skoncentrowanego na użytkowniku. Zwykle obejmuje wyświetlanie użytkownikowi interfejsu użytkownika, ale nie musi — niektóre działania nigdy nie wyświetlają interfejsu użytkownika. Zazwyczaj jednym z działań aplikacji jest punkt wejścia do aplikacji.
Usługi : Usługa to kod działający w tle. Może działać we własnym procesie lub w kontekście procesu innej aplikacji. Inne komponenty "wiążą się" z usługą i wywołują na niej metody poprzez zdalne wywołania procedur. Przykładem usługi jest odtwarzacz multimediów: nawet jeśli użytkownik opuści interfejs wyboru multimediów, prawdopodobnie nadal zamierza odtwarzać muzykę. Usługa utrzymuje muzykę nawet po zakończeniu interfejsu użytkownika.
Broadcast Receiver : BroadcastReceiver to obiekt, który jest tworzony, gdy mechanizm IPC znany jako intencja jest wystawiany przez system operacyjny lub inną aplikację. Aplikacja może na przykład zarejestrować odbiornik dla komunikatu o niskim stanie baterii i zmienić jego zachowanie w oparciu o te informacje.
Model uprawnień Androida: dostęp do chronionych interfejsów API
Wszystkie aplikacje w systemie Android działają w piaskownicy aplikacji . Domyślnie aplikacja na Androida ma dostęp tylko do ograniczonego zakresu zasobów systemowych. System zarządza dostępem aplikacji systemu Android do zasobów, które w przypadku niewłaściwego lub złośliwego użycia mogą negatywnie wpłynąć na wygodę użytkownika, sieć lub dane na urządzeniu.
Ograniczenia te są wdrażane w różnych formach. Niektóre możliwości są ograniczone przez celowy brak API do wrażliwej funkcjonalności (np. nie ma API Androida do bezpośredniej manipulacji kartą SIM). W niektórych przypadkach separacja ról zapewnia środek bezpieczeństwa, podobnie jak w przypadku izolacji pamięci masowej dla poszczególnych aplikacji. W innych przypadkach wrażliwe interfejsy API są przeznaczone do użytku przez zaufane aplikacje i są chronione przez mechanizm zabezpieczeń znany jako uprawnienia.
Te chronione interfejsy API obejmują:
- Funkcje aparatu
- Dane lokalizacji (GPS)
- Funkcje Bluetooth
- Funkcje telefoniczne
- Funkcje SMS/MMS
- Połączenia sieciowe/dane
Zasoby te są dostępne tylko za pośrednictwem systemu operacyjnego. Aby korzystać z chronionych interfejsów API na urządzeniu, aplikacja musi zdefiniować w swoim manifeście funkcje, których potrzebuje. Wszystkie wersje Androida 6.0 i nowsze korzystają z modelu uprawnień czasu wykonywania . Jeśli użytkownik zażąda funkcji z aplikacji, która wymaga chronionego interfejsu API, system wyświetli okno dialogowe z monitem o odmowę lub zezwolenie na dostęp.
Po przyznaniu uprawnienia są stosowane do aplikacji, o ile jest ona zainstalowana. Aby uniknąć zamieszania, system nie powiadamia użytkownika ponownie o uprawnieniach przyznanych aplikacji, a aplikacje zawarte w podstawowym systemie operacyjnym lub dołączone przez producenta OEM nie żądają uprawnień od użytkownika. Uprawnienia są usuwane po odinstalowaniu aplikacji, więc kolejna ponowna instalacja spowoduje ponowne wyświetlenie uprawnień.
W ustawieniach urządzenia użytkownicy mogą przeglądać uprawnienia aplikacji, które wcześniej zainstalowali. Użytkownicy mogą również wyłączyć niektóre funkcje globalnie, kiedy tylko zechcą, takie jak wyłączenie GPS, radia lub Wi-Fi.
W przypadku, gdy aplikacja próbuje użyć chronionej funkcji, która nie została zadeklarowana w manifeście aplikacji, niepowodzenie uprawnienia zwykle spowoduje odrzucenie wyjątku zabezpieczeń z powrotem do aplikacji. Kontrole uprawnień chronionego interfejsu API są egzekwowane na najniższym możliwym poziomie, aby zapobiec obchodzeniu. Przykład wiadomości użytkownika, gdy aplikacja jest instalowana podczas żądania dostępu do chronionych interfejsów API, pokazano na rysunku 2 .
Domyślne uprawnienia systemowe są opisane na https://developer.android.com/reference/android/Manifest.permission.html . Aplikacje mogą deklarować własne uprawnienia do korzystania z innych aplikacji. Takie uprawnienia nie są wymienione w powyższej lokalizacji.
Podczas definiowania uprawnienia atrybut protectionLevel informuje system, w jaki sposób użytkownik ma być informowany o aplikacjach wymagających uprawnienia lub kto może posiadać uprawnienia. Szczegóły dotyczące tworzenia i używania uprawnień specyficznych dla aplikacji są opisane na stronie https://developer.android.com/guide/topics/security/security.html .
Istnieją pewne możliwości urządzenia, takie jak możliwość wysyłania intencji rozgłaszania wiadomości SMS, które nie są dostępne dla aplikacji innych firm, ale mogą być używane przez aplikacje wstępnie zainstalowane przez producenta OEM. Te uprawnienia korzystają z uprawnienia signatureOrSystem.
Jak użytkownicy rozumieją aplikacje innych firm
Android stara się jasno informować użytkowników o interakcji z aplikacjami innych firm i informować użytkownika o możliwościach, jakie mają te aplikacje. Przed zainstalowaniem jakiejkolwiek aplikacji, użytkownikowi wyświetlany jest jasny komunikat o różnych uprawnieniach, o które prosi aplikacja. Po instalacji użytkownik nie jest ponownie proszony o potwierdzenie jakichkolwiek uprawnień.
Istnieje wiele powodów, aby pokazać uprawnienia bezpośrednio przed instalacją. Dzieje się tak, gdy użytkownik aktywnie przegląda informacje o aplikacji, deweloperze i funkcjonalności, aby określić, czy odpowiada to jego potrzebom i oczekiwaniom. Ważne jest również, aby nie podjęli jeszcze zobowiązania psychicznego lub finansowego do aplikacji i mogą łatwo porównać aplikację z innymi alternatywnymi aplikacjami.
Niektóre inne platformy stosują inne podejście do powiadamiania użytkowników, prosząc o pozwolenie na początku każdej sesji lub podczas używania aplikacji. Wizją Androida jest umożliwienie użytkownikom płynnego przełączania się między aplikacjami w dowolnym momencie. Dostarczanie potwierdzeń za każdym razem spowolniłoby działanie użytkownika i uniemożliwiłoby Androidowi zapewnianie doskonałej obsługi. Posiadanie uprawnień do przeglądania przez użytkownika w czasie instalacji daje użytkownikowi opcję, aby nie instalować aplikacji, jeśli czuje się niekomfortowo.
Ponadto wiele badań dotyczących interfejsu użytkownika wykazało, że nadmierne monitowanie użytkownika powoduje, że użytkownik zaczyna mówić „OK” w każdym wyświetlonym oknie dialogowym. Jednym z celów bezpieczeństwa Androida jest skuteczne przekazywanie użytkownikowi ważnych informacji o bezpieczeństwie, czego nie można zrobić za pomocą okien dialogowych, które użytkownik zostanie przeszkolony w ignorowaniu. Prezentując ważne informacje raz i tylko wtedy, gdy jest to ważne, użytkownik jest bardziej skłonny pomyśleć o tym, na co się zgadza.
Niektóre platformy decydują się nie wyświetlać w ogóle żadnych informacji o funkcjonalności aplikacji. Takie podejście uniemożliwia użytkownikom łatwe zrozumienie i omawianie możliwości aplikacji. Chociaż nie wszyscy użytkownicy mogą zawsze podejmować w pełni świadome decyzje, model uprawnień Androida sprawia, że informacje o aplikacjach są łatwo dostępne dla szerokiego grona użytkowników. Na przykład nieoczekiwane prośby o uprawnienia mogą skłonić bardziej zaawansowanych użytkowników do zadawania krytycznych pytań dotyczących funkcjonalności aplikacji i dzielenia się swoimi obawami w miejscach takich jak Google Play , gdzie są widoczne dla wszystkich użytkowników.
| Uprawnienia przy instalacji aplikacji — Mapy Google | Uprawnienia zainstalowanej aplikacji — Gmail |
 |  |
Rysunek 1. Wyświetlanie uprawnień dla aplikacji
Komunikacja międzyprocesowa
Procesy mogą komunikować się za pomocą dowolnego z tradycyjnych mechanizmów typu UNIX. Przykłady obejmują system plików, gniazda lokalne lub sygnały. Jednak nadal obowiązują uprawnienia systemu Linux.
Android udostępnia również nowe mechanizmy IPC:
Binder : lekki, oparty na możliwościach mechanizm zdalnego wywoływania procedur, zaprojektowany z myślą o wysokiej wydajności podczas wykonywania wywołań wewnątrzprocesowych i międzyprocesowych. Binder jest zaimplementowany przy użyciu niestandardowego sterownika Linux. Zobacz https://developer.android.com/reference/android/os/Binder.html .
Usługi : Usługi (omówione powyżej) mogą udostępniać interfejsy bezpośrednio dostępne za pomocą bindera.
Intents : Intent to prosty obiekt wiadomości, który reprezentuje „zamiar” zrobienia czegoś. Na przykład, jeśli aplikacja chce wyświetlić stronę internetową, wyraża swoją „Intencję”, aby wyświetlić adres URL, tworząc instancję Intent i przekazując ją do systemu. System lokalizuje inny fragment kodu (w tym przypadku przeglądarkę), który wie, jak obsłużyć tę intencję, i uruchamia go. Intencje mogą być również używane do transmitowania interesujących wydarzeń (takich jak powiadomienia) w całym systemie. Zobacz https://developer.android.com/reference/android/content/Intent.html .
ContentProviders : ContentProvider to magazyn danych, który zapewnia dostęp do danych na urządzeniu; klasycznym przykładem jest ContentProvider, który służy do uzyskiwania dostępu do listy kontaktów użytkownika. Aplikacja może uzyskiwać dostęp do danych, które inne aplikacje ujawniły za pośrednictwem ContentProvider, a aplikacja może również definiować własne ContentProvider, aby udostępniać własne dane. Zobacz https://developer.android.com/reference/android/content/ContentProvider.html .
Chociaż możliwe jest zaimplementowanie IPC przy użyciu innych mechanizmów, takich jak gniazda sieciowe lub pliki, które można zapisać na całym świecie, są to zalecane frameworki Android IPC. Programiści Androida będą zachęcani do stosowania najlepszych praktyk dotyczących zabezpieczania danych użytkowników i unikania wprowadzania luk w zabezpieczeniach.
Wrażliwe na koszty interfejsy API
Interfejs API uwzględniający koszty to dowolna funkcja, która może generować koszty dla użytkownika lub sieci. Platforma Android umieściła interfejsy API wrażliwe na koszty na liście chronionych interfejsów API kontrolowanych przez system operacyjny. Użytkownik będzie musiał udzielić wyraźnych uprawnień aplikacjom innych firm, które proszą o korzystanie z interfejsów API wrażliwych na koszty. Te interfejsy API obejmują:
- Telefonia
- SMS/MMS
- Sieć/Dane
- Rozliczenia w aplikacji
- Dostęp NFC
Android 4.2 dodaje dalszą kontrolę nad korzystaniem z SMS-ów. Android wyświetli powiadomienie, jeśli aplikacja spróbuje wysłać SMS na krótki kod, który korzysta z usług premium, co może spowodować dodatkowe opłaty. Użytkownik może wybrać, czy zezwolić aplikacji na wysyłanie wiadomości, czy ją zablokować.
Dostęp do karty SIM
Dostęp niskiego poziomu do karty SIM nie jest dostępny dla aplikacji innych firm. System operacyjny obsługuje całą komunikację z kartą SIM, w tym dostęp do informacji osobistych (kontaktów) w pamięci karty SIM. Aplikacje również nie mogą uzyskać dostępu do poleceń AT, ponieważ są one zarządzane wyłącznie przez warstwę interfejsu radiowego (RIL). RIL nie udostępnia interfejsów API wysokiego poziomu dla tych poleceń.
Informacje osobiste
Android umieścił interfejsy API, które zapewniają dostęp do danych użytkownika, w zestawie chronionych interfejsów API. Przy normalnym użytkowaniu urządzenia z systemem Android będą również gromadzić dane użytkownika w aplikacjach innych firm zainstalowanych przez użytkowników. Aplikacje, które zdecydują się udostępniać te informacje, mogą korzystać z kontroli uprawnień systemu operacyjnego Android, aby chronić dane przed aplikacjami innych firm.
Rysunek 2. Dostęp do poufnych danych użytkownika jest możliwy tylko za pośrednictwem chronionych interfejsów API
Dostawcy treści systemowych, którzy mogą zawierać dane osobowe lub informacje umożliwiające identyfikację, takie jak kontakty i kalendarz, zostali utworzono z jasno określonymi uprawnieniami. Ta szczegółowość zapewnia użytkownikowi jasne wskazanie rodzajów informacji, które mogą być dostarczane do aplikacji. Podczas instalacji aplikacja innej firmy może zażądać pozwolenia na dostęp do tych zasobów. Jeśli zezwolenie zostanie udzielone, aplikacja może zostać zainstalowana i będzie miała dostęp do żądanych danych w dowolnym momencie podczas instalacji.
Wszystkie aplikacje, które gromadzą dane osobowe, będą domyślnie ograniczać te dane tylko do konkretnej aplikacji. Jeśli aplikacja zdecyduje się udostępnić dane innym aplikacjom za pośrednictwem IPC, aplikacja udzielająca dostępu może zastosować uprawnienia do mechanizmu IPC, które są wymuszane przez system operacyjny.
Wrażliwe urządzenia do wprowadzania danych
Urządzenia z systemem Android często udostępniają wrażliwe urządzenia do wprowadzania danych, które umożliwiają aplikacjom interakcję z otaczającym środowiskiem, takim jak kamera, mikrofon lub GPS. Aby aplikacja innej firmy mogła uzyskać dostęp do tych urządzeń, użytkownik musi najpierw uzyskać jawny dostęp za pomocą uprawnień systemu operacyjnego Android. Podczas instalacji instalator poprosi użytkownika o pozwolenie na dostęp do czujnika według nazwy.
Jeśli aplikacja chce poznać lokalizację użytkownika, wymaga pozwolenia na dostęp do lokalizacji użytkownika. Podczas instalacji instalator wyświetli monit z pytaniem, czy aplikacja może uzyskać dostęp do lokalizacji użytkownika. W dowolnym momencie, jeśli użytkownik nie chce, aby jakakolwiek aplikacja miała dostęp do jego lokalizacji, może uruchomić aplikację „Ustawienia”, przejść do „Lokalizacja i zabezpieczenia” i odznaczyć „Użyj sieci bezprzewodowych” i „Włącz satelity GPS” . Spowoduje to wyłączenie usług opartych na lokalizacji dla wszystkich aplikacji na urządzeniu użytkownika.
Metadane urządzenia
Android dąży również do ograniczenia dostępu do danych, które nie są wewnętrznie wrażliwe, ale mogą pośrednio ujawniać cechy użytkownika, jego preferencje i sposób, w jaki korzysta z urządzenia.
Domyślnie aplikacje nie mają dostępu do dzienników systemu operacyjnego, historii przeglądarki, numeru telefonu ani informacji identyfikujących sprzęt/sieć. Jeśli aplikacja zażąda dostępu do tych informacji w czasie instalacji, instalator wyświetli monit z pytaniem, czy aplikacja może uzyskać dostęp do informacji. Jeśli użytkownik nie udzieli dostępu, aplikacja nie zostanie zainstalowana.
Urzędy certyfikacji
Android zawiera zestaw zainstalowanych systemowych urzędów certyfikacji, które są zaufane w całym systemie. Przed Androidem 7.0 producenci urządzeń mogli modyfikować zestaw urzędów certyfikacji dostarczonych na ich urządzeniach. Jednak urządzenia z systemem 7.0 i nowszymi będą miały jednolity zestaw systemowych urzędów certyfikacji, ponieważ modyfikacja przez producentów urządzeń nie jest już dozwolona.
Aby zostać dodanym jako nowy publiczny urząd certyfikacji do zestawu zasobów systemu Android, urząd certyfikacji musi ukończyć proces włączania urzędu certyfikacji Mozilla , a następnie złożyć żądanie funkcji w systemie Android ( https://code.google.com/p/android/issues/entry ) aby dodać CA do podstawowego zestawu CA systemu Android w projekcie Android Open Source Project (AOSP).
Nadal istnieją urzędy certyfikacji, które są specyficzne dla urządzenia i nie powinny być uwzględniane w podstawowym zestawie urzędów certyfikacji AOSP, na przykład prywatne urzędy certyfikacji przewoźników, które mogą być potrzebne do bezpiecznego dostępu do komponentów infrastruktury operatora, takich jak bramy SMS/MMS. Zachęca się producentów urządzeń do uwzględniania prywatnych urzędów certyfikacji tylko w składnikach/aplikacjach, które muszą ufać tym urzędom. Aby uzyskać więcej informacji, zobacz Konfiguracja zabezpieczeń sieci .
Podpisywanie aplikacji
Podpisywanie kodu pozwala programistom zidentyfikować autora aplikacji i zaktualizować swoją aplikację bez tworzenia skomplikowanych interfejsów i uprawnień. Każda aplikacja uruchomiona na platformie Android musi być podpisana przez dewelopera. Aplikacje, które próbują zainstalować bez podpisu, są odrzucane przez Google Play lub instalator pakietów na urządzeniu z Androidem.
W Google Play podpisywanie aplikacji łączy zaufanie firmy Google do programisty i zaufanie programisty do aplikacji. Deweloperzy wiedzą, że ich aplikacja jest dostarczana, niezmodyfikowana na urządzeniu z Androidem; a programiści mogą zostać pociągnięci do odpowiedzialności za zachowanie ich aplikacji.
W systemie Android podpisywanie aplikacji jest pierwszym krokiem do umieszczenia aplikacji w jej piaskownicy aplikacji. Podpisany certyfikat aplikacji określa, który identyfikator użytkownika jest powiązany z daną aplikacją; różne aplikacje działają pod różnymi identyfikatorami użytkowników. Podpisywanie aplikacji zapewnia, że jedna aplikacja nie może uzyskać dostępu do żadnej innej aplikacji, z wyjątkiem dobrze zdefiniowanego IPC.
Po zainstalowaniu aplikacji (pliku APK) na urządzeniu z systemem Android Menedżer pakietów weryfikuje, czy plik APK został prawidłowo podpisany za pomocą certyfikatu zawartego w tym pakiecie APK. Jeśli certyfikat (a dokładniej klucz publiczny w certyfikacie) jest zgodny z kluczem używanym do podpisywania dowolnego innego pakietu APK na urządzeniu, nowy pakiet APK ma możliwość określenia w manifeście, że podobnie będzie współdzielił identyfikator UID z innym pakietem -podpisane pliki APK.
Wnioski mogą być podpisane przez stronę trzecią (OEM, operator, rynek alternatywny) lub samodzielnie. Android zapewnia podpisywanie kodu przy użyciu certyfikatów z podpisem własnym, które programiści mogą generować bez pomocy lub pozwolenia z zewnątrz. Wnioski nie muszą być podpisane przez organ centralny. Android obecnie nie przeprowadza weryfikacji CA dla certyfikatów aplikacji.
Aplikacje mogą również deklarować uprawnienia bezpieczeństwa na poziomie ochrony podpisu, ograniczając dostęp tylko do aplikacji podpisanych tym samym kluczem przy jednoczesnym zachowaniu odrębnych identyfikatorów UID i piaskownic aplikacji. Bliższe relacje z udostępnioną piaskownicą aplikacji są dozwolone za pośrednictwem funkcji udostępnionego identyfikatora UID, w której co najmniej dwie aplikacje podpisane przy użyciu tego samego klucza programisty mogą zadeklarować wspólny identyfikator UID w swoim manifeście.
Weryfikacja aplikacji
Android 4.2 i nowsze obsługują weryfikację aplikacji. Użytkownicy mogą włączyć opcję „Zweryfikuj aplikacje” i zlecić ocenę aplikacji przez weryfikatora aplikacji przed instalacją. Weryfikacja aplikacji może ostrzec użytkownika, jeśli spróbuje zainstalować aplikację, która może być szkodliwa; jeśli aplikacja jest szczególnie zła, może zablokować instalację .
Zarządzanie Prawami Cyfrowymi
Platforma Android zapewnia rozszerzalną strukturę DRM, która umożliwia aplikacjom zarządzanie zawartością chronioną prawami zgodnie z ograniczeniami licencji skojarzonymi z zawartością. Struktura DRM obsługuje wiele schematów DRM; jakie schematy DRM obsługuje urządzenie, pozostawia się producentowi urządzenia.
Platforma Android DRM jest zaimplementowana w dwóch warstwach architektonicznych (patrz rysunek poniżej):
Interfejs API platformy DRM, który jest udostępniany aplikacjom za pośrednictwem platformy aplikacji Android i działa przez maszynę wirtualną Dalvik w przypadku standardowych aplikacji.
Natywny menedżer DRM z kodem, który implementuje strukturę DRM i udostępnia interfejs dla wtyczek DRM (agentów) do obsługi zarządzania prawami i odszyfrowywania dla różnych schematów DRM
Rysunek 3. Architektura zarządzania prawami cyfrowymi na platformie Android