Bionic (oprogramowanie) - Bionic (software)

Bioniczny
Deweloper(zy) Sojusz otwartych słuchawek
Pierwsze wydanie 23 września 2008 ; 12 lat temu ( 2008-09-23 )
Magazyn
System operacyjny Android
Platforma RAMIĘ , ARM64 , x86 , x86-64
Rodzaj Biblioteka standardowa C
Licencja Trzy klauzula licencja BSD
Strona internetowa programista .android .com Edytuj to na Wikidanych

Bionic to implementacja standardowej biblioteki C , opracowana przez Google dla systemu operacyjnego Android . Różni się od biblioteki GNU C (glibc) tym, że jest przeznaczony dla urządzeń z mniejszą ilością pamięci i mocy procesora niż typowy system Linux . Opiera się na kodzie OpenBSD wydanym na licencji BSD , a nie na glibc, która używa GNU Lesser General Public License . Ta różnica była ważna we wczesnych dniach Androida, kiedy statyczne linkowanie było powszechne, i nadal jest pomocne we wprowadzaniu Androida do producentów oprogramowania przyzwyczajonych do prawnie zastrzeżonych systemów operacyjnych, którzy mogą być ostrożni wobec LGPL i niejasnych co do różnic między nim a pełna Powszechna Licencja Publiczna GNU (GPL).

Bionic jest biblioteką C do użytku z jądrem Linuksa i dostarcza libc , libdl , libm i libpthread . Różni się to od bibliotek BSD C, które wymagają jądra BSD .

Oryginalne cele

