הגדרת ART

בדף הזה נסביר איך להגדיר את סביבת זמן הריצה של Android‏ (ART) ואת אפשרויות הידור שלה. הנושאים שבהם נעסוק כאן כוללים הגדרה של הידור מראש של קובץ האימג' של המערכת, אפשרויות הידור של dex2oat ואיך למצוא את האיזון בין נפח המחיצה של המערכת, נפח המחיצה של הנתונים והביצועים.

כדי לעבוד עם ART, אפשר לעיין במאמרים ART ו-Dalvik ופורמט קובץ ההפעלה של Dalvik. במאמר אימות התנהגות האפליקציה בסביבת זמן הריצה של Android‏ (ART) מוסבר איך לוודא שהאפליקציות פועלות כמו שצריך.

איך פועל ART

‏ART משתמש בהידור מראש (AOT), ומתחיל מ-Android 7, הוא משתמש בשילוב היברידי של הידור AOT, הידור בזמן אמת (JIT) ופירוש, וההידור של AOT יכול להיות מונחה-פרופיל. אפשר לשנות את השילוב של כל מצבי הביצוע האלה, ונעסוק בכך בקטע הזה. לדוגמה, מכשירי Pixel מוגדרים לפעול בתהליך הבא:

1. האפליקציה מותקנת בהתחלה עם קובץ מטא-נתונים של dex‏ (.dm) שמופץ על ידי חנות Play, ומכיל פרופיל בענן. ART AOT-compiles את השיטות שמפורטות בפרופיל בענן. לחלופין, אם האפליקציה מותקנת בלי קובץ מטא-נתונים של dex, לא מתבצעת הידור AOT.
2. בפעם הראשונה או השנייה שהאפליקציה פועלת, שיטות שלא עברו הידור AOT מתורגמות. מבין השיטות המתורגמות, אלה שמבוצעות בתדירות גבוהה עוברות הידור בזמן ריצה (JIT). ‏ART יוצר פרופיל מקומי על סמך הביצועים ומשלב אותו עם פרופיל הענן (אם יש כזה).
3. כשהמכשיר לא פעיל ומחובר לטעינה, דימון הידור פועל כדי לבצע הידור מחדש של האפליקציה על סמך הפרופיל המשולב שנוצר במהלך ההפעלות הראשונות.
4. בהפעלות הבאות של האפליקציה, ‏ART משתמש בפריטים שנוצרו על ידי הדימון של הידור, שמכילים יותר קוד שעבר הידור AOT בהשוואה לפריטים שנוצרו במהלך ההפעלה. שיטות שלא עברו הידור AOT עדיין מתורגמות או עוברות הידור JIT. ‏ART מעדכן את התקנת הפרופיל על סמך הביצוע, ולאחר מכן הפרופיל יילקח על ידי הפעלות הבאות של הדימון של הידור.

‏ART מורכב ממהדר (הכלי dex2oat) ומסביבת זמן ריצה (libart.so) שנטענת במהלך האתחול. הכלי dex2oat מקבל קובץ APK ויוצר קובץ אחד או יותר של פריט מידע שנוצר בתהליך פיתוח (artifact) של הידור, שנטען בסביבת זמן הריצה. מספר הקבצים, הסיומות והשמות שלהם עשויים להשתנות במהלך הגרסאות, אבל החל מגרסה 8 של Android, המערכת יוצרת את הקבצים הבאים:

• .vdex: מכיל מטא-נתונים נוספים כדי לזרז את האימות, לפעמים יחד עם קוד ה-DEX הלא דחוס של ה-APK.
• .odex: מכיל קוד שעבר הידור AOT לשיטות ב-APK.
• .art (optional) מכיל ייצוגים פנימיים של ART של מחרוזות וכיתות מסוימות שמפורטות ב-APK, שמשמשים לקיצור זמן ההפעלה של האפליקציה.

אפשרויות הידור

יש שתי קטגוריות של אפשרויות הידור ל-ART:

1. הגדרת ROM למערכת: איזה קוד מקובץ על ידי AOT כשמפתחים קובץ אימג' של מערכת.
2. הגדרות בסביבת זמן ריצה: האופן שבו ART יוצר ומריץ אפליקציות במכשיר.

מסנני Compiler

