ב-Android 7.0 הוצגו מרחבי שמות לספריות מקומיות כדי להגביל את הנראות של ממשקי API פנימיים ולפתור מצבים שבהם אפליקציות משתמשות בטעות בספריות פלטפורמה במקום בספריות שלהן. בפוסט בבלוג של Android Developers בנושא שיפור היציבות באמצעות הגבלות על סמלי C/C++ פרטיים ב-Android 7.0 מפורטים שינויים ספציפיים לאפליקציות.
ארכיטקטורה
ב-Android מגרסה 7.0 ואילך, ספריות המערכת מופרדות מספריות האפליקציות.
איור 1. מרחבי שמות לספריות מקוריות.
מרחבי שמות לספריות מקוריות מונעים מאפליקציות להשתמש בממשקי API מקוריים של פלטפורמות פרטיות (כמו שנעשה עם OpenSSL). בנוסף, השינוי הזה מונע מצבים שבהם אפליקציות משתמשות בטעות בספריות של הפלטפורמה במקום בספריות שלהן (כפי שקרה ב-libpng). קשה לספריות של אפליקציות להשתמש בטעות בספריות פנימיות של המערכת (ולהפך).
הוספת ספריות מקוריות נוספות
בנוסף לספריות Native ציבוריות רגילות, ספקי סיליקון (החל מ-Android 7.0) ויצרני מכשירים (החל מ-Android 9) יכולים לספק ספריות Native נוספות שאפליקציות יכולות לגשת אליהן. כדי לעשות זאת, הם צריכים להוסיף אותן לתיקיות הספריות המתאימות ולציין אותן באופן מפורש בקובצי .txt.
תיקיות הספרייה הן:
-
/vendor/lib(ל-32 ביט) ו-/vendor/lib64(ל-64 ביט) לספריות מספקי סיליקון -
/system/lib(ל-32 ביט) ו-/system/lib64(ל-64 ביט) לספריות מיצרני מכשירים
קובצי ה- .txt הם:
-
/vendor/etc/public.libraries.txtלספריות מספקי סיליקון -
/system/etc/public.libraries-COMPANYNAME.txtלספריות של יצרני מכשירים, כאשרCOMPANYNAMEהוא שם היצרן (לדוגמה,awesome.company).COMPANYNAMEחייב להיות זהה ל-[A-Za-z0-9_.-]+; תווים אלפאנומריים, _, . (נקודה) ו--. יכול להיות שיש כמה קובצי .txt כאלה במכשיר אם חלק מהספריות מגיעות מספקי פתרונות חיצוניים.
ספריות Native במחיצה system שמוגדרות כציבוריות על ידי יצרני המכשירים חייבות להיקרא lib*COMPANYNAME.so, לדוגמה, libFoo.awesome.company.so.
במילים אחרות, libFoo.so אסור לפרסם את השם בלי הסיומת של שם החברה.
השם COMPANYNAME בקובץ הספרייה חייב להיות זהה לשם COMPANYNAME בקובץ ה-txt שבו מופיע שם הספרייה.
אסור להפוך ספריות Native שמהוות חלק מ-AOSP לציבוריות (למעט ספריות Native ציבוריות רגילות, שהן ציבוריות כברירת מחדל). אפשר להעניק לאפליקציות גישה רק לספריות הנוספות שנוספו על ידי ספקי סיליקון או יצרני מכשירים.
החל מ-Android 8.0, לספריות ציבוריות של ספקים יש הגבלות נוספות והגדרות נדרשות:
- ספריית ה-Native אצל הספק צריכה להיות מתויגת בצורה נכונה כדי שאפליקציות יוכלו לגשת אליה. אם נדרשת גישה לאפליקציות כלשהן (כולל אפליקציות צד שלישי), צריך להוסיף לספרייה את התווית
same_process_hal_fileבקובץfile_contextsספציפי לספק באופן הבא: /vendor/lib(64)?/libnative.so u:object_r:same_process_hal_file:s0
libnative.soהוא השם של ספריית Native. - הספרייה, באופן ישיר או דרך התלויות שלה, לא יכולה להיות תלויה בספריות מערכת אחרות מלבד ספריות VNDK-SP ו-LLNDK. אפשר למצוא את רשימת הספריות של VNDK-SP ו-LLNDK בכתובת
development/vndk/tools/definition/tool/datasets/eligible-list-<version>-release.csv.
החל מ-Android 15, אפשר להציב ספריות ציבוריות של ספקים בספק APEX. כשמצרפים אותן לחבילת APEX של ספק, צריך לפרט את הספריות במאפיין provideNativeLibs במניפסט של ה-APEX.
עדכון אפליקציות כדי שלא ישתמשו בספריות מקוריות לא ציבוריות
התכונה הזו מופעלת רק באפליקציות שמטרגטות SDK בגרסה 24 ואילך. למידע על תאימות לאחור, אפשר לעיין בטבלה 1. למה לצפות אם האפליקציה מקשרת לספריות Native פרטיות. רשימת ספריות Native של Android שאפליקציות יכולות לגשת אליהן (נקראות גם ספריות Native ציבוריות) מופיעה בקטע 3.1.1 של CDD. צריך לעדכן אפליקציות שמטרגטות גרסה 24 ואילך ומשתמשות בספריות לא ציבוריות. פרטים נוספים מופיעים במאמר NDK Apps Linking to Platform Libraries .
עדכון אפליקציות כדי לכלול את יחסי התלות שלהן בספריות Native
באפליקציות שמטרגטות לגרסת SDK 31 (Android 12) ומעלה, חובה לציין באופן מפורש את יחסי התלות בספריות Native משותפות באמצעות התג <uses-native-library> בקובץ מניפסט של אפליקציה. אם חלק כלשהו מהספרייה המבוקשת לא קיים במכשיר, האפליקציה לא מותקנת. כשהאפליקציות מותקנות, הן מקבלות רק את הספריות המשותפות של Native שהן ביקשו. המשמעות היא שאפליקציות לא יכולות לגשת לספריות Native משותפות שלא מופיעות בקובץ מניפסט של אפליקציה.