andr.docx

(5) Stos programowy systemu operacyjnego Android. Mechanizmy zapewniające programiście dostęp do bibliotek natywnych.

Stos programowy = architektura systemu:

Android został zaprojektowany tak, aby był

bardziej odporny na błędy:
- jądro Linux, na którym w bezpieczny sposób wykonywane są aplikacje; dostarcza podstawowy system usług tj. ochrona, zarządzanie pamięcią, zarządzanie procesem, obsługa sieci itp.; służy także jako warstwa komunikacji między hardware a software.

- każda aplikacja działa w obrębie własnej maszyny wirtualnej Dalvik, zmniejsza to ryzyko awarii całego telefonu.

Warstwa wykonawcza = środowisko uruchomieniowe Androida (biblioteki natywne + Dalvik).

Warstwa kolejna, Libraries, biblioteki natywne (!), zawiera biblioteki systemowe zapewniające obsługę m. in. bazy danych SQLite; protokołu SSL; multimediów; grafiki 2D/3D... te biblioteki nie są samodzielnymi aplikacjami. Można je wykorzystać poprzez wywołanie w bardziej zaawansowanych programach.

Dalvik VM obsługuje pliki .dex, które zostają skonwertowane w trakcie kompilacji z tradycyjnych plików .class i .jar.

Pliki .dex są mniejsze i wydajniejsze od plików klas

Ponad bibliotekami natywnymi i środowiskiem uruchomieniowym znajdziemy warstwę szkieletu aplikacji (aplication framework).

Najważniejsze elementy szkieletu:

- menedżer aktywności (odpowiada za cykl życia aplikacji);

- dostawcy treści;

- menedżer zasobów (zasobami nazywamy wszystkie elementy znajdujące się w aplikacji które nie stanowią jej kodu);

- menedżer lokacji (telefon zna swoje położenie w przestrzeni);

- menedżer powiadomień.

Zewnętrznym programistom udostępniono te same narzędzia
jakich używają programiści systemowi. Każda aplikacja zarejestrowana w systemie może pełnić rolę usługodawcy
wobec wszystkich innych aplikacji.

Najwyższa warstwa przeznaczona jest dla zwykłych użytkowników.

??

Mechanizmy umożliwiające programiście korzystanie z bibliotek natywnych (C/C++):

Pisząc kod w programach typu Eclipse + narzędzia SDK,
można korzystać z bibliotek tj. OpenGL.

Należy do kodu programu dołączyć pakiet biblioteki, potem można korzystać z funkcji dostępnych w danej bibliotece.

(11) Definicja reguł dostępu dla poszczególnych procesów uruchamianych w maszynie wirtualnej Dalvik.

Każda aplikacja działa w obrębie własnej, zoptymalizowanej dla urządzeń mobilnych, wirtualnej maszyny Dalvik -> Sandbox.
Każda aplikacja działa jako inny użytkownik, posiadający własne, prywatne pliki, identyfikator oraz bezpieczne środowisko,
              w którym jest wykonywana dana aplikacja (stąd różne uprawnienia aplikacji).

Aplikacja = aktywność + linuksowy proces, w którym jest ona przechowywana.

?????????????????

Reguły dostępu  => kategorie, w jaki sposób będzie dany komponent uruchamiany: w AndroidManifest.xml
CATEGORY_DEFAULT;  CATEGORY_BROWSABLE;  CATEGORY_TAB;  CATEGORY_ALTERNATIVE; CATEGORY_SELECTED_ALTERNATIVE; CATEGORY_LAUNCHER; CATEGORY_HOME; CATEGORY_PREFERENCE;  CATEGORY_GADGET;  CATEGORY_EMBED.

Maszyna wirtualna Dalvik zajmuje bardzo mało w pamięci, a na urządzeniu może działać wiele jej egzemplarzy.

(13) Alokacja i dostęp do danych w obrębie maszyny wirtualnej Dalvik.

Aplikacja dysponuje swoimi własnymi zasobami, z których korzysta.

Aby uzyskać dostęp do wspólnych zasobów systemu, aplikacjie muszą rejestrować się i prosić o niezbędne uprawnienia.

Uprawnienia aplikacji zostają zarejestrowane w pliku AndroidManifest.xml.

Każda aplikacja zostaje uruchomiona w oddzielnym procesie systemu Linux.

Architektura sprzętowa nie dopuszcza zjawiska uzyskiwania dostępu do pamięci jednego procesu przez inny proces.

Dodatkowo każda aplikacja posiada własny odmienny identyfikator użytkownika.

Wszelkie pliki utworzone przez jedną aplikację nie mogą być odczytywane ani nadpisywane przez pozostałe programy.

Dostęp do określonych, najważniejszych operacji jest ograniczony - pozwolenie/uprawnienia dla aplikacji na korzystanie z takich operacji trzeba umieścić w pliku AndroidManifest.xml.

Kiedy aplikacja dysponuje takim pozwoleniem, wysyła intencję, którą system (jądro Linux, IPC - komunikacja między procesowa) przekazuje do odpowiedniego programu - ale to już nie jest w obrębie maszyny wirtualnej Dalvik.

?? Może też chodzi o identyfikatory zawarte w klasie R.java.

(1) Charakterystyka sposobów zarządzania zasobami systemu operacyjnego Android z poziomu interfejsu użytkownika

              oraz procesu dowolnej aplikacji systemowej w kontekście danych skompresowanych i nieskompresowanych.

