גרסת הבטא הרביעית של Android 17

‫Android 17 הגיע לגרסת בטא 4, גרסת הבטא המתוזמנת האחרונה של מחזור ההפצה הזה, שהיא אבן דרך חשובה לתאימות האפליקציות ויציבות הפלטפורמה. בין אם אתם משפרים את חוויית המשתמש באפליקציה, מוודאים שהרינדור מקצה לקצה חלק או משתמשים בממשקי ה-API החדשים ביותר, גרסת בטא 4 מספקת את הסביבה כמעט סופית שאתם צריכים לבדיקה. 

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

אם אתם מפתחים ערכת SDK, ספרייה, כלי או מנוע משחקים ל-Android, חשוב מאוד שתכינו עכשיו את כל העדכונים הנדרשים כדי למנוע ממפתחי אפליקציות ומשחקים שמשתמשים במוצרים שלכם להיתקל בבעיות תאימות, וכדי לאפשר להם להשתמש בתכונות העדכניות ביותר של ה-SDK. חשוב להודיע למפתחים שמשתמשים ב-SDK שלך אם נדרשים עדכונים כדי לתמוך באופן מלא ב-Android 17.

הבדיקה כוללת התקנה של אפליקציית הייצור או של אפליקציית בדיקה שמשתמשת בספרייה או במנוע שלכם באמצעות Google Play או אמצעים אחרים במכשיר או באמולטור שמופעלים באמצעות Android 17 Beta 4. בודקים את כל התהליכים באפליקציה ומחפשים בעיות פונקציונליות או בעיות בממשק המשתמש. כל גרסה של Android כוללת שינויים בפלטפורמה שמשפרים את הפרטיות, האבטחה וחוויית המשתמש הכוללת. כדי להתמקד בבדיקות, כדאי לעיין בשינויים בהתנהגות שמשפיעים על אפליקציות שפועלות ב וב-Android 17 שמיועדות ל, כולל השינויים הבאים:

• שינוי גודל במסכים גדולים: אחרי שמגדירים את גרסת היעד ל-Android 17, אי אפשר יותר לבטל את ההגבלות על כיוון, שינוי גודל ויחס גובה-רוחב במסכים גדולים.
• טעינה דינמית של קוד: אם האפליקציה מטרגטת את Android 17 ואילך, ההגנה על טעינה דינמית של קוד (DCL) שהושקה ב-Android 14 עבור קובצי DEX ו-JAR, חלה עכשיו גם על ספריות Native. כל הקבצים המקוריים שנטענו באמצעות System.load() חייבים להיות מסומנים כקריאה בלבד. אחרת, המערכת תציג את השגיאה UnsatisfiedLinkError.
• הפעלה של CT כברירת מחדל: שקיפות אישורים (CT) מופעלת כברירת מחדל. (ב-Android 16, התכונה CT זמינה, אבל האפליקציות צריכות להצטרף).
• אמצעי הגנה על הרשת המקומית: באפליקציות שמטרגטות ל-Android 17 ואילך, הגישה לרשת המקומית חסומה כברירת מחדל. אם אפשר, כדאי לעבור לשימוש בכלי בחירה ששומרים על הפרטיות, ולהשתמש בהרשאה החדשה ACCESS_LOCAL_NETWORK לגישה רחבה ומתמשכת.
• הגברת האבטחה של אודיו ברקע: החל מ-Android 17, מסגרת האודיו אוכפת הגבלות על אינטראקציות עם אודיו ברקע, כולל הפעלת אודיו, בקשות למיקוד אודיו וממשקי API לשינוי עוצמת הקול. על סמך המשוב שקיבלנו, ביצענו כמה שינויים מאז גרסת בטא 2, כולל הגבלת הגישה ל-targetSDK בזמן האכיפה של FGS בשימוש, ופטור מאודיו של אזעקה. פרטים מלאים זמינים בהנחיות המעודכנות.

מגבלות זיכרון של אפליקציות

מערכת Android מציגה מגבלות על הזיכרון של האפליקציות בהתבסס על זיכרון ה-RAM הכולל של המכשיר כדי ליצור סביבה יציבה ודטרמיניסטית יותר לאפליקציות ולמשתמשי Android. ב-Android 17, המגבלות מוגדרות באופן שמרני כדי ליצור קווי בסיס למערכת, במטרה לזהות דליפות זיכרון קיצוניות וחריגות אחרות לפני שהן גורמות לחוסר יציבות במערכת כולה, שמוביל לגמגום בממשק המשתמש, לניקוז מוגבר של הסוללה ולסגירה של אפליקציות. אנחנו צופים שההשפעה על רוב הביקורים באפליקציות תהיה מינימלית, אבל מומלץ לפעול לפי השיטות המומלצות הבאות לניהול הזיכרון, כולל הגדרת בסיס לזיכרון.

בהטמעה הנוכחית, getDescription ב- ApplicationExitInfo יכיל את המחרוזת MemoryLimiter אם האפליקציה שלכם הושפעה. אפשר גם להשתמש בפרופילים מבוססי טריגר עם TRIGGER_TYPE_ANOMALY כדי לקבל קובצי dump של ה-heap שנאספים כשמגיעים למגבלת הזיכרון.

