Google Play תאלץ בקרוב מפתחים להעלות חבילות App Bundles במקום APKs, מה שמעלה שאלות אבטחה לא נוחות לגבי הדרישה.
נובמבר האחרון, הודיעה גוגל כי מפתחים יידרשו לפרסם אפליקציות חדשות בחנות Play באמצעות פורמט Android App Bundle (AAB) במקום APK. רק לפני כמה ימים, גוגל הזכירה למפתחים את הדרישה הקרובה הזו, ועוררה סופת אש של מחלוקת ממשתמשים שמאמינים שגוגל הורגת חבילות APK, מבטלת טעינת צד, מעכבת חנויות אפליקציות של צד שלישי ו מה לא.
זה נכון ש-Android App Bundles הם סטייה די גדולה מפורמט ה-APK הקלאסי שאולי רגילים אליו, גם כמשתמש וגם כמפתח. אמנם יש לא מעט יתרונות לשימוש בחבילות App Bundles, אבל יש היבט אחד מרכזי בהכנתם שכמה מפתחים ומומחי אבטחה מודאגים בו בצדק.
במאמר זה נסקור את הביקורות שראינו על המעבר ל-Android App Bundles וכן כמה פתרונות מוצעים, ונדבר גם על הפתרון המוצע של גוגל לבעיות אלו.
רקע כללי
לפני שזה יקרה, אנחנו צריכים לדבר קצת על איך הפצת אפליקציות עובדת באנדרואיד באופן כללי. אם אתה כבר יודע כיצד פועלים חתימת אפליקציות וחבילות אפליקציות, תוכל לדלג על החלק הזה.
חבילות APK
לרוב, אפליקציות באנדרואיד מופצות בתוך קבצי APK. APK מכיל את כל הקוד והמשאבים של האפליקציה, יחד עם כמה תכונות אבטחה כמו מניפסט חתימה. כאשר APK מותקן, הוא בעצם פשוט מועתק לתיקיה ספציפית ומתווסף למסד נתונים פנימי של אפליקציות מותקנות.
חתימות
במהלך ההתקנה, החתימה של אפליקציה זו מאומתת גם כדי לוודא שהיא חוקית. אם האפליקציה כבר מותקנת, אנדרואיד בודק את החתימה של האפליקציה החדשה מול זו שכבר מותקנת. אם החתימה לא חוקית או לא תואמת, אנדרואיד תסרב להתקין את האפליקציה.
בדיקת חתימות היא חלק חשוב מאבטחה באנדרואיד. זה מוודא שהאפליקציה שאתה מתקין חוקי ולפחות מאותו מקור כמו זה שכבר התקנת. לדוגמה, אם אתה מתקין, נניח, אפליקציית Widgets מסך הנעילה שלי מחנות Play, אתה יכול להיות בטוח למדי שאני זה שחתמתי עליו ושהיא אותנטית. אם לאחר מכן תנסה להתקין עדכון ל- Lockscreen Widgets מאתר צד שלישי מפוקפק והוא נכשל, תדע שמישהו התעסק ב-APK הזה, אולי כדי להוסיף תוכנות זדוניות.
המפתח המשמש לחתימה על אפליקציה הוא (אידיאלי) לעולם לא שוחרר בפומבי. זה ידוע בתור המפתח הפרטי. המפתח הפרטי משמש לאחר מכן ליצירת המפתח המוצג בחתימת האפליקציה, המכונה המפתח הציבורי. זה מה שחנויות אנדרואיד ואפליקציות משתמשות בו כדי לאמת את תקפות האפליקציה. אני לא אכנס לאופן שבו בדיוק אתה יכול ליצור מפתח ציבורי מבלי לחשוף את המפתח הפרטי, מכיוון שזה כרוך בהרבה מתמטיקה של הצפנה. אם אתה רוצה פרטים נוספים, בדוק התיעוד של גוגל על חתימת APKs או לעשות מחקר על פונקציות מתמטיות חד-כיווניות.
תכונה נוספת של חתימות אפליקציות היא היכולת להגביל הרשאות רק לאפליקציות עם חתימות תואמות. אנדרואיד עושה זאת באופן פנימי עבור הרבה פונקציות, כאשר רק אפליקציות חתומות עם אותו מפתח כמו המסגרת יכולות לגשת לתכונות מסוימות.
App Bundles
אז עכשיו, לאחר שנתנו סקירה מהירה של APKs וחתימות, בואו נדבר על App Bundles. כאן נכנסים משאבי APK. משאבים הם דברים כמו פריסות, תמונות, אודיו וכו'. בעיקרון, הם כל דבר שהוא לא קוד. כדי לתמוך טוב יותר בתצורות תצוגה שונות ובשפות שונות, מפתחים יכולים ליצור גרסאות מרובות של אותו משאב המשמשות בהתאם למכשיר ולשפה.
אבל ב-APK, כל המשאבים האלה קיימים, לא משנה באיזה אתה משתמש. והם תופסים מקום. בהתאם למורכבות האפליקציה שלך, עשויים להיות משאבים רבים שאינם בשימוש עבור הרבה מכשירים. זה מה ש-App Bundles נועדו לפתור. מפתחים יכולים ליצור App Bundle בדיוק כמו APK, ולאחר מכן ניתן להעלות את ה-App Bundle לחנות Play, בדיוק כמו APK.
לאחר מכן גוגל משתמשת ב-App Bundle הזה כדי ליצור חבורה שלמה של חבילות APK שונות עבור תצורות מכשירים שונות. כל App Bundle מכיל רק את המשאבים הדרושים לאותה תצורה. כאשר משתמש הולך להוריד את האפליקציה הזו, יוגש לו ה-APK שנוצר שתואם את התצורה שלו. זה עוזר להפחית הן את הורדת האפליקציה והן את גדלי ההתקנה, וחוסך רוחב פס ושטח אחסון.
כמובן, התקנת APK ספציפי למכשיר שלך פירושה שקשה לך יותר פשוט להעתיק אותו למכשיר אחר ולהתקין אותו ללא בעיה. בהתאם לנקודת המבט שלך, זה יכול להיות דבר טוב או רע. מצד אחד, זה מקשה על פיראטיות, מכיוון שלמשתמשים אין יותר את כל האפליקציה. מצד שני, זה מקשה על אחסון אפליקציות לארכיון לגיטימי, מאותה סיבה.
חתימת אפליקציה
מכיוון שחבילות אפליקציות אנדרואיד אינן חבילות APK, אינך יכול פשוט לפתוח קובץ AAB ולהתקין אותו ישירות במכשיר. כאשר אתה מעלה אחד לחנות Play, Google משתמשת בחבילה כדי ליצור קבצי APK שונים (לא חתומים). לאחר מכן יש לחתום על חבילות APK אלה לפני שניתן יהיה להתקין אותן.
במקום לבקש מהמפתח לחתום ולהעלות מחדש את חבילות ה-APK שנוצרו, Google מנהלת את החתימה בעצמה. חנות Play משתמשת במפתח חדש שהיא יוצרת או מבקשת מהמפתח את המפתח שבו הם משתמשים כדי לחתום חבילות APK. בכל אחת מהאפשרויות, Google מטפלת בחתימה הציבורית עבור המפתח ומספקת העלאה מַפְתֵחַ. גוגל משתמשת במפתח ההעלאה לצורך אימות פנימי ומוודאת שה-App Bundle (או ה-APK במקרים מסוימים) שהמפתח מעלה הוא הנכון.
אם מפתח העלאה נפרץ או אבד, מפתחים יכולים לבקש מפתח חדש, ומפתח החתימה המשמש להפצת האפליקציה נשאר ללא שינוי.
יש הרבה יותר בחתימת אפליקציות, אבל זה מה שרלוונטי למאמר זה. אם תרצה, תוכל לקרוא עוד על חבילות אפליקציות וכניסה לאפליקציות מאמר בינוני זה מאת Wojtek Kaliciński.
ביקורת
בתיאוריה ובפועל, App Bundles הם די מעולים. הם מפחיתים את השימוש בנתונים וגודל ההתקנה, כל זאת מבלי שהמשתמש יצטרך לעשות דבר. אבל בגלל האופן שבו זה מיושם, כמה מפתחים וחוקרי אבטחה בחודשים האחרונים העלו חששות. לפני שאסכם את החששות האלה, אני רוצה להקדיש רגע לומר שרוב מה שכתוב למטה הוא ישירות מבוסס על סדרת מאמרים מאת המפתח מארק מרפי מ CommonsWare. אתה בהחלט צריך לבדוק את המאמרים שלו, מכיוון שהם מספקים יותר פרטים וביקורות מנקודת המבט של מפתח.
בִּטָחוֹן
במודל ההפצה הקלאסי, מפתח שומר את המפתח שבו הוא משתמש כדי לחתום על APK פרטי. זה אף פעם לא משותף לציבור ורק לאנשים מורשים צריכה להיות גישה אליו. זה מבטיח שרק אותם אנשים יכולים ליצור APK חוקי.
אבל אם אתה משתמש ב-App Bundles בחנות Play, Google היא זו שמנהלת את המפתח שחותם על חבילות ה-APK שמשתמשים מקבלים. ה בְּרִירַת מֶחדָל התנהגות עבור אפליקציות חדשות שהועלו ל-Google Play החל מאוגוסט 2021 הוא ש-Google תיצור מפתח הפצה משלה, אותו היא שומרת פרטית מהמפתח.
מפתחים שולחים אפליקציות חדשות יגרום ל-Google לנהל עבורם את המפתח הפרטי שלהם כברירת מחדל, למרות שמפתחים שולחים עדכונים ל אפליקציות קיימות יכול להמשיך להשתמש ב-APKs אוֹ הם יכולים לעבור להפצת AAB על ידי יצירת מפתח חדש עבור Google לשימוש עבור משתמשים חדשים. אפליקציות קיימות אינם נדרשים לעבור מהפצת APK ל-Android App Bundles, אם כי אפשרות זו זמינה עבורם אם יבחרו. אחרי קצת דחיקה, גוגל אפילו יאפשר את זה להעלות מפתח פרטי משלך ש-Google תוכל לחתום איתו, הן עבור אפליקציות חדשות והן עבור אפליקציות קיימות. אף אחד מהמצבים הללו אינו אידיאלי, שכן לא משנה מה, לגוגל תהיה גישה למפתח הפרטי שלך אם תרצה בכך השתמש ב-Android App Bundles (ולמפתחים אין ברירה בעניין אם הם רוצים להגיש אפליקציה חדשה לאחר אוגוסט 2021!)
למרות שאנו בטוחים שגוגל מתייחסת לאבטחה ברצינות רבה, אין חברה בכדור הארץ שחסינה מפני פרצות מידע. אם המפתח שגוגל משתמשת בו כדי לחתום על האפליקציה שלך להפצה נמצא באחת מההפרות הללו, כל אחד יכול לחתום על גרסה של האפליקציה שלך ולגרום לה להיראות כאילו היא נחתמה על ידך. וכמה מפתחים ומומחי אבטחה לא מרוצים מהאפשרות הזו. זו אפשרות מאוד מאוד קלושה, כן, אבל העובדה שזו אפשרות בכלל מפחידה חלק מקהילת ה-infosec.
קבלת מפתחים לחתום על APKs של Android פירושה שכל אחד יכול לאמת APKs מ-Google Play, אין צורך באמון עיוור. זהו עיצוב אלגנטי המספק אבטחה ניתנת לאימות. חבילות אפליקציות הופכות את זה על הראש, ונראות בנויות כדי לקדם נעילה של ספקים. ישנן גישות טכניות חלופיות רבות שיספקו חבילות APK קטנות שעדיין חתומות על ידי מפתחים, אך אלה לא יעדיפו את Play. לדוגמה, כל גרסאות ה-APK יכולות להיווצר ולחתום על ידי המפתח, ולאחר מכן להעלות אותן לכל חנות אפליקציות.
בהחלט יש ויכוחים אם עדיף להשאיר את האחסון המאובטח של מפתחות פרטיים בידי גוגל או מפתחים בודדים. אבל אותם מפתחים (כנראה) אינם משתמשים בדרך כלל במאגר מרכזי עבור המפתחות שלהם. על ידי אילוץ מפתחים להשתמש ב-Play App Signing, תוקף זדוני צריך להפר את האבטחה של Google רק פעם אחת כדי לאחזר אלפי או מיליוני מפתחות.
בשביל מה זה שווה, הנה מה שגוגל אומרת על האופן שבו היא מגינה על מפתח החתימה שלך על התשתית שלה:
[blockquote author="Wojtek Kaliciński, Android Developer Advocate at Google"]כאשר אתה משתמש ב-Play App Signing, המפתחות שלך מאוחסנים באותה תשתית ש-Google משתמשת בה כדי לאחסן את המפתחות שלה.
גישת מפתח נשלטת על ידי ACL קפדניים ומסלולי ביקורת ברורים לכל הפעולות.
כל החפצים שנוצרו ונחתמו עם המפתח של המפתח זמינים לך ב-Google Play Console לבדיקה/אישור.
יתר על כן, כדי למנוע אובדן מפתח, אנו עורכים גיבויים תכופים מאוד של האחסון הראשי שלנו. גיבויים אלו מוצפנים היטב ואנו בודקים באופן קבוע שחזור מגיבויים אלו.
אם אתה רוצה ללמוד על התשתית הטכנית של גוגל, קרא את ה מסמכי אבטחת ענן של Google.[/blockquote]
עד כמה שכל הצלילים, האובדן והגניבה עדיין אפשריים. ומסלולי ביקורת רק עוזרים למנוע התקפות עתידיות; הם לא יקבלו בחזרה מפתחות שנפרצו.
פוטנציאל לשינויים לא מורשים
בעיה אחת גדולה בדרך שבה גוגל הגדירה חבילות אפליקציות היא הפוטנציאל להוספת שינויים לא מורשים לאפליקציה. תהליך חילוץ APKs מ-App Bundle כרוך מטבעו בשינויים, מכיוון שגוגל צריכה לבנות כל APK באופן ידני. בזמן גוגל הבטיחה שהיא לא תכניס ולא תשנה קוד, הבעיה בתהליך ה-App Bundle היא שיש לו את הכוח לעשות זאת.
הנה כמה דוגמאות למה שיש לחברה בעמדה של גוגל לעשות:
נניח שיש אפליקציית הודעות מאובטחת שאנשים משתמשים בה כדי לתקשר ללא סיכון של מעקב ממשלתי. זה יכול להיות כלי שימושי להפליא לאנשים שמוחים על ממשלה סמכותית, או אפילו אנשים שרק רוצים לשמור על הפרטיות שלהם. הממשלה הזו, שרוצה את היכולת לראות מה משתמשי האפליקציה אומרים, יכולה לנסות לכפות על גוגל להוסיף דלת אחורית למעקב לקוד האפליקציה.
הדוגמה הזו קצת יותר תמימה, אבל זה גם משהו שמעסיק אנשים מסוימים. נניח שיש אפליקציה שמקבלת מיליוני הורדות ביום, אבל אין בה שום מודעות או ניתוח נתונים. זהו מקור נתונים ענק ללא דרך לגשת לנתונים האלה. גוגל, בהיותה חברת פרסום, אולי תרצה לגשת לנתונים האלה.
במודל ה-APK הקלאסי של הפצת אפליקציות, גוגל לא יכולה לשנות את האפליקציות מבלי לשנות את החתימה. אם גוגל משנה את החתימה, במיוחד באפליקציה פופולרית, אנשים ישימו לב כי העדכון לא יותקן. אבל עם חבילות אפליקציות וחתימת אפליקציות, גוגל יכולה להחדיר בשקט קוד משלה לאפליקציות לפני הפצתן. החתימה לא תשתנה מכיוון ש-Google תהיה הבעלים של מפתח החתימה.
שיהיה ברור, אין סבירות להפליא שהדוגמאות האלה יקרו. גוגל נוטה פשוט לצאת מהשווקים הבעייתיים לגמרי, במקום להסתגל. אבל למרות שזה לא סביר, זה עדיין אפשרי. רק בגלל שחברה מבטיחה שמשהו לא יקרה, זה לא מבטיח את זה.
שקיפות קוד
גוגל, כששמעה את החששות הללו, הציגה השבוע תכונה חדשה בשם שקיפות קוד עבור App Bundles. שקיפות קוד מאפשרת למפתח ליצור בעצם חתימה שנייה שנשלחת עם האפליקציה למשתמשים. יש ליצור חתימה נוספת זו ממפתח פרטי נפרד שרק למפתח יש גישה אליו. עם זאת, ישנן מספר מגבלות לשיטה זו.
שקיפות קוד מכסה רק קוד. זה אולי נראה מובן מאליו בהתחשב בשם, אבל זה גם אומר שזה לא מאפשר למשתמשים לאמת משאבים, את המניפסט או כל דבר אחר שאינו קובץ DEX או ספרייה מקורית. בעוד שלשינויים זדוניים בקבצים שאינם קוד יש בדרך כלל הרבה פחות השפעה, זה עדיין חור באבטחה של האפליקציה.
בעיה נוספת עם שקיפות קוד היא שאין אימות מובנה. לאחד, זו תכונה אופציונלית, אז מפתחים צריכים לזכור לכלול אותו עבור כל APK חדש שהם מעלים. כרגע, זה צריך להיעשות משורת הפקודה ועם גרסה של bundletool זה לא מגיע עם Android Studio. גם כאשר מפתח כולל את זה, לאנדרואיד אין שום סוג של אימות מובנה כדי לבדוק שהמניפסט של שקיפות הקוד תואם לקוד באפליקציה.
על משתמש הקצה לבדוק בעצמו על ידי השוואת המניפסט מול מפתח ציבורי שהמפתח יכול לספק, או על ידי שליחת ה-APK למפתח לאימות.
בעוד שקיפות קוד מאפשרת אישור ששום קוד באפליקציה לא שונה, היא לא כוללת אימות כלשהו עבור חלקים אחרים של אפליקציה. אין גם אמון מובנה בתהליך. אתה יכול לטעון שאם אתה לא בוטח בגוגל, כנראה שאתה עומד במשימה של אימות עצמאי, אבל למה אתה צריך?
ישנן בעיות נוספות בתכונת שקיפות הקוד, כמו ציין מאת מארק מרפי מ CommonsWare. אני ממליץ לקרוא את המאמר שלו לניתוח מעמיק יותר של התכונה.
נוחות ובחירה למפתחים
סיבה שלישית (ואחרונה למאמר זה) שחלק מהמפתחים מתמודדים עם חבילות אפליקציות היא נוחות ובחירה מופחתת.
אם מפתח יוצר אפליקציה חדשה בחנות Play לאחר שגוגל מתחילה לדרוש חבילות אפליקציות והוא יבחר אפשרות ברירת המחדל לאפשר ל-Google לנהל את מפתח החתימה, לעולם לא תהיה להם גישה לחתימה הזו מַפְתֵחַ. אם אותו מפתח ירצה להפיץ את האפליקציה הזו בחנות אפליקציות אחרת, הם יצטרכו להשתמש במפתח משלהם, שלא יתאים לזה של גוגל.
המשמעות היא שמשתמשים יצטרכו להתקין ולעדכן מ-Google Play או ממקורות צד שלישי. אם הם רוצים לשנות את המקור, עליהם להסיר לחלוטין את האפליקציה, שעלול לאבד נתונים, ולהתקין מחדש. צוברי APK אוהבים APKMirror אז יצטרך להתמודד גם עם חתימות רשמיות מרובות עבור אותה אפליקציה. (טכנית, הם כבר צריכים לעשות זאת מכיוון ש-App Signing מאפשר לך ליצור מפתח חדש ומאובטח יותר, עבור משתמשים חדשים, אבל זה יהיה גרוע יותר עבורם ואתרים אחרים כאשר כולם יש ל לעשות זאת.)
התגובה של Google לבעיה זו היא להשתמש ב-App Bundle Explorer או ב-Artifact Explorer ב-Play Console כדי להוריד את חבילות ה-APK שהתקבלו מהחבילה שהועלתה. בדומה לשקיפות קוד, זה לא פתרון מלא. חבילות ה-APK שיורדו מ-Play Console יפוצלו עבור פרופילי מכשירים שונים. בעוד שה-Play Console אכן תומך בהעלאת חבילות APK מרובות עבור גרסה אחת של אפליקציה אחת, ערוצי הפצה רבים אחרים אינם עושים זאת.
לפיכך, הרבה מהיתרונות של שימוש ב-App Bundles נעלמים כאשר מפתחים מנהלים מספר חנויות, מה שמקשה על ההפצה. עם חדשות זה Windows 11 הוא זוכה לתמיכה באפליקציית אנדרואיד הודות ל-Amazon Appstore, יש המאמינים שדרישת ה-App Bundles תמנע מפתחים מלהפיץ באמזון. כמובן, הדאגה העיקרית של גוגל היא עם חנות האפליקציות שלה, אבל זה בדיוק מה הנחית אותם למים חמים עם מתחרים מוביל אותם לעשות שינויים קטנים ומפשרים לאופן שבו פועלות חנויות אפליקציות של צד שלישי באנדרואיד.
כמה בעיות הקשורות למספר חנויות הן קישוריות בין אפליקציות ובדיקות אש מהירה.
בואו נתחיל עם קישוריות בין אפליקציות. האם אי פעם הורדת אפליקציה שנועלת תכונות מאחורי חומת תשלום? כמעט בהחלט. חלק מהמפתחים שמים את התכונות מאחורי רכישה בתוך האפליקציה, אך אחרים עשויים לבחור ליצור אפליקציה נפרדת בתשלום. כאשר אפליקציית ההרחבה הזו מותקנת, תכונות האפליקציה הראשיות לא נעולות.
אבל מה מונע ממישהו פשוט להתקין את התוסף ממקור פיראטי? ובכן, יש הרבה אפשרויות למפתחים, אבל לפחות אחת כוללת שימוש בהרשאות מוגנות חתימה. נניח שהאפליקציה הראשית מצהירה על הרשאה מוגנת חתימה. לאחר מכן, אפליקציית התוסף מצהירה שהיא רוצה להשתמש בהרשאה זו. באופן אידיאלי, לאפליקציית התוסף תהיה גם פונקציונליות כלשהי של אימות רישיון, שמתחברת לאינטרנט כדי לוודא שהמשתמש לגיטימי.
אם לשתי האפליקציות יש את אותה חתימה, אנדרואיד תעניק את ההרשאה לאפליקציית התוסף ובדיקות ההגנה על פיראטיות יעברו. אם לאפליקציית התוסף אין את החתימה הנכונה, ההרשאה לא תינתן והאימות ייכשל.
עם מודל הפצת ה-APK הקלאסי, משתמש יכול לקבל כל אחת מהאפליקציות מכל מקור לגיטימי ולסיים איתה. עם מודל ברירת המחדל הנוכחי של App Bundle, החתימות באפליקציות הראשיות והתוספות לא יתאימו. גוגל תיצור מפתח ייחודי לכל אפליקציה. המפתח תמיד יכול לבטל את ההרשאה המוגנת בחתימה ולהשתמש באימות hash ישיר של חתימה, אבל זה הרבה פחות מאובטח.
ואז יש בדיקות אש מהירה. משתמשים שולחים דוא"ל למפתחים כל הזמן לגבי בעיות באפליקציות שלהם. לפעמים הבעיות האלה הן תיקונים פשוטים: שחזר את הבעיה, מצא את הבעיה, תקן אותה והעלה גרסה חדשה. אבל לפעמים הם לא. לפעמים מפתחים לא יכולים לשחזר בעיה. הם יכולים לתקן את מה שהם חושבים שהבעיה, אבל אז המשתמש צריך לבדוק את זה. כעת נניח שהמשתמש התקין את האפליקציה דרך Google Play.
עם מודל ה-APK, מפתח יכול לשנות קוד כלשהו, לבנות ולחתום על APK חדש, ולשלוח אותו למשתמש לבדיקה. מכיוון שהחתימה של ה-APK לבדיקה תואמת לזה שהמשתמש התקין, זהו תהליך פשוט לעדכן, לבדוק ולדווח בחזרה. עם App Bundles, זה מתפרק. מכיוון שגוגל חותמת על ה-APK שהמשתמש התקין במקור, הוא לא יתאים לחתימה של ה-APK שהמפתח שולח. אם האפליקציה הזו מתפרסמת לאחר המועד האחרון ל-App Bundles, למפתח לא תהיה אפילו גישה למפתח ש-Google משתמשת בו. על מנת לבדוק, המשתמש יצטרך להסיר את ההתקנה של האפליקציה הנוכחית לפני התקנת גרסת הבדיקה.
יש פה המון בעיות. ראשית, יש אי נוחות, הן בצד המפתח והן בצד המשתמש. הצורך להסיר את האפליקציה רק כדי לבדוק תיקון זה לא כיף. ומה אם הבעיה תיעלם? האם אלה השינויים שהמפתח ביצע, או שמא בגלל שהמשתמש ניקה למעשה את נתוני האפליקציה? בחנות Play יש אמנם בדיקות פנימיות, שאמורות לאפשר למפתחים לבצע בנייה והפצה מהירה, אך היא מחייבת את המשתמש להסיר תחילה את גרסת המהדורה. זה לא באמת מתקן כלום.
למקרה שכל זה נשמע כמו חבורה של שטויות היפותטיות, הנה דוגמה אמיתית מאוד למפתח שיהיו לו את הבעיות האלה אם יתנו לגוגל לייצר עבורו מפתח פרטי: João Dias. הוא המפתח של Tasker, יחד עם חבורה שלמה של אפליקציות פלאגין, כולל חבילת AutoApps. עם דרישת ה-App Bundles החדשה, מחזור הפיתוח של João עשוי להיות מסובך הרבה יותר, לפחות עבור אפליקציות חדשות. שליחת גרסאות בדיקה ישירות תהיה פחות נוחה. אימות רישיונות יהיה פחות יעיל.
זה אולי נשמע כמו מקרה קצה, אבל זה לא שג'ואאו הוא איזה מפתח קטן, וסביר להניח שהוא לא לבד. יש הרבה אפליקציות בחנות Play המסתמכות על אימות חתימה כדי לזהות משתמשים לא לגיטימיים.
כמובן, עם האופציה החדשה למפתחים להעלות מפתחות חתימה משלהם לגוגל, הבעיות הללו לפחות במידת מה. אבל מפתחים צריכים להצטרף כדי להפעיל את האפשרות עבור כל אפליקציה. אם הם לא יצליחו, החיבורים יכשלו ותמיכה באש מהירה תדרוש העלאת חבילה ל-Google והמתנה ליצירת חבילות APK, לפני שליחת הקובץ הנכון למשתמש. בנוסף, זה עדיין אומר שהם צריכים לשתף את המפתח הפרטי שלהם, מה שמחזיר אותנו לחששות שדיברנו עליהם קודם לכן.
פתרונות
זו בעיה ישנה בהתחשב בדרישות ה-App Bundle פורסמו לפני חודשים, כך שהוצעו לא מעט פתרונות בינתיים.
פתרון אחד הוא להימנע מהצורך בחתימת אפליקציות Play. במקום ליצור App Bundle ש-Google מעבדת לאחר מכן ל-APKs וסימנים, העיבוד הזה יכול להתבצע על ידי Android Studio. לאחר מכן, מפתחים יכולים פשוט להעלות ZIP מלא של APKs עם חתימה מקומית עבור כל תצורה שגוגל הייתה מייצרת.
עם הפתרון הזה, גוגל כלל לא תצטרך גישה למפתחות של מפתחים. התהליך יהיה דומה מאוד למודל הפצת ה-APK הקלאסי, אך יכלול מספר חבילות APK, קטנות יותר, במקום רק אחד.
פתרון נוסף הוא פשוט לא לדרוש שימוש ב-App Bundles ולהמשיך לאפשר למפתחים להעלות חבילות APK עם חתימה מקומית. בעוד ש-App Bundles עשוי להיות חוויה טובה יותר עבור המשתמש במקרים רבים, אפליקציות מסוימות לא ממש נהנות מפיצול לפי תצורה, בגודל מינימלי צִמצוּם.
אם גוגל הטמיעה את שני הפתרונות הללו, מפתח שרוצה להשתמש ב-App Bundles לא יצטרך לתת מעבר לחתימה לגוגל, ומפתח שהאפליקציה שלו לא תרוויח הרבה מהפורמט לא יצטרך להשתמש בה ב- את כל.
התגובות של גוגל
חתימה עצמית
כאשר הם נשאלו לראשונה לגבי מתן אפשרות למפתחים לטפל בחתימה על חבילות אפליקציות, התגובה של גוגל הייתה מאוד לא מתחייבת:
[blockquote author=""]אז, דיברתי בקצרה על הדרישה בשנה הבאה מאפליקציות חדשות להשתמש ב-App Bundle, ודבר אחד שמגיע עם זה הוא שבהמשך נדרוש חתימת אפליקציות Play. אז מפתחים יצטרכו ליצור את מפתח חתימת האפליקציות ב-Play או להעלות מפתח משלהם ל-Play... כי זה תנאי מוקדם ל-App Bundles. שמענו ממפתחים שחלקם פשוט לא רוצים לעשות את זה. הם לא רוצים שמפתחות ינוהלו על ידי Play. וכרגע זה לא אפשרי אם אתה רוצה להשתמש ב-App Bundles.
אבל, שמענו את המשוב הזה, ו... אני לא יכול לדבר על שום דבר כרגע, אין לנו מה להכריז, אבל אנחנו בוחנים איך נוכל להקל על חלק מהחששות האלה. זה לא בהכרח צריך לאפשר לשמור את המפתח שלך בזמן העלאת חבילות. אנו בודקים אפשרויות שונות. פשוט אין לנו פתרון להכריז כרגע. אבל עדיין יש לנו כשנה עד לדרישה, אז אני מאוד מקווה שתהיה לנו תשובה למפתחים בעניין הזה.[/blockquote]
זה היה בסוף נובמבר בשנה שעברה, ונראה ששום דבר לא קרה. נותרו חודשים ספורים בלבד לפני דרישת ה-App Bundles נכנסת לתוקף, עדיין אין דרך למפתחים לטפל בחתימה על האפליקציות שלהם. בעוד שגוגל אפשרה כעת להעלות מפתח משלך עבור אפליקציות חדשות וקיימות, זה עדיין מוציא את חלק החתימה מידיו של המפתח.
שינויים בקוד
בעוד שגוגל הבטיחה במפורש שחנות Play לא תשנה את קוד האפליקציה, הבטחה אינה ערובה. עם חבילות אפליקציות וחתימת אפליקציות, אין מגבלה טכנית שאנו יודעים על כך שמונעת מ-Google לשנות אפליקציות שהועלו לפני ההפצה.
גוגל הציגה שקיפות קוד כתכונה אופציונלית, ולמרות שזה עוזר במקצת, יש לה חלק נכבד של בעיות, כפי שדיברנו קודם לכן.
חבילות תוצרת עצמית
כשגוגל נשאלה לגבי מתן אפשרות למפתחים ליצור "חבילות" (ZIPs המכילות APKs מפוצלים) משלהם, התגובה הייתה בעצם "אנחנו לא הולכים לעשות את זה":
כנראה שלא כפי שמתואר בשאלה, מכיוון שזה יקשה על תהליך הפרסום עוד יותר עבור מפתחים, ואנחנו בעצם רוצים להפוך אותו לפשוט ובטוח יותר. עם זאת, שוב, שמענו את המשוב הזה, ואנו נבדוק אפשרויות כיצד לאפשר זאת, אולם כנראה לא בצורה שתוארה כאן.
באופן מעניין, נראה שההצדקה של גוגל היא שזה יהפוך את הפרסום למסובך יותר. עם זאת, גוגל עדיין יכולה להפוך את התהליך לאוטומטי כחלק מתיבת הדו-שיח ליצירת APK ב-Android Studio. יתר על כן, אם האפליקציה המדוברת מופצת במספר חנויות, היא למעשה תעשה את ה תהליך הפרסום פשוט יותר, מכיוון שמפתחים לא יצטרכו לנהל מספר מפתחות חתימה ותלונות מ משתמשים.
ועם הכנסת הקוד שקיפות, נראה שסיבוך הוא לא בדיוק בעיה אחרי הכל. שקיפות קוד, לעת עתה לפחות, מחייבת את המפתח להשתמש בכלי שורת פקודה ולמשתמשים לאמת במפורש את תקפות האפליקציה שהם מגישים. זה יותר מסובך מתהליך לייצור עצמי של חבילות, ולא ברור למה זה הפתרון שגוגל מעדיפה.
הולך קדימה
חבילות אפליקציות יהיו פורמט ההפצה הנדרש עבור אפליקציות חדשות שיוגשו ל-Google Play החל מה-1 באוגוסט. בעוד שגוגל טיפלה לפחות במידת מה לרוב הבעיות שהעלו מפתחים ומומחי אבטחה, התגובות משאירות הרבה מקום לרצוי. ישנם יתרונות ברורים רבים ל-App Bundles כפורמט ההפצה של הדור הבא, אך תמיד יהיו דאגות מתמשכות לגבי מתן שליטה חלקית או מלאה בחתימת אפליקציות לגוגל.
התגובות והמאמצים של גוגל בהחלט מוערכים, אבל חלקם, כמו מארק מרפי, מרגישים שהם לא הלכו רחוק מספיק. עם פתרונות כמו חבילות מתוצרת עצמית לא מיושמים והדד-ליין ל-Android App Bundles נדרש במהירות מתקרב, לא נראה שמפתחים ב-Google Play יוכלו לשמור על שליטה מלאה באפליקציות שלהם לאורך זמן ארוך יותר.
נדבר על ההשלכות של דרישת ה-Android App Bundle בחלל של טוויטר מאוחר יותר היום אחר הצהריים, אז הצטרף אלינו!