אחת מהאפשרויות המרכזיות של ART להגדרת שתי הקטגוריות האלה היא מסנני מהדר. מסנני המהדר קובעים את האופן שבו ART יוצרת קודי DEX, והם אפשרות שמועברת לכלי dex2oat. החל מגרסה 8 של Android, יש ארבעה מסננים נתמכים באופן רשמי:

• verify: הפעלה של אימות קוד DEX בלבד (ללא הידור AOT).
• quicken:‏ (Android 11 ואילך) מפעילה אימות של קוד DEX ומבצעת אופטימיזציה של חלק מההוראות DEX כדי לשפר את הביצועים של המתורגמן.
• speed: הפעלת אימות קוד DEX והדרה של כל השיטות באמצעות AOT. לא מתבצעת אופטימיזציה של טעינת הכיתות באף כיתה.
• speed-profile: הפעלת אימות של קוד DEX, הידור שיטות שמפורטות בפרופיל באמצעות AOT ואופטימיזציה של טעינת הכיתות של הכיתות בפרופיל.

הגדרת ROM במערכת

ספריות ואפליקציות שהותקנו מראש עוברות הידור AOT במהלך ה-build של קובץ האימג' של המערכת. התהליך הזה נקרא dexpreopt. אפשר להשתמש בקבצים כאלה כל עוד כל יחסי התלות לא משתנים, במיוחד נתיב ה-Classpath של האתחול.

הערה: אם המכשיר מקבל עדכונים של מודול מערכת, סביר מאוד שנתיב ה-classpath של האתחול ישתנה בעדכון הבא, וכתוצאה מכך כל קובצי dexpreopt יהיו לא רלוונטיים ולא ניתנים לשימוש.

יש מספר אפשרויות build של ART שזמינות להגדרת dexpreopt. אופן ההגדרה של האפשרויות האלה תלוי בנפח האחסון הפנוי לתמונת המערכת ובמספר האפליקציות המותקנות מראש. קובצי ה-JAR או ה-APK שמתורגמים ל-ROM של המערכת מתחלקים לארבע קטגוריות:

• קוד של classpath של אתחול: עבר הידור באמצעות מסנן המהדר speed-profile כברירת מחדל.
• קוד שרת המערכת (ראו PRODUCT_SYSTEM_SERVER_JARS,‏ PRODUCT_APEX_SYSTEM_SERVER_JARS, ‏ PRODUCT_STANDALONE_SYSTEM_SERVER_JARS,‏ PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS בהמשך המסמך):
  • (Android 14 ואילך) הידור באמצעות מסנן המהדר speed-profile כברירת מחדל, או הידור באמצעות מסנן המהדר speed אם לא צוין פרופיל.
  • (Android מגרסה 13 ומטה) הידור עם מסנן המהדר speed כברירת מחדל.
  אפשר להגדיר אותו באמצעות PRODUCT_SYSTEM_SERVER_COMPILER_FILTER (מפורט בהמשך המסמך).
• אפליקציות ליבה ספציפיות למוצר (ראו PRODUCT_DEXPREOPT_SPEED_APPS בהמשך המסמך): כברירת מחדל, המערכת מקמפלת אותן באמצעות מסנן המהדר speed.
• כל האפליקציות האחרות: הידור באמצעות מסנן המהדר speed-profile כברירת מחדל, או הידור באמצעות מסנן המהדר verify אם לא צוין פרופיל.

  אפשר להגדיר אותו באמצעות PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (מידע נוסף מופיע בהמשך המסמך).

אפשרויות של Makefile

• WITH_DEXPREOPT

האם dex2oat מופעל בקוד DEX שמותקן בתמונת המערכת. מופעלת כברירת מחדל.

• DONT_DEXPREOPT_PREBUILTS (Android מגרסה 5 ואילך)

הפעלת DONT_DEXPREOPT_PREBUILTS מונעת את ה-dexpreopt של ה-prebuilts. אלה אפליקציות שצוין להן include $(BUILD_PREBUILT) ב-Android.mk. דילוג על ה-dexpreopt של אפליקציות מוכנות מראש שסביר להניח יתעדכנו דרך Google Play חוסך מקום בתמונת המערכת, אבל מאריך את זמן האתחול הראשון. חשוב לזכור שהאפשרות הזו לא משפיעה על אפליקציות מוכנות מראש שמוגדרות ב-Android.bp.

• PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER (Android מגרסה 9 ואילך)