Pierwotne publicznie określone cele Bionic były następujące:

  • Licencjonowane przez BSD : Google chciał odizolować aplikacje na Androida od wpływu licencji typu copyleft, aby stworzyć zastrzeżony ekosystem przestrzeni użytkownika i aplikacji, ale:
    • Android jest oparty na jądrze Linux, które podlega licencji copyleft GNU General Public License (GPL) w wersji 2.
    • Najbardziej rozpowszechnioną standardową biblioteką C dla jądra Linuksa jest GNU C Library (glibc), która podlega licencji GNU Lesser General Public License (LGPL), także licencji typu copyleft. W przeciwieństwie do GPL, LGPL wyraźnie zezwala na dynamiczne łączenie, ale nie pozwala na statyczne łączenie prawnie zastrzeżonego oprogramowania bez dostarczenia kodu źródłowego lub plików obiektowych, które można
    łączyć .
  • Liberalna licencja BSD jest nie- copyleft licencja, która jest zgodna w obu kierunkach. Substytut glibc na licencji BSD może działać jako warstwa izolująca między rdzeniem (jądrem) typu copyleft a aplikacjami nie będącymi własnością typu copyleft, dlatego został wybrany przez Google ze względu na swój Bionic jako substytut glibc.
  • Mały rozmiar: Bionic był znacznie mniejszy niż biblioteka GNU C; co ważniejsze, jego wymagania dotyczące pamięci były (i pozostają) znacznie niższe.
  • Szybkość: Bionic został zaprojektowany dla procesorów o stosunkowo niskich częstotliwościach zegara.

    • Obsługiwane architektury

    Bionic obsługuje tylko jądra Linuksa, ale obecnie obsługuje architektury arm, arm64, x86 i x86-64. Sama platforma wymagała armv7 z Neon od czasu Marshmallow , chociaż Android Native Development Kit (NDK) nadal wspierał armv5 (które nazywał armeabi) aż do NDK r16. NDK nadal obsługuje armv7 zarówno z neonem, jak i bez niego. Historycznie platforma miała częściową obsługę SH-4 , ale żadne urządzenia nigdy nie zostały wysłane, a wsparcie zostało od tego czasu usunięte. NDK nigdy nie obsługiwał SH-4, a obsługa MIPS i MIPS64 została usunięta z NDK w r17.

    składniki

    Niektóre części źródła libc, takie jak stdio , pochodzą z BSD (głównie OpenBSD ), podczas gdy inne, takie jak implementacja pthread , zostały napisane od zera.

    Dynamicznego przydzielania pamięci realizacja uległa zmianie w czasie. Przed Lollipopem istniał jeden natywny alokator pamięci, dlmalloc Douga Lea . Dla Lollipop i Marshmallow były dwie implementacje: dlmalloc i jemalloc . jemalloc zapewnia znacznie wyższą wydajność niż dlmalloc, ale kosztem dodatkowej pamięci wymaganej do prowadzenia księgowości. Większość urządzeń używała jemalloc, ale urządzenia o małej ilości pamięci nadal używały dlmalloc. W przypadku Nougat za pośrednictwem Androida 10 wszystkie urządzenia używają jemalloc. Urządzenia o małej ilości pamięci używają "smukłej" konfiguracji jemalloc, która wyłącza pamięć tcache, aby prawie dopasować się do mniejszego obciążenia pamięci dlmalloc, zachowując większość prędkości jemalloc. W systemie Android 11 alokator pamięci dla większości urządzeń został zmieniony na Scudo, co poświęca część wysokiej wydajności jemalloc na rzecz dodatkowych funkcji zwiększania bezpieczeństwa. Jednak urządzenia o małej pamięci nadal mogą używać jemalloc.

    Niektóre urządzenia 64-bitowe, takie jak Nexus 9 , są faktycznie urządzeniami o małej ilości pamięci ze względu na dodatkowe wymagania przestrzenne 64-bitowych wskaźników i hostingu dwóch zygot. ( Zygote to usługa systemu Android, która jest rodzicem wszystkich procesów aplikacji na Androida.)

    Źródłem libm jest w dużej mierze FreeBSD , ale ze zoptymalizowanym asemblerem dostarczanym przez różnych dostawców SoC .

    Dynamiczny linker (i libdl) zostały napisane od podstaw.

    Bionic nie zawiera libthread_db (używanego przez gdbserver ), ale NDK tak. Platforma Android zawiera statycznie połączony serwer gdb, dzięki czemu programiści mogą korzystać z najnowszego gdb nawet na starych urządzeniach.

    Nie ma oddzielnego libpthread, libresolv ani librt na Androidzie – cała funkcjonalność jest w libc. W przypadku libpthread nie ma próby optymalizacji dla przypadku jednowątkowego, ponieważ aplikacje działają w środowisku wielowątkowym, nawet przed uruchomieniem pierwszej instrukcji kodu innej firmy.

    Platforma Android używa libc++ dla standardowej biblioteki C++ (wydania do Lollipop włącznie z użyciem stlport). NDK historycznie oferował stlport i GNU libstdc++, ale zostały one usunięte wraz z NDK r18. Pamiętaj, że jeśli dowolny kod natywny w aplikacji dla systemu Android używa C++, wszystkie C++ muszą używać tego samego STL . STL nie jest dostarczany przez system operacyjny Android i musi być dołączony do każdej aplikacji.

    Różnice w stosunku do POSIX

    Chociaż Bionic ma na celu zaimplementowanie całego C11 i POSIX , wciąż (od Oreo) brakuje około 70 funkcji POSIX w libc. Istnieją również funkcje POSIX, takie jak rodzina endpwent/getpwent/setpwent, które nie mają zastosowania w systemie Android, ponieważ brakuje w nich bazy danych passwd . Od Oreo libm jest kompletny.

    Niektóre funkcje celowo nie są zgodne ze standardami POSIX lub C ze względów bezpieczeństwa, np. printf, który nie obsługuje ciągu %nformatującego.

    Wiele najczęściej używanych rozszerzeń GNU jest zaimplementowanych w Bionic, podobnie jak różne rozszerzenia BSD.

    Stosunek do NDK

    Kod platformy używa bezpośrednio Bionic, ale programiści zewnętrzni używają zestawu Android Native Development Kit (NDK). Wielu programistów zewnętrznych nadal atakuje starsze wersje systemu operacyjnego, co przyczynia się do powszechnego przekonania, że ​​bionic nie ma wielu funkcji. Gingerbread wyeksportował 803 funkcje z libc, ale Oreo wyeksportował 1278 (wzrost o 1,6x).

    Historycznie NDK i platforma były rozbieżne, ale NDK r11 i później zastąpiły widełki NDK ich obecnymi odpowiednikami platformy. Ta praca początkowo skupiała się na kompilatorach GCC i Clang .

    Przed NDK r14, kiedy "ujednolicone" nagłówki były po raz pierwszy oferowane na zasadzie opt-in, NDK posiadało rozwidlone kopie nagłówków platformy dla różnych poziomów API. Oznaczało to, że poprawki dotyczące tylko nagłówków (na przykład poprawki do definicji stałych lub struktur) nie były dostępne dla większości użytkowników NDK, ponieważ byłyby one ukierunkowane na starszy poziom API, ale poprawki platformy wchodziły tylko do obecnych nagłówków platformy. W okresie rozwoju Oreo nagłówki platformy były adnotowane informacjami o poziomie API, dzięki czemu ten sam zestaw nagłówków może być używany dla wszystkich poziomów API, przy czym widoczne są tylko te funkcje, które są dostępne na docelowym poziomie API programisty. Są to tak zwane "zunifikowane" nagłówki i były domyślne od czasu NDK r15.

    Przed NDK r16, NDK łączyło bibliotekę o nazwie libandroid_support.a z kodem przy użyciu libc++. Zapewniało to funkcje wymagane przez libc++, których nie było w starych wydaniach systemu operacyjnego. To nie był ten sam kod używany przez platformę i wprowadził wiele błędów (takich jak łamanie argumentów pozycyjnych do rodziny printf w dowolnym kodzie, który używał libc++). W NDK r16 libandroid_support.a nadal istnieje, ale jest teraz budowany bezpośrednio ze źródła platformy (aktualny w momencie budowania NDK).

    Wzmocnij źródło

    Jak z Android Jelly Bean MR1 (4,2), Bionic obsługuje podobną funkcjonalność do glibc _FORTIFY_SOURCE, co jest cechą gdzie niebezpieczne smyczkowych i pamięci funkcje (takie jak strcpy(), strcat()i memcpy()) obejmują kontrole dotyczące przekroczenia buforowych. Te sprawdzenia są wykonywane w czasie kompilacji, jeśli rozmiary buforów można określić w czasie kompilacji lub w czasie wykonywania w inny sposób. Ponieważ fortify opiera się na obsłudze środowiska uruchomieniowego libc, jego przenośność do starszych wersji Androida jest ograniczona. Sama platforma jest zbudowana z _FORTIFY_SOURCEwłączonym.

    Historycznie jedną z wad fortify było to, że jest blisko powiązana z GCC, co bardzo utrudnia dobrą obsługę w innych kompilatorach, takich jak Clang. Oznaczało to, że kiedy Android zamienił się na Clang jako domyślny kompilator, implementacja fortify Bionic stała się znacznie mniej użyteczna. W Androidzie Oreo (8.0), fortify Bionic został przebudowany z myślą o Clangu, dzięki czemu fortify na Clang zapewnia wrażenia na równi z fortify na GCC. Od czasu tej przeróbki dodano kilka sprawdzeń wykraczających poza glibc, aby wyłapać kod, który — choć niekoniecznie powoduje niezdefiniowane zachowanie — jest oczywiście niepoprawny. Ponieważ ta nowa implementacja nie wymaga więcej obsługi libc niż poprzednia, ulepszenia specyficzne dla Clang są dostępne dla aplikacji przeznaczonych dla wersji Androida przed Oreo.

    Kontrowersje

    Do stworzenia Bionic, Google użyło plików nagłówkowych jądra Linuksa na licencji GPLv2 . Aby pozbyć się GPL, Google twierdziło, że wyczyściło pliki nagłówkowe z wszelkich dzieł objętych prawami autorskimi, redukując je do niepodlegających prawu autorskiemu „faktów”. Twórca Linuksa Linus Torvalds uznał zachowanie Google za dopuszczalne, ale interpretacja GPL przez Google została zakwestionowana, na przykład przez Raymonda Nimmera, profesora prawa z University of Houston Law Center .

    Zobacz też

    Bibliografia

    Zewnętrzne linki