Elementy aplikacji
Android to platforma open source i środowisko aplikacji dla urządzeń mobilnych. Główny system operacyjny jest oparty na jądrze Linuksa. Aplikacje na Androida są najczęściej tworzone w języku programowania Java i uruchamiane w maszynie wirtualnej Android Runtime (ART). Aplikacje mogą być jednak też napisane w kodzie natywnym. Aplikacje są instalowane z pojedynczego pliku o rozszerzeniu APK.
Główne elementy składowe aplikacji na Androida to:
-
AndroidManifest.xml: plik AndroidManifest.xml to plik kontrolny, który informuje system, co zrobić ze wszystkimi komponentami najwyższego poziomu (w szczególności z aktywnościami, usługami, odbiornikami transmisji i dostawcami treści opisanymi poniżej) w aplikacji. Określa on też, które uprawnienia są wymagane.
-
Czynności: czynność to zazwyczaj kod pojedynczego zadania skierowanego do użytkownika, które korzysta z klasy
Activity. Aktywność zwykle obejmuje wyświetlenie interfejsu użytkownika, ale nie musi tak być. Niektóre aktywności nigdy nie wyświetlają interfejsu. Zazwyczaj jedna z aktywności w aplikacji jest punktem wejścia do niej. -
Usługi: usługa to fragment kodu działający w tle. Może działać w ramach własnego procesu lub w kontekście procesu innej aplikacji. Inne komponenty „wiążą się” z usługą i wywołują w niej metody za pomocą zdalnych wywołań procedur. Przykładem usługi jest odtwarzacz multimediów: nawet gdy użytkownik zamknie interfejs wyboru multimediów, nadal będzie chciał odtwarzać muzykę. Usługa umożliwia kontynuowanie odtwarzania muzyki nawet po zakończeniu działania interfejsu.
-
Broadcast Receiver: BroadcastReceiver to obiekt tworzony w ramach mechanizmu IPC, zwany Intent, który jest wydawany przez system operacyjny lub inną aplikację. Aplikacja może zarejestrować odbiornik na potrzeby wiadomości o niskim stanie baterii i zmienić swoje zachowanie na podstawie tych informacji.
Model uprawnień na Androidzie: dostęp do chronionych interfejsów API
Wszystkie aplikacje na Androida działają w piaskownicy aplikacji. Domyślnie aplikacja na Androida ma dostęp tylko do ograniczonej liczby zasobów systemowych. System zarządza dostępem aplikacji na Androida do zasobów, które w przypadku niewłaściwego lub złośliwego użycia mogą negatywnie wpłynąć na komfort użytkownika, sieć lub dane na urządzeniu.
Te ograniczenia są wdrażane na wiele różnych sposobów. Niektóre możliwości są ograniczone przez celowy brak interfejsów API do funkcji wrażliwych (np. nie ma interfejsu API Androida do bezpośredniego manipulowania kartą SIM). W niektórych przypadkach rozdzielenie ról stanowi zabezpieczenie, podobnie jak izolowanie pamięci w poszczególnych aplikacjach. W innych przypadkach interfejsy API do obsługi danych wrażliwych są przeznaczone do użytku przez zaufane aplikacje i chronione za pomocą mechanizmu bezpieczeństwa znanego jako uprawnienia.
Do chronionych interfejsów API należą:
- Funkcje aparatu
- Dane o lokalizacji (GPS)
- Funkcje Bluetooth
- Funkcje telefoniczne
- Funkcje SMS-ów/MMS-ów
- Połączenia sieciowe/danych
Te zasoby są dostępne tylko w systemie operacyjnym. Aby móc korzystać z chronionych interfejsów API na urządzeniu, aplikacja musi określić w swoim pliku manifestu funkcje, których potrzebuje. Wszystkie wersje Androida 6.0 lub nowsze korzystają z modelu uprawnień w czasie wykonywania aplikacji. Jeśli użytkownik poprosi o funkcję w aplikacji, która wymaga interfejsu Protected Audience API, system wyświetli okno z prośbą o odrzucenie lub zezwolenie na dostęp.
Po przyznaniu uprawnienia są stosowane do aplikacji przez cały czas jej instalacji. Aby uniknąć dezorientacji użytkowników, system nie informuje ich ponownie o uprawnieniach przyznanych aplikacji. Aplikacje zawarte w głównym systemie operacyjnym lub w pakiecie OEM nie wymagają od użytkownika przyznania uprawnień. Uprawnienia są usuwane, jeśli aplikacja zostanie odinstalowana, więc ponowna instalacja spowoduje wyświetlenie uprawnień.
W ustawieniach urządzenia użytkownicy mogą wyświetlać uprawnienia aplikacji, które wcześniej zainstalowali. Użytkownicy mogą też wyłączyć niektóre funkcje globalnie, np. GPS, radio czy Wi-Fi.
Jeśli aplikacja próbuje użyć funkcji chronionej, która nie została zadeklarowana w manifeście, błąd uprawnień powoduje zwykle wyjątek bezpieczeństwa zwracany do aplikacji. Sprawdzanie uprawnień chronionych interfejsów API jest wymuszane na najniższym możliwym poziomie, aby zapobiec obchodzeniu zabezpieczeń. Rysunek 2 przedstawia przykład wiadomości wyświetlanej użytkownikowi, gdy aplikacja jest instalowana podczas żądania dostępu do chronionych interfejsów API.
Domyślne uprawnienia systemu są opisane na stronie https://developer.android.com/reference/android/Manifest.permission.html. Aplikacje mogą deklarować własne uprawnienia, z których mogą korzystać inne aplikacje. Takie uprawnienia nie są wymienione w wymienionej wyżej lokalizacji.
Podczas definiowania uprawnienia atrybut protectionLevel informuje system, jak użytkownik ma być informowany o aplikacjach wymagających tego uprawnienia lub kto może je przyznać. Szczegółowe informacje o tworzeniu i używaniu określonych uprawnień aplikacji znajdziesz na stronie https://developer.android.com/guide/topics/security/security.html.
Niektóre funkcje urządzenia, takie jak możliwość wysyłania SMS-ów z rozgłoszeniem, 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, kiedy wchodzą w interakcje z aplikacjami innych firm, oraz o ich możliwościach. Przed zainstalowaniem aplikacji użytkownik widzi jasny komunikat o różnych uprawnieniach, o które prosi aplikacja. Po zainstalowaniu aplikacji użytkownik nie będzie musiał ponownie potwierdzać żadnych uprawnień.
Istnieje wiele powodów, dla których warto wyświetlać uprawnienia bezpośrednio przed instalacją. W tym przypadku użytkownik aktywnie sprawdza informacje o aplikacji, deweloperze i funkcjach, aby określić, czy spełnia ona jego potrzeby i oczekiwania. Ważne jest też to, że użytkownicy nie są jeszcze związani z aplikacją ani finansowo, ani emocjonalnie i mogą ją łatwo porównać z innymi aplikacjami.
Niektóre inne platformy stosują inne podejście do powiadomień dla użytkowników, prosząc o pozwolenie na początku każdej sesji lub podczas korzystania z aplikacji. Wizja Androida zakłada, że użytkownicy mogą płynnie przełączać się między aplikacjami. Wyświetlanie potwierdzenia za każdym razem spowolniłoby działanie urządzenia i uniemożliwiłoby Androidowi zapewnienie użytkownikom wygodnej obsługi. Wyświetlanie użytkownikowi uprawnień w momencie instalacji daje mu możliwość odmowy zainstalowania aplikacji, jeśli nie czuje się z tym komfortowo.
Wiele badań interfejsu użytkownika wykazało też, że nadmierne wyświetlanie użytkownikowi promptów powoduje, że zaczyna on reagować na każdy wyświetlany dialog kliknięciem „OK”. Jednym z celów Androida jest skuteczne przekazywanie użytkownikom ważnych informacji o zabezpieczeniach. Nie można tego zrobić za pomocą okien dialogowych, które użytkownik będzie ignorować. Wyświetlanie ważnych informacji tylko raz i tylko wtedy, gdy jest to konieczne, zwiększa prawdopodobieństwo, że użytkownik zastanowi się nad tym, na co się zgadza.
Niektóre platformy w ogóle nie wyświetlają żadnych informacji o funkcjach aplikacji. Takie podejście utrudnia użytkownikom zrozumienie i omówienie możliwości aplikacji. Nie wszyscy użytkownicy mogą podejmować świadome decyzje, ale dzięki modelom uprawnień w Androidzie 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 ważnych pytań o funkcje aplikacji i wyrażania wątpliwości w miejscach takich jak Google Play, gdzie są one widoczne dla wszystkich użytkowników.
| Uprawnienia podczas instalowania aplikacji – Tłumacz Google | Uprawnienia zainstalowanej aplikacji – Gmail |
|---|---|
 |
 |