PRODUCT_DEX_PREOPT_DEFAULT_COMPILER_FILTER מציין את מסנן ברירת המחדל של המהדר לאפליקציות שעברו אופטימיזציה מראש. האפליקציות האלה מוגדרות ב-Android.bp או שצוין להן include $(BUILD_PREBUILT) ב-Android.mk. אם לא מציינים ערך, ערך ברירת המחדל הוא speed-profile. אם לא מציינים ערך ולא מציינים פרופיל, ערך ברירת המחדל הוא verify.

• WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY (החל מגרסה MR1 של Android 8)

הפעלת WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY dexpreopts רק את classpath של האתחול ואת קובצי ה-jar של שרת המערכת.

• LOCAL_DEX_PREOPT

אפשר גם להפעיל או להשבית את Dexpreopt לכל אפליקציה בנפרד, על ידי ציון האפשרות LOCAL_DEX_PREOPT בהגדרת המודול. אפשר להשתמש באפשרות הזו כדי להשבית את dexpreopt של אפליקציות שעשויות לקבל עדכונים מ-Google Play באופן מיידי, כי העדכונים יגרמו לקוד dexpreopt בתמונת המערכת להיות לא רלוונטי. האפשרות הזו שימושית גם כדי לחסוך מקום בשדרוגים OTA של גרסאות גדולות, כי יכול להיות שכבר יש למשתמשים גרסאות חדשות יותר של אפליקציות במחיצה של הנתונים.

LOCAL_DEX_PREOPT תומך בערכים true או false כדי להפעיל או להשבית את dexpreopt, בהתאמה. בנוסף, אפשר לציין את הערך nostripping אם לא רוצים שהפקודה dexpreopt תסיר את הקובץ classes.dex מקובץ ה-APK או ה-JAR. בדרך כלל הקובץ הזה מבוטל כי הוא כבר לא נדרש אחרי dexpreopt, אבל האפשרות האחרונה הזו נחוצה כדי לאפשר לחתימות APK של צד שלישי להישאר תקינות.

• PRODUCT_DEX_PREOPT_BOOT_FLAGS

מעביר אפשרויות אל dex2oat כדי לקבוע את האופן שבו קובץ האימג' של האתחול יעבור הידור. אפשר להשתמש בה כדי לציין רשימות מותאמות אישית של סיווגים של תמונות, רשימות של סיווגים של כיתות שעבר תהליך הידור ומסננים של מהדרים.

• PRODUCT_DEX_PREOPT_DEFAULT_FLAGS

העברת אפשרויות אל dex2oat כדי לקבוע איך יתבצע הידור של כל מה שאינו קובץ האתחול.

• PRODUCT_DEX_PREOPT_MODULE_CONFIGS

מאפשרת להעביר אפשרויות dex2oat להגדרה ספציפית של מודול ומוצר. הוא מוגדר בקובץ device.mk של המוצר על ידי $(call add-product-dex-preopt-module-config,<modules>,<option>), כאשר <modules> היא רשימה של שמות LOCAL_MODULE ו-LOCAL_PACKAGE לקובצי JAR ו-APK, בהתאמה.

• PRODUCT_DEXPREOPT_SPEED_APPS (מ-Android 8 ואילך)

רשימת האפליקציות שזוהו כמרכזיות למוצרים, ורצוי לבצע להן הידור באמצעות מסנן המהדר speed. לדוגמה, אפליקציות קבועות כמו SystemUI מקבלות הזדמנות להשתמש בתכנות מבוססת-פרופיל רק בהפעלה מחדש הבאה, לכן יכול להיות שתמיד עדיף לכתוב את האפליקציות האלה בתכנות AOT.

• PRODUCT_SYSTEM_SERVER_APPS (מ-Android 8 ואילך)

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

• PRODUCT_ART_TARGET_INCLUDE_DEBUG_BUILD (מ-Android 8 ואילך)

האם לכלול במכשיר גרסה של ART לניפוי באגים. כברירת מחדל, ההגדרה הזו מופעלת בגרסאות build של userdebug ו-eng. אפשר לשנות את ההתנהגות על ידי הגדרה מפורשת של האפשרות ל-true או ל-false.

כברירת מחדל, המכשיר משתמש בגרסה ללא ניפוי באגים (libart.so). כדי לעבור, מגדירים את מאפיין המערכת persist.sys.dalvik.vm.lib.2 לערך libartd.so.

• WITH_DEXPREOPT_PIC (עד Android 7)

