איך להכין את האפליקציה לשינויים ב-Android 17 שקשורים לשינוי גודל וכיוון

עם השקת Android 16 ב-2025, שיתפנו את החזון שלנו לסביבה עסקית של מכשירים שבה אפליקציות מתאימות את עצמן בצורה חלקה לכל מסך – בין אם מדובר בטלפון, במכשיר מתקפל, בטאבלט, במחשב, במסך של רכב או ב-XR. המשתמשים מצפים שהאפליקציות שלהם יפעלו בכל מקום. בין אם המשתמשים מבצעים כמה משימות בו-זמנית בטאבלט, פותחים מכשיר מתקפל כדי לקרוא בנוחות או מפעילים אפליקציות בסביבת ממשק מחשב, הם מצפים שממשק המשתמש ימלא את שטח המסך הזמין ויתאים את עצמו למנח המכשיר.

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

עכשיו, עם השקת גרסת הבטא של Android 17, אנחנו עוברים לשלב הבא במפת הדרכים שלנו לעיצוב רספונסיבי: ב-Android 17 (רמת API‏ 37) המפתחים לא יוכלו יותר לבטל את ההגבלות על כיוון ושינוי גודל במכשירים עם מסך גדול (sw > 600 dp). כשמטרגטים לרמת ה-API המיועדת 37, האפליקציה צריכה להיות מסוגלת להתאים את עצמה למגוון גדלים של מסכים.

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

מה משתנה ב-Android 17

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

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

הערה: כמו שצוין קודם לגבי Android 16, השינויים האלה לא חלים על מסכים קטנים מ-sw 600 dp או על אפליקציות שמסווגות כמשחקים על סמך הדגל android:appCategory. 

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

הכנת האפליקציה

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

בדיקת האפליקציה

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

משתמשים ב-Android 17 בטא 1 עם האמולטורים של Pixel Tablet ו-Pixel Fold ב-Android Studio, ומגדירים את targetSdkPreview = “CinnamonBun”. לחלופין, אתם יכולים להשתמש במסגרת תאימות על ידי הפעלת הדגל UNIVERSAL_RESIZABLE_BY_DEFAULT אם האפליקציה שלכם עדיין לא מטרגטת את רמת ה-API המיועדת 36.

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

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

בואו נראה כמה אסטרטגיות לטיפול בבעיות הנפוצות האלה.

איך מוודאים שהמצלמה תואמת

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

מוודאים שהתצוגה המקדימה של המצלמה לא מתוחה או מסובבת.

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

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

פתרון 1: Jetpack CameraX (מועדף) 

הפתרון הפשוט והיציב ביותר הוא להשתמש בספריית Jetpack CameraX. רכיב ממשק המשתמש PreviewView מיועד לטפל באופן אוטומטי בכל המורכבות של התצוגה המקדימה:

• PreviewView מבצעת התאמה נכונה של כיוון החיישן, סיבוב המכשיר ושינוי קנה המידה
• ‫PreviewView שומר על יחס הגובה-רוחב של התמונה מהמצלמה, בדרך כלל על ידי מרכוז וחיתוך (FILL_CENTER)
• אפשר להגדיר את סוג קנה המידה לערך FIT_CENTER כדי להציג את התצוגה המקדימה בפורמט Letterbox, אם צריך

מידע נוסף זמין במאמר הטמעת תצוגה מקדימה במסמכי התיעוד של CameraX.

פתרון 2: CameraViewfinder 

אם אתם משתמשים בבסיס קוד קיים של Camera2, הספרייה CameraViewfinder (תואמת לדורות קודמים עד רמת API‏ 21) היא פתרון מודרני נוסף. הוא מפשט את הצגת פיד המצלמה באמצעות TextureView או SurfaceView ומחיל את כל הטרנספורמציות הנדרשות (יחס גובה-רוחב, קנה מידה וסיבוב).

מידע נוסף זמין בפוסט בבלוג Introducing Camera Viewfinder ובמדריך למפתחים Camera preview.