Rysunek 1. Wyświetlanie uprawnień aplikacji
Komunikacja między procesami
Procesy mogą się komunikować za pomocą dowolnego tradycyjnego mechanizmu typu UNIX. Przykłady to system plików, gniazda lokalne lub sygnały. Uprawnienia systemu Linux nadal obowiązują.
Android udostępnia też nowe mechanizmy IPC:
-
Binder: lekki mechanizm wywoływania procedur zdalnych oparty na uprawnieniach, zaprojektowany pod kątem wysokiej wydajności podczas wykonywania wywołań w ramach procesu i między procesami. Binder jest implementowany przy użyciu niestandardowego sterownika Linuksa. Więcej informacji znajdziesz na stronie https://developer.android.com/reference/android/os/Binder.html.
-
Usługi: usługi (omówione powyżej) mogą udostępniać interfejsy bezpośrednio za pomocą bindera.
-
Intencje: intencja to prosty obiekt wiadomości, który reprezentuje „intencję” wykonania jakiejś czynności. Jeśli np. aplikacja chce wyświetlić stronę internetową, wyraża swoją „intencję” wyświetlenia adresu URL, tworząc instancję intencji i przekazując ją do systemu. System wyszukuje inny fragment kodu (w tym przypadku przeglądarkę), który wie, jak obsłużyć ten zamiar, i go wykonuje. Intencje mogą też służyć do rozpowszechniania interesujących zdarzeń (np. powiadomień) w całym systemie. Patrz https://developer.android.com/reference/android/content/Intent.html.
-
ContentProvider: 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 udostępnionych przez inne aplikacje za pomocą ContentProvider. Może też definiować własne komponenty ContentProvider, aby udostępniać własne dane. Patrz https://developer.android.com/reference/android/content/ContentProvider.html.
Interfejs IPC można zaimplementować za pomocą innych mechanizmów, takich jak gniazda sieciowe lub pliki do zapisu dla wszystkich użytkowników, ale te ramki są zalecane w przypadku interfejsu IPC na Androidzie. Zachęcimy deweloperów Androida do stosowania sprawdzonych metod zabezpieczania danych użytkowników i zapobiegania wprowadzaniu luk w zabezpieczeniach.
Interfejsy API uwzględniające koszty
Interfejs API wrażliwy na koszty to każda funkcja, która może generować koszty dla użytkownika lub sieci. Na platformie Android interfejsy API wrażliwe na koszty zostały umieszczone na liście interfejsów chronionych kontrolowanych przez system operacyjny. Użytkownik będzie musiał wyraźnie zezwolić aplikacjom innych firm na korzystanie z interfejsów API z dostępem do informacji o kosztach. Te interfejsy API to:
- Połączenia telefoniczne
- SMS/MMS
- Sieć/Dane
- Rozliczenia w aplikacji
- Dostęp do NFC
Android 4.2 zapewnia dodatkowe możliwości zarządzania SMS-ami. Android wyświetli powiadomienie, jeśli aplikacja spróbuje wysłać SMS-a na krótki numer, który korzysta z usług premium, które mogą powodować dodatkowe opłaty. Użytkownik może zezwolić aplikacji na wysłanie wiadomości lub ją zablokować.
Dostęp do karty SIM
Dostęp na niskim poziomie do karty SIM nie jest dostępny dla aplikacji innych firm. System operacyjny zarządza całą komunikacją z kartą SIM, w tym dostępem do informacji osobistych (kontaktów) na karcie SIM. Aplikacje nie mają też dostępu do poleceń AT, ponieważ są one zarządzane wyłącznie przez warstwę interfejsu radiowego (RIL). Interfejs RIL nie udostępnia interfejsów API wysokiego poziomu dla tych poleceń.
Dane osobowe
Interfejsy API, które zapewniają dostęp do danych użytkownika, zostały umieszczone przez Androida w zbiorze chronionych interfejsów API. Podczas normalnego użytkowania urządzenia z Androidem gromadzą też dane użytkowników w aplikacjach innych firm zainstalowanych przez użytkowników. Aplikacje, które chcą udostępniać te informacje, mogą korzystać z systemowych kontroli uprawnień Androida, aby chronić dane przed aplikacjami innych firm.
Rysunek 2. Dostęp do poufnych danych użytkownika jest możliwy tylko za pomocą chronionych interfejsów API.
Dostawcy treści systemowych, które mogą zawierać informacje umożliwiające identyfikację, takie jak kontakty czy kalendarz, zostali utworzeni z jasno określonymi uprawnieniami. Ta szczegółowość daje użytkownikowi jasne wskazanie typów informacji, które mogą być udostępniane aplikacji. Podczas instalacji aplikacja innej firmy może poprosić o dostęp do tych zasobów. Jeśli użytkownik udzieli zgody, aplikacja może zostać zainstalowana i będzie mieć dostęp do żądanych danych w dowolnym momencie, gdy jest zainstalowana.
Wszystkie aplikacje, które zbierają dane osobowe, będą domyślnie miały te dane ograniczone tylko do tej konkretnej aplikacji. Jeśli aplikacja zdecyduje się udostępnić dane innym aplikacjom za pomocą interfejsu IPC, aplikacja przyznająca dostęp może zastosować uprawnienia do mechanizmu IPC, które są egzekwowane przez system operacyjny.
Urządzenia do wprowadzania danych wrażliwych
Urządzenia z Androidem często mają urządzenia do wprowadzania danych wrażliwych, które umożliwiają aplikacjom interakcję z otoczeniem, np. aparat, mikrofon czy GPS. Aby aplikacja innej firmy mogła uzyskać dostęp do tych urządzeń, użytkownik musi najpierw wyraźnie zezwolić na to za pomocą uprawnień systemu operacyjnego Android. Podczas instalacji instalator poprosi użytkownika o pozwolenie na dostęp do czujnika.
Jeśli aplikacja chce znać lokalizację użytkownika, musi mieć do niej dostęp. Podczas instalacji instalator poprosi użytkownika o pozwolenie na dostęp do lokalizacji. W każdej chwili, jeśli użytkownik nie chce, aby aplikacja miała dostęp do jego lokalizacji, może otworzyć aplikację „Ustawienia”, przejść do sekcji „Lokalizacja i bezpieczeństwo” i odznaczyć opcje „Używaj sieci bezprzewodowych” i „Włącz satelity GPS”. Spowoduje to wyłączenie usług opartych na lokalizacji we wszystkich aplikacjach na urządzeniu użytkownika.
Metadane urządzenia
Android stara się też ograniczać dostęp do danych, które nie są w samym sobie poufne, ale mogą pośrednio ujawniać informacje o użytkowniku, jego preferencjach i sposobie korzystania z urządzenia.
Domyślnie aplikacje nie mają dostępu do dzienników systemu operacyjnego, historii przeglądarki, numeru telefonu ani informacji o sprzęcie lub identyfikacji sieci. Jeśli aplikacja poprosi o dostęp do tych informacji podczas instalacji, instalator wyświetli użytkownikowi pytanie, czy aplikacja może uzyskać dostęp do tych informacji. Jeśli użytkownik nie przyzna dostępu, aplikacja nie zostanie zainstalowana.
Urzędy certyfikacji
Android zawiera zestaw zainstalowanych urzędów certyfikacji, które są zaufane w całym systemie. Przed Androidem 7.0 producenci urządzeń mogli modyfikować zestaw certyfikatów CA dostarczanych na urządzeniach. Urządzenia z Androidem 7.0 lub nowszym będą jednak mieć jednolity zestaw certyfikatów CA systemu, ponieważ modyfikacje przez producentów urządzeń nie są już dozwolone.
Aby dodać nowy publiczny zestaw CA do domyślnego zestawu CA Androida, CA musi przejść proces uwzględniania CA w Mozilla, a następnie przesłać prośbę o dodanie funkcji do Androida ( https://code.google.com/p/android/issues/entry), aby dodać CA do domyślnego zestawu CA Androida w Projekcie Android Open Source (AOSP).
Nadal istnieją urzędy certyfikacji, które są powiązane z poszczególnymi urządzeniami i nie powinny być uwzględniane w podstawowym zestawie urzędów certyfikacji AOSP, np. prywatne urzędy certyfikacji operatorów, które mogą być potrzebne do bezpiecznego uzyskiwania dostępu do elementów infrastruktury operatora, takich jak bramki SMS/MMS. Producentów urządzeń zachęcamy do uwzględniania prywatnych certyfikatów CA tylko w komponentach lub aplikacjach, które muszą im ufać. Więcej informacji znajdziesz w artykule Konfigurowanie zabezpieczeń sieci.
Podpisywanie aplikacji
Podpisywanie kodu pozwala deweloperom zidentyfikować autora aplikacji i zaktualizować ją bez tworzenia skomplikowanych interfejsów i uprawnień. Każda aplikacja działająca na platformie Android musi być podpisana przez dewelopera. Aplikacje, które próbują się zainstalować bez podpisu, są odrzucane przez Google Play lub instalator pakietu na urządzeniu z Androidem.
W Google Play podpisywanie aplikacji umożliwia Google zaufanie deweloperowi i zaufanie dewelopera swojej aplikacji. Deweloperzy wiedzą, że ich aplikacja jest dostarczana na urządzenie z Androidem bez zmian, a deweloperzy mogą być odpowiedzialni za działanie aplikacji.
Na Androidzie podpisanie aplikacji jest pierwszym krokiem do umieszczenia aplikacji w jej piaskownicy. Podpisany certyfikat aplikacji określa, który identyfikator użytkownika jest powiązany z którą aplikacją. Różne aplikacje działają pod różnymi identyfikatorami użytkownika. Podpisywanie aplikacji zapewnia, że jedna aplikacja nie może uzyskać dostępu do żadnej innej aplikacji inaczej niż przez dobrze zdefiniowane IPC.
Gdy aplikacja (plik APK) zostanie zainstalowana na urządzeniu z Androidem, menedżer pakietów sprawdzi, czy plik APK został prawidłowo podpisany certyfikatem zawartym w tym pliku. Jeśli certyfikat (lub dokładniej klucz publiczny w certyfikacie) pasuje do klucza użytego do podpisania dowolnego innego pliku APK na urządzeniu, nowy plik APK może w pliku manifestu określić, że będzie udostępniać identyfikator UID z innymi podpisanymi w podobny sposób plikami APK.
Aplikacje mogą być podpisane przez firmę zewnętrzną (OEM, operatora, alternatywny rynek) lub przez siebie. Android umożliwia podpisywanie kodu za pomocą samodzielnie podpisanych certyfikatów, które programiści mogą generować bez pomocy zewnętrznej lub zgody. Aplikacje nie muszą być podpisane przez urząd centralny. Android obecnie nie weryfikuje urzędu certyfikacji w przypadku certyfikatów aplikacji.
Aplikacje mogą też deklarować uprawnienia zabezpieczające na poziomie ochrony podpisem, ograniczając dostęp tylko do aplikacji podpisanych tym samym kluczem, przy zachowaniu odrębnych identyfikatorów UID i piaskownic aplikacji. Współdzielenie piaskownicy aplikacji jest możliwe dzięki funkcji współdzielonego identyfikatora UID, która umożliwia 2 lub większej liczbie aplikacji podpisanych tym samym kluczem dewelopera zadeklarowanie współdzielonego identyfikatora UID w manifeście.
Weryfikowanie aplikacji
Android 4.2 i nowsze obsługują weryfikację aplikacji. Użytkownicy mogą włączyć „Weryfikację aplikacji” i poprosić o weryfikację 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 niebezpieczna, może zostać zablokowana.
Zarządzanie prawami cyfrowymi
Platforma Android zapewnia rozszerzalne środowisko zarządzania prawami cyfrowymi (DRM), które umożliwia aplikacjom zarządzanie treściami chronionymi prawami zgodnie z ograniczeniami licencji powiązanymi z tymi treściami. Platforma DRM obsługuje wiele schematów DRM. Producent urządzenia decyduje, które z nich są obsługiwane.
Ramka DRM Androida jest wdrażana na 2 poziomach architektury (patrz rysunek poniżej):
-
interfejs API mechanizmu DRM, który jest udostępniany aplikacjom za pomocą mechanizmu aplikacji Androida i działa przez maszynę wirtualną ART w przypadku standardowych aplikacji;
-
Menedżer DRM w kodzie natywnym, który implementuje ramy DRM i wyświetla interfejs dla wtyczek DRM (agentów) do zarządzania prawami i odszyfrowywania w różnych schematach DRM.
Rysunek 3. Architektura DRM na platformie Android