כדי לעזור לכם למצוא דליפות זיכרון, ב-Android Studio Panda יש שילוב של LeakCanary ישירות ב-Android Studio Profiler כמשימה ייעודית, עם הקשר בתוך סביבת הפיתוח המשולבת (IDE) ושילוב מלא עם קוד המקור.

טביעת זיכרון קטנה יותר מתורגמת ישירות לביצועים חלקים יותר, לחיי סוללה ארוכים יותר ולחוויה איכותית בכל גורמי הצורה. בואו נבנה יחד עתיד מהיר ואמין יותר עבור הסביבה העסקית של Android!

טריגרים ליצירת פרופילים של חריגות באפליקציות

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

כדי לזהות בעיות בביצועי המערכת, כמו קריאות מוגזמות ל-binder ושימוש מוגזם בזיכרון, אפשר להשתמש בטריגר TRIGGER_TYPE_ANOMALY. כשחריגה של אפליקציה ממגבלות הזיכרון שמוגדרות במערכת ההפעלה מפעילה את האנומליה, המפתחים יכולים לקבל תמונות מצב של הזיכרון שספציפיות לאפליקציה. כך הם יכולים לזהות בעיות בזיכרון ולפתור אותן. בנוסף, במקרה של ספאם מוגזם ב-Binder, טריגר החריגה מספק תמונת מצב של דגימת ערימה בטרנזקציות של Binder.

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

    val profilingManager = applicationContext.getSystemService(ProfilingManager::class.java)
    val triggers = ArrayList<ProfilingTrigger>()  
    triggers.add(ProfilingTrigger.Builder(
                 ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
    val mainExecutor: Executor = Executors.newSingleThreadExecutor()
    val resultCallback = Consumer<ProfilingResult> { profilingResult ->
        if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
            // upload profile result to server for further analysis          
            setupProfileUploadWorker(profilingResult.resultFilePath)
        } 
    profilingManager.registerForAllProfilingResults(mainExecutor, resultCallback)
    profilingManager.addProfilingTriggers(triggers)
}

הצפנה פוסט-קוונטית (PQC) ב-Android Keystore

ב-Android Keystore נוספה תמיכה ב-ML-DSA (אלגוריתם חתימה דיגיטלית מבוסס רשת מודולים) שעבר סטנדרטיזציה על ידי NIST. במכשירים נתמכים, אפשר ליצור מפתחות ML-DSA ולהשתמש בהם כדי ליצור חתימות חסינות מפני פיצוח קוונטי, והכול בחומרה המאובטחת של המכשיר. מאגר המפתחות של Android חושף את וריאציות האלגוריתם ML-DSA-65 ו-ML-DSA-87 דרך ממשקי ה-API של ארכיטקטורת ההצפנה הסטנדרטית של Java: ‏ KeyPairGenerator,‏ KeyFactory ו- Signature. פרטים נוספים מופיעים במסמכי התיעוד למפתחים.

KeyPairGenerator generator = KeyPairGenerator.getInstance(
        “ML-DSA-65”, "AndroidKeyStore");
generator.initialize(
        new KeyGenParameterSpec.Builder(
                “my-key-alias”,
                KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY)
        .build());
KeyPair keyPair = generator.generateKeyPair();

איך מתחילים להשתמש ב-Android 17

אתם יכולים לרשום כל מכשיר Pixel נתמך כדי לקבל את העדכון הזה ועדכוני בטא עתידיים של Android דרך OTA. אם אין לכם מכשיר Pixel, אתם יכולים להשתמש בקובצי אימג' של מערכת 64 ביט עם אמולטור Android ב-Android Studio.

אם אתם משתתפים כרגע בתוכנית Android Beta, תוצע לכם אפשרות לעדכן את המכשיר לגרסת בטא 4 באמצעות עדכון אלחוטי (OTA).

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

כדי ליהנות מחוויית הפיתוח הטובה ביותר עם Android 17, מומלץ להשתמש בגרסת הטרום-השקה (Preview) העדכנית של Android Studio (Panda). אחרי ההגדרה, כדאי לבצע את הפעולות הבאות:

• קומפילציה מול ה-SDK החדש, בדיקה בסביבות CI ודיווח על בעיות בכלי למעקב אחר בעיות בדף המשוב.
• בודקים את התאימות של האפליקציה הנוכחית, בודקים אם האפליקציה מושפעת משינויים ב-Android 17, מתקינים את האפליקציה במכשיר או באמולטור עם Android 17 ומבצעים בדיקות מקיפות.

אנחנו נעדכן את תמונות המערכת של גרסת הבטא או התצוגה המקדימה ואת ה-SDK באופן קבוע במהלך מחזור הפרסום של Android 17. אחרי שמתקינים build של גרסת בטא, מקבלים באופן אוטומטי עדכונים עתידיים דרך האוויר לכל גרסאות הטרום-השקה וגרסאות הבטא הבאות.

מידע מלא זמין באתר למפתחים של Android 17.

הצטרפות לשיחה

המשוב שלכם הוא הנכס הכי חשוב שלנו. אם אתם משתמשים ראשונים בערוץ Canary או מפתחי אפליקציות שבודקים בגרסה Beta 4, כדאי לכם להצטרף לקהילות שלנו ולשלוח משוב. אנחנו מקשיבים.