ב-Android מגרסה 5.1.0 ועד 6.0.1, אפשר לציין את WITH_DEXPREOPT_PIC כדי להפעיל קוד שאינו תלוי מיקום (PIC). כך לא צריך להעביר קוד מהקובץ המאוחזר מ-/system אל /data/dalvik-cache, וכך חוסכים מקום במחיצה של הנתונים. עם זאת, יש השפעה קלה על זמן הריצה כי הפעולה הזו משביתה אופטימיזציה שמנצלת קוד שמבוסס על מיקום. בדרך כלל, במכשירים שרוצים לחסוך מקום ב-/data צריך להפעיל את הידור ה-PIC.

ב-Android 7.0, הידור PIC הופעל כברירת מחדל.

• WITH_DEXPREOPT_BOOT_IMG_ONLY (עד Android 7 MR1)

האפשרות הזו הוחלפה ב-WITH_DEXPREOPT_BOOT_IMG_AND_SYSTEM_SERVER_ONLY, שמאפשרת גם לבחור מראש את קובצי ה-JAR של שרת המערכת.

• PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

האפשרות הזו מציינת את מסנן המהדר בשרת המערכת.

• (Android 14 ואילך) אם לא צוין, ייעשה שימוש במסנן המהדר speed-profile, או במסנן המהדר speed אם לא צוין פרופיל.
• (Android 13 ומטה) אם לא צוין, המערכת תשתמש במסנן של המהדרר speed.
• אם הערך מוגדר כ-speed, נעשה שימוש במסנן המהדר speed.
• אם הערך מוגדר כ-speed-profile, נעשה שימוש במסנן המהדר speed-profile, או במסנן המהדר verify אם לא צוין פרופיל.
• אם הערך מוגדר כ-verify, נעשה שימוש במסנן המהדר verify.
• PRODUCT_SYSTEM_SERVER_JARS, PRODUCT_APEX_SYSTEM_SERVER_JARS, PRODUCT_STANDALONE_SYSTEM_SERVER_JARS, PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS

אלה רשימות של קובצי JAR שנטענים על ידי שרת המערכת. קובצי ה-JAR מקובצים באמצעות מסנן המהדר שצוין ב-PRODUCT_SYSTEM_SERVER_COMPILER_FILTER

• (חובה) PRODUCT_SYSTEM_SERVER_JARS: רשימה של קובצי JAR ב-classpath של שרת המערכת בפלטפורמה (כלומר, כחלק מ-SYSTEMSERVERCLASSPATH). חובה להוסיף קובצי JAR ב-classpath של שרת המערכת לרשימה הזו. אם לא תוסיפו לרשימה קובצי JAR של נתיב ה-class של שרת המערכת, קובצי ה-JAR האלה לא ייטענו.
• (חובה) PRODUCT_APEX_SYSTEM_SERVER_JARS: רשימת קובצי JAR של נתיב ה-class של שרת המערכת שסופקו עם APEX (כלומר, כחלק מ-SYSTEMSERVERCLASSPATH). הפורמט הוא <apex name>:<jar name>. צריך להוסיף לרשימה הזו קובצי JAR של classpath של שרת המערכת של APEX. אם לא תוסיפו לרשימה הזו קובצי JAR של נתיב ה-class של שרת המערכת של APEX, קובצי ה-JAR האלה לא ייטענו.
• (אופציונלי, Android 13 ומטה) PRODUCT_STANDALONE_SYSTEM_SERVER_JARS: רשימת קובצי JAR ששרת המערכת טוען באופן דינמי באמצעות מערכי טעינה נפרדים של כיתות (דרך SystemServiceManager.startServiceFromJar). לא חובה להוסיף לרשימת קובצי ה-JAR של שרת המערכת העצמאיים, אבל מומלץ מאוד לעשות זאת כי כך קובצי ה-JAR יקובצו, וכתוצאה מכך הביצועים שלהם יהיו טובים בסביבת זמן הריצה.
• (חובה, החל מ-Android 13) PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS: רשימה של קובצי JAR שנשלחים עם APEX ושרת המערכת טוען באופן דינמי באמצעות מערכי טעינה נפרדים של כיתות (כלומר, דרך SystemServiceManager.startServiceFromJar או שהוגדרו כ-<apex-system-service>). הפורמט הוא <apex name>:<jar name>. צריך להוסיף לרשימה הזו קובצי JAR של שרת מערכת APEX עצמאי. אם לא תוסיפו לרשימה הזו קובצי JAR של שרת מערכת APEX עצמאיים, תגרמו לכשל אתחול.

