VirtualizationService zarządza wszystkimi maszynami wirtualnymi gości, chronionymi lub w inny sposób, działającymi w systemie Android, głównie przez zarządzanie wystąpieniami crosvm. VirtualizationService udostępnia interfejs API AIDL, którego usługi systemowe lub aplikacje mogą używać do uruchamiania, monitorowania i zatrzymywania maszyn wirtualnych.
AIDL API
VirtualizationService udostępnia interfejs API AIDL, którego klienci mogą używać do dostarczania obrazów i uruchamiania maszyny wirtualnej. Ten opis może być albo surową konfiguracją maszyny wirtualnej z deskryptorami plików dla bootloadera lub jądra i różnymi obrazami dysków do włączenia do maszyny wirtualnej, albo konfiguracją Microdroid, w której klient po prostu dostarcza ładunek, a maszyna wirtualna jest uruchamiana ze standardowym jądrem i infrastrukturą Microdroid . VirtualizationService następnie zwraca obiekt IVirtualMachine Binder, który reprezentuje maszynę wirtualną. Klient, który uruchomił maszynę wirtualną, może udostępnić obiekt Binder innym procesom, korzystając ze zwykłych mechanizmów Binder.
IVirtualMachine ma metody AIDL do uzyskiwania informacji o maszynie wirtualnej, takie jak CID, które mogą być używane do komunikowania się z nią przez vsock, a także umożliwia zarejestrowanie wywołania zwrotnego w celu wywołania, gdy maszyna wirtualna się zatrzyma. W przypadku maszyn wirtualnych IVirtualMachine obiekt IVirtualMachine może być również użyty do skonfigurowania połączeń Bindera z maszyną wirtualną.
Cykl życia maszyny wirtualnej
Dostęp do maszyny wirtualnej jest śledzony przez obiekt IVirtualMachine . Dopóki istnieje co najmniej jedno odwołanie do obiektu IVirtualMachine , maszyna wirtualna kontynuuje działanie (chyba że ulegnie awarii lub wyłączy się z własnej woli). Jeśli wszystkie odwołania do obiektu IVirtualMachine zostaną usunięte przed zamknięciem maszyny wirtualnej, usługa VirtualizationService automatycznie zamknie maszynę wirtualną. Ten proces oznacza, że jeśli klient, który uruchomił maszynę wirtualną, zostanie zamknięty przez zabójcę małej ilości pamięci, maszyna wirtualna również zostanie zamknięta, zapobiegając w ten sposób wyciekom zasobów.
Każda maszyna wirtualna jest zarządzana przez własną instancję crosvm, którą z kolei zarządza VirtualizationService w imieniu klienta. VirtualizationService uruchamia te procesy podrzędne crosvm zgodnie z wymaganiami i przekazuje im deskryptory plików dla obrazów, których potrzebuje maszyna wirtualna. VirtualizationService następnie monitoruje proces podrzędny pod kątem śmierci, dzięki czemu może odpowiednio powiadomić pozostałych klientów.
Pakowanie maszyn wirtualnych
crosvm obsługuje dwa różne sposoby uruchamiania maszyny wirtualnej: dostarczane jest jądro i initrd lub udostępniany jest program ładujący. W obu przypadkach można również dostarczyć dowolną liczbę obrazów dysków, która może być albo obrazem nieprzetworzonym, albo złożeniem kilku partycji. Różne obrazy są dostarczane przez klienta jako deskryptory plików.
VirtualizationService tworzy złożone obrazy dysków na żądanie. Ten proces jest konieczny, ponieważ kompozytowy plik dysku odwołuje się wewnętrznie do różnych plików obrazu partycji tworzących dysk, które są przekazywane przez klienta i mogą nie być bezpośrednio dostępne przez crosvm. Aby obejść ten problem, VirtualizationService zapewnia, że numery deskryptorów plików odziedziczone przez crosvm są takie same, jak numery deskryptorów plików, których VirtualizationService używał do tworzenia obrazów złożonych. Złożony obraz dysku używa nazw plików w postaci /proc/self/fd/N do reprezentowania każdego pliku partycji.
W przypadku Microdroid pVM, AVF zawiera bootloader, który ładuje jądro z partycji złożonego obrazu dysku, zgodnie ze standardowym przepływem Android Verified Boot.
Gniazda maszyn wirtualnych (vsock)
Podstawowym interfejsem do komunikacji między pVM jest vsock, standardowy interfejs gniazda virtio. Każda maszyna wirtualna jest identyfikowana przez 32-bitowy identyfikator kontekstu (CID), który jest analogiczny do adresu IP, który VirtualizationService przypisuje do maszyny wirtualnej podczas tworzenia maszyny wirtualnej i może uwidaczniać usługi na dowolnym numerze portu wybranym przez maszynę wirtualną. Identyfikator CID jest unikatowy, gdy maszyna wirtualna jest uruchomiona, ale wartość identyfikatora CID można przywrócić, gdy maszyna wirtualna zostanie zakończona i wszystkie uchwyty IVirtualMachine Binder do maszyny wirtualnej zostały usunięte.
Interfejs debugowania
Polecenie vm służy do debugowania. To polecenie umożliwia programiście uruchomienie maszyny wirtualnej z powłoki, wyświetlenie jej dzienników i zakończenie działania maszyny wirtualnej. Polecenie vm zawiera również opcję wyświetlenia aktualnie uruchomionych maszyn wirtualnych, w tym ich statusów i powiązanych procesów. Ta opcja jest zaimplementowana jako dodatkowa metoda w API VirtualizationService AIDL, która, aby uniknąć nadużyć, może być wywoływana tylko przez użytkownika powłoki.
AVF obejmuje również obsługę przekazywania połączenia adb przez vsock, aby zapewnić dostęp adb do maszyn wirtualnych gości. Na przykład dla maszyny wirtualnej Microdroid z CID 10 z uruchomionym adbd na porcie 5555 programista może pobrać powłokę w maszynie wirtualnej Microdroid ze swojej stacji roboczej za pomocą następujących poleceń:
$ adb forward tcp:8000 vsock:10:5555
$ adb connect localhost:8000
$ adb -s localhost:8000 shell
Przekazywanie połączenia adb przez vsock jest dostępne tylko dla maszyn wirtualnych działających w trybie debugowania.