ייעוץ לספקי תווכה

הפצת תוכנת ביניים שנוצרה באמצעות NDK מעוררת כמה בעיות נוספות שמפתחי האפליקציות לא צריכים לדאוג אליהן. ספריות מוכנות מראש מכתיבות למשתמשים חלק מהאפשרויות שלהן להטמעה.

בחירת רמות API וגרסאות NDK

המשתמשים לא יכולים להשתמש ב-minSdkVersion נמוך יותר מהערך שלכם. אם המשתמשים צריכים לרוץ ב-API 21, לא ניתן ליצור עבור API 24. מותר לפתח את הספרייה לרמת API נמוכה יותר מזו של המשתמשים. אפשר ליצור גרסת API ל-API 16 וימשיכו להיות תואמים למשתמשי API 21 שלכם.

גרסאות NDK תואמות זו לזו במידה רבה, אבל לפעמים יש שינויים שמפריעים לתאימות. אם אתם יודעים שכל המשתמשים שלכם משתמשים באותה גרסה של NDK, מומלץ להשתמש באותה גרסה. אחרת, כדאי להשתמש בגרסה החדשה ביותר.

שימוש ב-STL

אם אתם כותבים ב-C++‎ ומשתמשים ב-STL, הבחירה בין libc++_shared ל-libc++_static משפיעה על המשתמשים שלכם אם אתם מפיצים ספרייה משותפת. אם להפיץ ספרייה משותפת, עליך להשתמש ב-libc++_shared או לוודא הסמלים של libc++ אינם גלויים בספרייה שלך. הדרך הטובה ביותר לעשות זאת היא להצהיר במפורש על פלטפורמת ה-ABI באמצעות סקריפט גרסה.

אפשרות נוספת, פחות חזקה, היא להשתמש ב--Wl,--exclude-libs,libc++_static.a -Wl,--exclude-libs,libc++abi.a בזמן הקישור. זה פחות מתקדם כי יסתיר את הסמלים רק בספריות שיש להן שם מפורש, ולא מתבצע דיווח על ניתוחים של ספריות שלא נעשה בהן שימוש (שגיאת הקלדה בספרייה אינו שגיאה, והעומס הוא על המשתמש לשמור את רשימת הספרייה עד היום). הגישה הזו גם לא מסתירה את פרטי ההטמעה שלכם.

הפצת ספריות מקוריות ב-AARs

הערה: בקטע הזה מוסבר איך להפיץ ממשקי API של C/C++ למשתמשים. אם הספריות הילידיות הן פרטי הטמעה של ממשק ה-API ל-Java, כדאי לעיין בקטע Middleware של Java עם ספריות JNI.

הפלאגין של Android Gradle יכול לייבא יחסי תלות מקומיים שמופצים בקבצי AAR. אם המשתמשים שלך משתמשים בפלאגין של Android Gradle, זו תהיה את הדרך הקלה ביותר בשבילם לצרוך את הספרייה שלכם.

ניתן לארוז ספריות מקוריות לתוך AAR באמצעות AGP. זו תהיה האפשרות הקלה ביותר אם הספרייה כבר נוצרה באמצעות externalNativeBuild.

גרסאות build שאינן של AGP יכולות להשתמש ב-ndkport או לבצע אריזה ידנית לפי מסמכי תיעוד של Prefab כדי ליצור את ספריית המשנה prefab/ של ה-AAR שלהם.

תווכה של Java עם ספריות JNI

בספריות Java שכוללות ספריות JNI (כלומר, ספריות AAR שמכילות את jniLibs), צריך להקפיד שספריות ה-JNI שכלולות בהן לא ייכנסו להתנגשויות עם ספריות אחרות באפליקציה של המשתמש. לדוגמה, אם ספריית ה-AAR כוללת את libc++_shared.so, אבל בגרסה שונה מזו שבה האפליקציה משתמשת, רק אחת מהן תותקן בקובץ ה-APK, וזה עלול להוביל להתנהגות לא מהימנה.

אזהרה: Bug 141758241: בגרסאות ישנות יותר של הפלאגין Android Gradle לאבחן כרגע את מצב השגיאה הזה. אחת מהספריות עם שם זהה ייבחר באופן שרירותי לאריזה ב-APK.

הפתרון האמין ביותר הוא שספריות Java יכללו לא יותר מספריית JNI אחת (זו גם עצה טובה לאפליקציות). כל יחסי התלות, כולל צריך לקשר את STL באופן סטטי לספריית ההטמעה, וגרסה צריך להשתמש בסקריפט כדי לאכוף את פלטפורמת ה-ABI. לדוגמה, בספריית Java‏ com.example.foo שכוללת את ספריית ה-JNI‏ libfooimpl.so צריך להשתמש בסקריפט הגרסה הבא:

LIBFOOIMPL {
global:
    JNI_OnLoad;
local:
    *;
};

בדוגמה הזו נעשה שימוש ב-registerNatives דרך JNI_OnLoad כפי שמתואר בטיפים ל-JNI כדי להבטיח שרק שטח ה-ABI המינימלי נחשף וזמן הטעינה של הספרייה מצומצם ככל האפשר.