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

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

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

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

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

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

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

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

טירגוט לרמת 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 כבר היום.