הגדרת classpath של האתחול

רשימת הכיתות שהועמסו מראש היא רשימה של כיתות ש-Zygote מאתחלת בזמן ההפעלה. כך כל אפליקציה לא צריכה להריץ את מפעילי הכיתות האלה בנפרד, וכך האפליקציות יכולות להתחיל לפעול מהר יותר ולשתף דפים בזיכרון. קובץ רשימת הכיתות שהוטען מראש נמצא ב-frameworks/base/config/preloaded-classes כברירת מחדל, והוא מכיל רשימה שמותאמת לשימוש טיפוסי בטלפון. יכול להיות שההגדרה הזו תהיה שונה במכשירים אחרים, כמו תכשיטים לבישים, וצריך לשנות אותה בהתאם. חשוב להיזהר כשמשנים את ההגדרה הזו. הוספת יותר מדי כיתות גורמת לבזבוז זיכרון כשכיתות שלא בשימוש נטענות. הוספה של מעט מדי כיתות מחייבת כל אפליקציה לכלול עותק משלה, וכך שוב נוצר בזבוז זיכרון.

דוגמה לשימוש (ב-device.mk של המוצר):

PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes

הערה: צריך להציב את השורה הזו לפני שעוברים בירושה על קובצי make של הגדרות המוצר שמקבלים את קובץ ברירת המחדל מ-build/target/product/base.mk.

הגדרות זמן ריצה

אפשרויות JIT

האפשרויות הבאות משפיעות על גרסאות Android רק במקומות שבהם מהדר ה-JIT של ART זמין.

• dalvik.vm.usejit: האם ה-JIT מופעל או לא.
• dalvik.vm.jitinitialsize (ברירת המחדל היא 64K): הקיבולת הראשונית של מטמון הקוד. מאגר הקוד יבצע פינוי אשפה (GC) באופן קבוע ויגדיל את נפחו לפי הצורך.
• dalvik.vm.jitmaxsize (ברירת המחדל היא 64MB): הקיבולת המקסימלית של מטמון הקוד.
• dalvik.vm.jitthreshold (ברירת המחדל היא 10000): הסף שספירת ה'פופולריות' של method צריכה לעבור כדי ש-method יתבצע הידור בזמן ריצה (JIT). המונה 'hotness' הוא מדד פנימי בסביבת זמן הריצה. הוא כולל את מספר הקריאות, ההסתעפויות לאחור וגורמים אחרים.
• dalvik.vm.usejitprofiles (עד Android 13): האם פרופילי JIT מופעלים. אפשר להשתמש באפשרות הזו גם אם הערך של dalvik.vm.usejit הוא false. שימו לב שאם הערך הוא false, מסנן המהדר speed-profile לא ידרוך אף שיטה ב-AOT והוא שווה ל-verify. החל מגרסה Android 14, פרופילי JIT תמיד מופעלים ואי אפשר להשבית אותם.
• dalvik.vm.jitprithreadweight (ברירת המחדל היא dalvik.vm.jitthreshold / 20): המשקל של 'הדוגמאות' של ה-JIT (ראו jitthreshold) לשרשור של ממשק המשתמש של האפליקציה. משתמשים בה כדי לזרז את הידור השיטות שמשפיעות ישירות על חוויית המשתמש במהלך האינטראקציה עם האפליקציה.
• dalvik.vm.jittransitionweight (ברירת המחדל היא dalvik.vm.jitthreshold / 10): המשקל של קריאת השיטה שמעבירה בין קוד הידור למהדר. כך אפשר לוודא שהשיטות הרלוונטיות מקובצות כדי לצמצם את המעברים (שהם יקרים).

אפשרויות של Dex2oat

האפשרויות האלה משפיעות על הידור במכשיר (שנקרא גם dexopt), וחלק מהן משפיעות גם על dexpreopt. לעומת זאת, האפשרויות שצוינו בקטע הגדרת ROM המערכת שלמעלה משפיעות רק על dexpreopt.

אפשרויות לשלוט בשימוש במשאבים:

