עם ההשקה של 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 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 מתבצעת התאמה נכונה של כיוון החיישן, סיבוב המכשיר והקנה מידה
• ‫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, אפשר להשתמש ב-modifier‏ 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 כבר היום.