פתרון 3: הטמעה ידנית של Camera2 

אם אתם לא יכולים להשתמש ב-CameraX או ב-CameraViewfinder, אתם צריכים לחשב באופן ידני את הכיוון ואת יחס הגובה-רוחב, ולוודא שהחישובים מתעדכנים בכל שינוי בהגדרות האישיות:

• מקבלים את כיוון חיישן המצלמה (לדוגמה, 0, 90, 180, 270 מעלות) מ-CameraCharacteristics
• לקבל את כיוון התצוגה הנוכחי של המכשיר (לדוגמה, 0, 90, 180, 270 מעלות)
• משתמשים בכיוון של חיישן המצלמה ובערכי הסיבוב של התצוגה כדי לקבוע את הטרנספורמציות הנדרשות ל-SurfaceView או ל-TextureView
• כדי למנוע עיוותים, חשוב לוודא שיחס הגובה-רוחב של הפלט Surface תואם ליחס הגובה-רוחב של התצוגה המקדימה של המצלמה.

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

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

פתרון 4: ביצוע פעולות בסיסיות במצלמה באמצעות Intent 

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

מידע נוסף זמין במאמר Camera intents.

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

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

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

יכול להיות שהגדרתם לחצנים, שדות טקסט וכרטיסים לערכים fillMaxWidth או match_parent.  בטלפון, זה נראה נהדר. עם זאת, בטאבלט או במכשיר מתקפל במצב לרוחב, הרכיבים בממשק המשתמש נמתחים על פני כל המסך הגדול. ב-Jetpack Compose, אפשר להשתמש במשנה widthIn כדי להגדיר רוחב מקסימלי לרכיבים, וכך למנוע מתיחה של התוכן:

Box(
    contentAlignment = Alignment.Center,
    modifier = Modifier.fillMaxSize()
) {
    Column(
        modifier = Modifier
            .widthIn(max = 300.dp) // Prevents stretching beyond 300dp
            .fillMaxWidth()        // Fills width up to 300dp
            .padding(16.dp)
    ) {
        // Your content
    }
}

אם משתמש פותח את האפליקציה שלכם במצב לרוחב במכשיר מתקפל או בטאבלט, יכול להיות שכפתורי פעולה כמו שמירה או התחברות בתחתית המסך יוצגו מחוץ למסך. אם אי אפשר לגלול את הקונטיינר, המשתמש לא יוכל להמשיך. ב-Jetpack Compose, אתם יכולים להוסיף לרכיב את המשתנה verticalScroll:

Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(rememberScrollState())
        .padding(16.dp)
)

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

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

שמירת המצב עם שינויים בהגדרות האישיות

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

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

מומלץ לעיין במדריך שלנו בנושא שמירת מצב ממשק המשתמש.

טירגוט לרמת ה-API המיועדת 37 עד אוגוסט 2027

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

• ‫Android 17: השינויים שמתוארים למעלה יהיו חוויית השימוש הבסיסית במכשירים עם מסך גדול (רוחב המסך הקטן ביותר > 600dp) באפליקציות שמטרגטות ל-API ברמה 37. למפתחים לא תהיה אפשרות לבטל את ההסכמה.

המועדים האחרונים לטירגוט של רמת API ספציפית משתנים בהתאם לחנות האפליקציות. ב-Google Play, אפליקציות חדשות ועדכונים יידרשו לטרגט לרמת ה-API המיועדת 37, כך שההתנהגות הזו תהיה חובה להפצה באוגוסט 2027.

הכנה לקראת Android 17

בדף השינויים ב-Android 17 מפורטים כל השינויים שמשפיעים על אפליקציות ב-Android 17. כדי לבדוק את האפליקציה, צריך להוריד את גרסת הבטא הראשונה של Android 17 ולעדכן לגרסה targetSdkPreview = “CinnamonBun” או להשתמש במסגרת התאימות של האפליקציה כדי להפעיל שינויים ספציפיים.

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

אל תחכו. התחילו להתכונן ל-Android 17 כבר היום!