פיתוח גרסאות build לארכיטקטורות של 32 ו-64 ביט

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

מערכת ה-build תומכת ביצירת קובצי בינארי לשתי ארכיטקטורות של מעבדים (CPU) ייעודיים, 32 ביט ו-64 ביט, באותו build. גרסה של build עם שני יעדים נקראת multilib build.

בספריות סטטיות מובנות ובספריות משותפות, מערכת ה-build מגדירה כללים ליצירת קובצי בינארי בשתי הארכיטקטורות. הגדרות המוצר (PRODUCT_PACKAGES), יחד עם תרשים התלות, קובע קבצים בינאריים נוצרים ומותקנים בתמונת המערכת.

לקובצי הפעלה ולאפליקציות, מערכת ה-build יוצרת רק את גרסת 64 סיביות על ידי אבל אפשר לשנות את ההגדרה הזו באמצעות הגדרה של משתנה BoardConfig.mk או משתנה ברמת המודול.

זיהוי ארכיטקטורה ו-ABI של מעבד שני

BoardConfig.mk כולל את המשתנים הבאים כדי להגדיר את המעבד השני וממשק בינארי של אפליקציות (ABI):

• TARGET_2ND_ARCH
• TARGET_2ND_ARCH_VARIANT
• TARGET_2ND_CPU_VARIANT
• TARGET_2ND_CPU_ABI
• TARGET_2ND_CPU_ABI2

לדוגמה, getfile שמשתמש במשתנים האלה: build/make/target/board/generic_arm64/BoardConfig.mk

ב-build של multilib, שמות המודולים ב-PRODUCT_PACKAGES מכסים גם את הקבצים הבינאריים של 32 סיביות וגם את הקבצים הבינאריים של 64 סיביות, כל עוד הם מוגדרים על ידי מערכת ה-build. עבור ספריות שכלולות בתלות, ספרייה של 32 או 64 ביט מותקנת רק אם היא נדרשת בספרייה אחרת של 32 סיביות או 64 סיביות, או קובץ הפעלה.

עם זאת, שמות המודולים בשורת הפקודה make מכסים רק את הגרסה ל-64 ביט. לדוגמה, אחרי שמריצים את lunch aosp_arm64-eng, make libc יוצר רק את libc של 64 ביט. שפת תרגום לבנות את ה-libc בגרסת 32 סיביות, צריך להריץ את make libc_32.

הגדרת ארכיטקטורת המודול בקובץ Android.mk

אפשר להשתמש במשתנה LOCAL_MULTILIB כדי להגדיר את ה-build ל-32 ביט ול-64 ביט ולשנות את ברירת המחדל של המשתנה הגלובלי TARGET_PREFER_32_BIT.

כדי לשנות את TARGET_PREFER_32_BIT, צריך להגדיר את LOCAL_MULTILIB לאחת מהאפשרויות הבאים:

• both יוצר גרסאות build ב-32 ביט וב-64 ביט.
• 32 יכול לפתח רק 32 ביט.
• 64 יוצר רק גרסת build של 64 ביט.
• first יוצר גרסאות build רק לארכיטקטורה הראשונה (32 ביט במכשירים של 32 ביט ו-64 ביט במכשירים של 64 ביט).

כברירת מחדל לא מוגדר LOCAL_MULTILIB, ומערכת ה-build קובעת של ארכיטקטורת RNN המבוססת על מחלקה LOCAL_* משתנים, כמו LOCAL_MODULE_TARGET_ARCH ו-LOCAL_32_BIT_ONLY.

כדי לבנות את המודול לארכיטקטורות ספציפיות, משתמשים משתנים:

• LOCAL_MODULE_TARGET_ARCH – מגדירים את המשתנה הזה לרשימה של ארכיטקטורות, כמו arm x86 arm64. אם הארכיטקטורה שאתם רוצים ליצור נמצאת ברשימה הזו, המודול הנוכחי נכלל על ידי מערכת ה-build.

• LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH – המשתנה הזה הוא ההיפך מ-LOCAL_MODULE_TARGET_ARCH. אם הארכיטקטורה שנוצרת היא not ברשימה הזו, המערכת תיצור את המודול הנוכחי.

יש וריאציות קלות של שני המשתנים האלה:

• LOCAL_MODULE_TARGET_ARCH_WARN
• LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN

מערכת ה-build מציגה אזהרה אם מדלגים על המודול הנוכחי בגלל של הארכיטקטורות המפורטות.

כדי להגדיר דגלי build לארכיטקטורה ספציפית, צריך להשתמש LOCAL_* ספציפיים לארכיטקטורה, כאשר * היא סיומת ספציפית לארכיטקטורה, לדוגמה:

