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

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

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

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

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

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

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

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

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

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

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

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

פתרון 1: Jetpack CameraX (מומלץ) 

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

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

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

פתרון 2: CameraViewfinder 

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

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

פתרון 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 Beta 1 ולעדכן לגרסה targetSdkPreview = “CinnamonBun” או להשתמש במסגרת התאימות של האפליקציה כדי להפעיל שינויים ספציפיים.

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

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