• dalvik.vm.image-dex2oat-threads/dalvik.vm.image-dex2oat-cpu-set (עד Android 11): מספר השרשור וקבוצת ליבות המעבד (ראו בהמשך) שישמשו בתמונות האתחול.
• dalvik.vm.boot-dex2oat-threads/dalvik.vm.boot-dex2oat-cpu-set:
  • (עד Android 11) מספר השרשור והקבוצה של ליבות המעבד (ראו בהמשך) שבהם יש להשתמש במהלך האתחול לכל דבר מלבד קובצי אימג' להפעלה.
  • (החל מ-Android 12) מספר השרשורות וקבוצת ליבות המעבד (ראו בהמשך) שבהם יש להשתמש במהלך האתחול לכל דבר, כולל קובצי אימג' לאתחול.
    • באופן ספציפי, החל מ-Android 14, הערך הזה תואם לעדיפות PRIORITY_BOOT ב-ART Service.
• dalvik.vm.restore-dex2oat-threads/dalvik.vm.restore-dex2oat-cpu-set:
  • (החל מגרסה 11 של Android ועד לגרסה 13) מספר השרשור והקבוצה של ליבות המעבד (ראו בהמשך) שישמשו לשחזור מהגיבוי בענן.
  • (החל מ-Android 14) מספר השרשור והקבוצה של ליבות המעבד (ראו בהמשך) שישמשו לכל מה שמושפע יותר מהרגישות לזמן אחזור מהרגיל, כולל שחזור מגיבוי בענן.
    • באופן ספציפי, זה תואם לעדיפות PRIORITY_INTERACTIVE_FAST ב-ART Service.
• dalvik.vm.background-dex2oat-threads/ dalvik.vm.background-dex2oat-cpu-set (החל מגרסה 14 של Android): מספר השרשור והקבוצה של ליבות המעבד (ראו בהמשך) שבהם נעשה שימוש ברקע.
  • באופן ספציפי, זה תואם לעדיפות PRIORITY_BACKGROUND ב-ART Service.
• dalvik.vm.dex2oat-threads/dalvik.vm.dex2oat-cpu-set: מספר השרשור וקבוצת ליבות המעבד שישמשו לכל שאר הדברים.

יש לציין קבוצה של ליבות מעבד כרשימה של מזהי מעבדים שמופרדים בפסיקים. לדוגמה, כדי להריץ את dex2oat בליבות המעבד 0 עד 3, מגדירים:

dalvik.vm.dex2oat-cpu-set=0,1,2,3

כשמגדירים את מאפייני הקשר ל-CPU, מומלץ להתאים את המאפיין התואם למספר השרשראות של dex2oat למספר המעבדים שנבחרו, כדי למנוע תחרות מיותרת על זיכרון ועל קלט/פלט:

dalvik.vm.dex2oat-cpu-set=0,1,2,3
dalvik.vm.dex2oat-threads=4

בנוסף למאפייני המערכת שלמעלה, אפשר גם להשתמש בפרופילים של משימות כדי לשלוט בשימוש במשאבים של dex2oat (ראו שכבת האבסטרקציה של Cgroup).

פרופילי המשימות הנתמכים הם:

• Dex2OatBackground (החל מגרסה 14 של Android) (אופן ברירת המחדל הוא בירושה מ-Dex2OatBootComplete): האפשרות הזו קובעת את המשאבים שבהם המערכת תשתמש ברקע.
  • באופן ספציפי, זה תואם לעדיפות PRIORITY_BACKGROUND ב-ART Service.
• Dex2OatBootComplete:
  • (עד Android 13) קובע את המשאב שבו נעשה שימוש בכל מה שקורה אחרי האתחול.
  • (החל מ-Android 14) קובע את המשאב שבו ישתמשו בכל מה שקורה אחרי האתחול ולא ברקע.
    • באופן ספציפי, זה תואם לעדיפות PRIORITY_INTERACTIVE_FAST ו-PRIORITY_INTERACTIVE בשירות ART.

כשמציינים גם מאפייני מערכת וגם פרופילים של משימות, שניהם נכנסים לתוקף.

אפשרויות לשלוט בגודל האוסף:

• dalvik.vm.image-dex2oat-Xms: גודל האשפה הראשוני בקובצי אימג' לאתחול.
• dalvik.vm.image-dex2oat-Xmx: גודל האשפה המקסימלי לקובצי אימג' לאתחול.
• dalvik.vm.dex2oat-Xms: גודל האשפה הראשוני לכל שאר הפריטים.
• dalvik.vm.dex2oat-Xmx: גודל האוסף המקסימלי לכל שאר הפריטים.

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

אפשרויות לשלוט במסנן של המהדר:

