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

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

אם אתם מפתחים Android SDK, ספרייה, כלי או מנוע משחקים ל-Android, חשוב מאוד שתכינו עכשיו את כל העדכונים הנדרשים כדי למנוע ממפתחי אפליקציות ומשחקים שמשתמשים במוצרים שלכם להיתקל בבעיות תאימות, וכדי לאפשר להם להשתמש בתכונות העדכניות ביותר של ה-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 לשינוי עוצמת הקול. על סמך המשוב שקיבלנו מכם, ביצענו כמה שינויים מאז גרסת הבטא השנייה, כולל הגבלת targetSDK בזמן האכיפה של FGS בשימוש והחרגת אודיו של אזעקה. פרטים מלאים זמינים בהנחיות המעודכנות.

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

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

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

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

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

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

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

כדי לזהות בעיות בביצועי המערכת, כמו קריאות מוגזמות ל-binder ושימוש מוגזם בזיכרון, אפשר להשתמש בטריגר TRIGGER_TYPE_ANOMALY. כשמגבלות הזיכרון שמוגדרות במערכת ההפעלה מופרות על ידי אפליקציה, טריגר האנומליה מאפשר למפתחים לקבל קובצי dump של ה-heap שספציפיים לאפליקציה, כדי לעזור להם לזהות ולתקן בעיות בזיכרון. בנוסף, במקרים של ספאם מוגזם ב-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 ב-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. אחרי שמתקינים גרסת בטא, מקבלים באופן אוטומטי עדכונים עתידיים דרך האוויר לכל גרסאות התצוגה המקדימה וגרסאות הבטא הבאות.

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

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

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