• LOCAL_SRC_FILES_arm, LOCAL_SRC_FILES_x86,
• LOCAL_CFLAGS_arm, LOCAL_CFLAGS_arm64,
• LOCAL_LDFLAGS_arm, LOCAL_LDFLAGS_arm64,

המשתנים האלה חלים רק אם מתבצע פיתוח של קובץ בינארי לארכיטקטורה הזו.

לפעמים קל יותר להגדיר סימונים אם הקובץ הבינארי להיות בגרסת 32 סיביות או 64 סיביות. שימוש בLOCAL_* עם הסיומת _32 או _64, לדוגמה:

• LOCAL_SRC_FILES_32, LOCAL_SRC_FILES_64,
• LOCAL_CFLAGS_32, LOCAL_CFLAGS_64,
• LOCAL_LDFLAGS_32, LOCAL_LDFLAGS_64,

הגדרת נתיב להתקנת הספרייה

לגרסה ללא multilib, אפשר להשתמש ב-LOCAL_MODULE_PATH כדי להתקין ספרייה למיקום אחר מלבד מיקום ברירת המחדל. לדוגמה, LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw

אבל, ב-build מרובים, צריך להשתמש ב-LOCAL_MODULE_RELATIVE_PATH במקום זאת:

LOCAL_MODULE_RELATIVE_PATH := hw

בפורמט הזה, גם הספריות של 64 ביט וגם הספריות של 32 ביט מותקנות במיקום הנכון.

אם אתם יוצרים קובץ הפעלה גם ב-32 ביט וגם ב-64 ביט, תוכלו להשתמש באחד מהמשתנים הבאים כדי להבדיל בין נתיב ההתקנה:

• LOCAL_MODULE_STEM_32, LOCAL_MODULE_STEM_64 – מציין את שם הקובץ שהותקן.
• LOCAL_MODULE_PATH_32, LOCAL_MODULE_PATH_64 - מציין את נתיב ההתקנה.

קבלה של ספריית ביניים לקובצי המקור

ב-builder מרובה, אם יוצרים קובצי מקור $(local-intermediates-dir) (או $(intermediates-dir-for)) עם משתנים מפורשים), הוא לא פועל באופן מהימן. כאן למשל כי מקורות הביניים שנוצרו נדרשים גם בגרסת 32 סיביות וגם גרסאות build של 64 ביט, אבל $(local-intermediates-dir) נקודות רק לאחד בין שתי ספריות הביניים.

מערכת ה-build מספקת מודל ייעודי וידידותי ל-multilib היא ספריית הביניים ליצירת מקורות. כדי לאחזר את הנתיב של הספרייה הביניים, משתמשים במאקרו $(local-generated-sources-dir) או $(generated-sources-dir-for). השימושים בפקודות המאקרו האלה דומים $(local-intermediates-dir) וגם $(intermediates-dir-for)

אם קובץ מקור נוצר לספרייה הייעודית הזו ונאסף של LOCAL_GENERATED_SOURCES, הוא מיועד בגרסת 32 ביט וגם ל-64 ביט במצב build מרובה.

תארו את ארכיטקטורת המערכת של יעדים בינאריים מוכנים מראש

ב-build של multilib, אי אפשר להשתמש ב-TARGET_ARCH או ב-TARGET_ARCH בשילוב עם TARGET_2ND_ARCH כדי לציין את ארכיטקטורת המערכת של יעדי הבינארי שנוצרו מראש. במקום זאת, משתמשים במשתנים מסוג LOCAL_* LOCAL_MODULE_TARGET_ARCH או LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH.

עם המשתנים האלה, מערכת ה-build יכולה לבחור את קוד ה-32 סיביות שנוצר מראש גם אם הוא עובד על build מרובה של 64 ביט.

אם אתם רוצים להשתמש בארכיטקטורה שנבחרה כדי לחשב את נתיב המקור של קוד בינארי מובנה מראש, קוראים לפונקציה $(get-prebuilt-src-arch).

אפשרות ליצירת קובצי ODEX של 32 סיביות ו-64 סיביות

במכשירים של 64 ביט, Google יוצרת כברירת מחדל קובצי ODEX של 32 ביט ושל 64 ביט לתמונת האתחול ולספריות Java. כברירת מחדל, Google יוצרת קובצי ODEX רק לארכיטקטורה הראשית של 64 סיביות עבור חבילות APK. אם אפליקציה מופעלת גם בתהליך של 32 ביט וגם בתהליכי 64 ביט, צריך להשתמש ב-LOCAL_MULTILIB := both שנוצרות גם קובצי ODEX של 32 סיביות וגם קובצי ODEX של 64 ביט. אם באפליקציה מותקנת גרסת 32 סיביות או ספריות JNI של 64 ביט, הדגל הזה גם מורה למערכת ה-build לכלול אותן.