• dalvik.vm.image-dex2oat-filter (עד Android 11): מסנן המהדר עבור קובצי אימג' להפעלה. החל מגרסה 12 של Android, המסנן של המהדר לתמונות אתחול הוא תמיד speed-profile ואי אפשר לשנות אותו.
• dalvik.vm.systemservercompilerfilter (החל מ-Android 13): מסנן המהדר לשרת המערכת. PRODUCT_SYSTEM_SERVER_COMPILER_FILTER
• dalvik.vm.systemuicompilerfilter (החל מ-Android 13): מסנן המהדר למארז System UI.
• dalvik.vm.dex2oat-filter (עד Android 6): מסנן המהדר עבור כל שאר הדברים.
• pm.dexopt.<reason> (החל מגרסה 7 של Android): מסנן המהדר לכל שאר הדברים. למידע נוסף, ראו הגדרת שירות ART לגרסאות Android 14 ואילך, או הגדרת מנהל החבילות לגרסאות Android 13 ומטה.

אפשרויות אחרות לשלוט בתהליך ה-compilation של כל מה שאינו קובצי אימג' להפעלה:

• dalvik.vm.dex2oat-very-large (החל מ-Android 7.1): הגודל הכולל המינימלי של קובץ dex בבייטים כדי להשבית את הידור AOT.
• dalvik.vm.dex2oat-swap (החל מ-Android 7.1) (ברירת המחדל: true): מאפשר להשתמש בקובץ החלפה ל-dex2oat. כך אפשר למנוע קריסות שנובעות מיציאה מחוץ למכסת הזיכרון. חשוב לזכור שגם אם האפשרות הזו מופעלת, הכלי dex2oat ישתמש בקובץ החלפה רק בתנאים מסוימים, למשל כשמספר קובצי ה-dex גדול, והתנאים עשויים להשתנות.
• dalvik.vm.ps-min-first-save-ms (החל מגרסה 12 של Android): משך ההמתנה המינימלי לפני שסביבת זמן הריצה יוצרת פרופיל של האפליקציה בפעם הראשונה שהיא מופעלת.
• dalvik.vm.ps-min-save-period-ms (החל מ-Android 12): משך הזמן המינימלי להמתנה לפני עדכון הפרופיל של האפליקציה.
• dalvik.vm.dex2oat64.enabled (החל מ-Android 11) (ברירת המחדל: false): האפשרות להשתמש בגרסת 64-ביט של dex2oat.
• dalvik.vm.bgdexopt.new-classes-percent (החל מ-Android 12) (ברירת המחדל: 20): האחוז המינימלי, בין 0 ל-100, של כיתות חדשות בפרופיל כדי להפעיל הידור מחדש. רלוונטי רק ל-profile-guided compilation‏ (speed-profile), בדרך כלל במהלך dexopt ברקע. חשוב לזכור שיש גם סף של 50 כיתות חדשות לפחות, בנוסף לסף האחוזים, ואי אפשר לשנות אותו.
• dalvik.vm.bgdexopt.new-methods-percent (החל מגרסה 12 של Android) (ברירת המחדל: 20): האחוז המינימלי, בין 0 ל-100, של שיטות חדשות בפרופיל כדי להפעיל הידור מחדש. רלוונטי רק ל-profile-guided compilation‏ (speed-profile), בדרך כלל במהלך dexopt ברקע. חשוב לזכור שיש גם סף של לפחות 100 שיטות חדשות בנוסף לסף האחוזים, ואי אפשר לשנות אותו.
• dalvik.vm.dex2oat-max-image-block-size (החל מ-Android 10) (ברירת המחדל: 524288) גודל מקסימלי של בלוק מוצק לתמונות דחוסות. תמונה גדולה מחולקת לקבוצה של בלוקים מוצקים, כך שאף בלוק לא גדול מהגודל המקסימלי.
• dalvik.vm.dex2oat-resolve-startup-strings (החל מ-Android 10) (ברירת המחדל: true) אם הערך הוא true, המערכת תגרום ל-dex2oat לפתור את כל מחרוזות הקבועים שמפנים לשיטות שמסומנות בתור 'הפעלה' בפרופיל.
• debug.generate-debug-info (ברירת המחדל: false) האפשרות ליצור מידע לניפוי באגים לצורך ניפוי באגים מקומי, כמו מידע על ביטול הקיפול של הערימה, סמלי ELF וקטעי dwarf.
• dalvik.vm.dex2oat-minidebuginfo (החל מ-Android 9) (ברירת המחדל: true) האפשרות ליצור כמות מינימלית של פרטי ניפוי באגים דחוסים ב-LZMA הנדרשים להדפסת מעקב נתיב חזרה.