Zasoby = dane, nie będące kodem (łańcuchy znaków, obrazy, pliki dźwiękowe, wideo), wymagane przez aplikację.

Przechowywane są w katalogu /res, czyli innym niż kod źródłowy.

Mogą być zasoby w formie: XML lub "surowe": obrazy, muzyka, ikony..

Rodzaje zasobów:

•zasoby string–napisy

•zasoby layout–układy graficzne

•zasoby color–kolory

•zasoby dimension–wymiary

•zasoby image–obrazy graficzne

•zasoby color-drawable–kolorowe obiekty do narysowania

•własne pliki XML(xml)

•własne pliki nieskompresowane (raw)

Pliki dodatkowe (assests) nie są traktowane, jako zasoby.

Dane skompresowane: skompilowane XML np. string.XML do formatu binarnego.
Dane nieskompresowane: XML jako "raw".

Takie pliki przechowujemy w katalogu res/raw -> plik otrzmuje id w R.java.

Podobne pliki w katalogu /assets - dodatki - katalog plików niekompilowanych -> plik nie otrzymuje id.

Kod aplikacji (warstwa logiki) jest odseparowany od zasobów (warstwa prezentacji). Separacja umożliwia modyfikację zasobów bez konieczności wprowadzania zmian w kodzie źródłowym aplikacji lub ponownej kompilacji. Użycie alternatywnych zestawów zasobów ułatwia również obsługę ekranów o różnych rozdzielczościach i lokalizację aplikacji (tworzenie wersji językowych). Dla każdego zasobu automatycznie generowany jest identyfikator. Identyfikatory tworzone są przez kompilator zasobów AAPT (Android AssetPackaging Tool) i przechowywane w automatycznie generowanej klasie R. Jakiekolwiek modyfikacje zasobów w plikach XML (katalog /resprojektu) powodują automatycznie odpowiednie zmiany i aktualizacje w klasie R (plik R.java).

Zasoby skompilowane wraz z kodem = .apk;   APK = Android Package, służy do instalacji aplikacji w systemie.

(6) Mechanizmy dostępu do zasobów skompresowanych systemu operacyjnego Android.

Zasób - ciąg znaków, bitmapa lub inna dowolna informacja niebędąca kodem i jest wymagana przez aplikację.

Zasoby są przechowywane w katalogu res, znajdującym się wewnątrz projektu.

Kompilator zasobów (aapt) przetwarza zasoby zgodnie z podfolderami, w których są one przechowywane

oraz zgodnie z formatem pliku.

Przykładowo: pliki PNG -> res/drawable; XML opisujące układ graficzny ekranu -> res/layout.

Kompilator kompresuje i pakuje zasoby, a następnie generuje klasę o nazwie R,

zawierającą identyfikatory, które następnie pełnią rolę odnośników do odpowiednich zasobów w programie.

W trakcie pisania programu mamy przed oczami kod XML, wtyczka Android wywołuje kompilator zasobów (aapt),
który przekształca język XML na skompresowany format binarny.

Oprócz zasobów danej aplikacji, można także korzystać z zasobów systemowych,

w ramach klas potomnych klasy android.R np. komunikaty o błędach.

(15) Optymalizacja aplikacji źródłowej systemu operacyjnego Android.

Urządzenia mobilne mają małą pamięć oraz moc obliczeniową dlatego ważne jest aby poprzez kod źródłowy optymalizować każdą z aplikacji.
Strukturę aplikacji można optymalizować np. poprzez:
- używanie plików .json;
- dostosowywanie rozmiarów wyświetlanych obrazów do docelowego ekranu (w miarę możliwości);

- układaj zasoby w odpowiednich folderach (pomaga to uporządkować dane i daje możliwość tworzenia przykładowo różnych wersji jezykowych).

(8) Plik apk i jego rola w optymalizacji procesu urządzenia typu handheld.

Urządzenia o ograniczonej ilości pamięci i mocy procesora:
.apk - format binarny aplikacji na Androida - mniejszy rozmiar i większa szybkość działania

Proces tłumaczenia i instalowanie aplikacji można schematycznie przedstawić następująco:

Translacja : Aplikacja.java => Aplikacja.class => Aplikacja.dex + zasoby => Aplikacja.apk

Instalacja : Aplikacja.apk + prawa dostępu => urządzenie

Jak widać efektem końcowym generowania kodu aplikacji w środowisku deweloperskim,

np. w Eclipse IDE jest plik o rozszerzeniu apk zawierający archiwum przeznaczone do wysłania użytkownikowi.

Skompilowany kod programów wraz z niezbędnymi zasobami scalany jest w plik pakietu o rozszerzeniu apk.
Pojedynczy plik .apk traktowany jest jak jedna aplikacja uruchamiana w odrębnym procesie.

(4) Cykl życia aplikacji systemu Android z uwzględnieniem roli zarządcy treści i intencji procesowych.

Cykl życia aplikacji związany jest z cyklem życia jego aktywności. W zależności od działań podejmowanych przez użytkownika (ukrywanie, przywracanie, zatrzymywanie, zamykanie okien aktywności), aktywność zmienia stan i automatycznie uruchamiana jest przez system odpowiednia metoda cyklu życia aktywności (cyklem zarządza system Android).

Na aplikację składają się co najmniej 1 aktywność oraz linuksowy proces w którym jest ona przechowywana. Każda aktywność (ekran interfejsu użytkownika) posiada własny cykl życia.

Program może się zn...