אפשרויות השירות של ART

החל מ-Android 14, שירות ART מטפל בתהליך הידור AOT לאפליקציות במכשיר (שנקרא גם dexopt). מידע נוסף על הגדרת ART Service זמין במאמר הגדרת ART Service.

אפשרויות של מנהל החבילות

לפני Android 14, ניהול החבילות מטפל בהידור AOT של אפליקציות במכשיר (שנקרא גם dexopt). מידע נוסף על הגדרת מנהל החבילות ל-dexopt זמין במאמר הגדרת מנהל החבילות.

הגדרה ספציפית לניסוי A/B

הגדרת ROM

החל מגרסה 7.0 של Android, יכול להיות שמכשירים ישתמשו בשני מחיצות מערכת כדי לאפשר עדכוני מערכת מסוג A/B. כדי לחסוך בגודל של מחיצת המערכת, אפשר להתקין את הקבצים שנבחרו מראש במחיצה השנייה של המערכת שלא בשימוש. לאחר מכן הם מועתקים למחיצה של הנתונים בהפעלה הראשונה.

דוגמה לשימוש (ב-device-common.mk):

PRODUCT_PACKAGES += \
     cppreopts.sh
PRODUCT_PROPERTY_OVERRIDES += \
     ro.cp_system_other_odex=1

וב-BoardConfig.mk של המכשיר:

BOARD_USES_SYSTEM_OTHER_ODEX := true

חשוב לזכור שקוד של classpath של האתחול, קוד של שרת המערכת ואפליקציות ליבה ספציפיות למוצר תמיד עוברים הידור למחיצה של המערכת. כברירת מחדל, כל האפליקציות האחרות מקובצות במחיצה השנייה של המערכת שלא בשימוש. אפשר לשלוט בכך באמצעות SYSTEM_OTHER_ODEX_FILTER, שהערך שמוגדר לו כברירת מחדל הוא:

SYSTEM_OTHER_ODEX_FILTER ?= app/% priv-app/%

עיבוד OTA ברקע (dexopt)

במכשירים עם תמיכה ב-A/B, אפשר לקמפל אפליקציות ברקע לפני ההפעלה מחדש עם קובץ האימג' החדש של המערכת. במאמר הדרכה ליצירת קובצי אימג' של מערכת עם אפליקציות מוסבר איך אפשר לכלול את סקריפט הידור הקוד ואת קובצי ה-binaries בקובץ האימג' של המערכת. אפשר לשלוט במסנן ה-compilation שמשמש ל-compilation הזה באמצעות:

pm.dexopt.ab-ota=speed-profile

מומלץ להשתמש ב-speed-profile כדי ליהנות מהיתרונות של הידור מונחה-פרופיל ולחסוך באחסון.

אפשרויות JDWP

יצירת השרשור של Java Debug Wire Protocol‏ (JDWP) ב-builds של userdebug נשלטת באמצעות מאפיין המערכת persist.debug.dalvik.vm.jdwp.enabled. כברירת מחדל, המאפיין הזה לא מוגדר ושרשראות JDWP נוצרות רק לאפליקציות שניתנות לניפוי באגים. כדי להפעיל את השרשור של JDWP גם לאפליקציות שניתן לנפות בהן באגים וגם לאפליקציות שלא ניתן לנפות בהן באגים, מגדירים את persist.debug.dalvik.vm.jdwp.enabled לערך 1. כדי שהשינויים בנכס ייכנסו לתוקף, צריך להפעיל מחדש את המכשיר.

כדי לנפות באגים באפליקציה שלא ניתן לנפות בה באגים ב-build של userdebug, מפעילים את JDWP באמצעות הפקודה הבאה:

  adb shell setprop persist.debug.dalvik.vm.jdwp.enabled 1
  adb reboot
  

במכשירים עם Android מגרסה 13 ומטה, סביבת זמן הריצה יוצרת שרשראות JDWP לאפליקציות שניתן לנפות באגים בהן ולאפליקציות שלא ניתן לנפות באגים בהן בגרסאות build של userdebug. המשמעות היא שאפשר לצרף כלי לניפוי באגים או ליצור פרופיל של כל אפליקציה בגרסאות build של userdebug.