היסודות של אפליקציות

ניתן לכתוב אפליקציות ל-Android באמצעות Kotlin, שפת התכנות Java ושפות C++. כלי הידור של Android SDK את הקוד יחד עם כל קובצי הנתונים והמשאבים ב-APK או בקובץ Android App Bundle.

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

קובץ Android App Bundle, שהוא קובץ ארכיון עם הסיומת .aab, מכיל את התוכן של פרויקט באפליקציה ל-Android, כולל כמה מטא-נתונים נוספים שלא נדרשים ב בסביבת זמן ריצה. AAB הוא פורמט פרסום ואי אפשר להתקין אותו במכשירי Android. הוא מונעת יצירת APK וחתימה לשלב מאוחר יותר.

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

כל אפליקציה ל-Android פועלת בארגז חול (Sandbox) נפרד לאבטחה, שמוגן על ידי תכונות האבטחה הבאות של Android:

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

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

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

• אפשר לקבוע ששתי אפליקציות ישתפו את אותו מזהה משתמש ב-Linux, ובמקרה כזה הם יכולים לגשת לקבצים אחד של השני. כדי לחסוך במשאבי מערכת, אפליקציות עם אותו User ID יכול גם לקבוע לפעול באותו תהליך Linux ולשתף את אותה VM. גם האפליקציות חייבות להיות חתומות באמצעות אותו אישור.
• אפליקציות יכולות לבקש הרשאת גישה לנתוני המכשיר, למשל המיקום, המצלמה וחיבור ה-Bluetooth. למשתמש יש כדי להעניק את ההרשאות האלה באופן מפורש. למידע נוסף על הרשאות, אפשר לעיין במאמר הרשאות ב-Android.

בהמשך המסמך מתוארים המושגים הבאים:

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

רכיבי האפליקציה

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

יש ארבעה סוגים של רכיבי אפליקציות:

• פעילויות
• שירותים
• מקלטי שידורים
• ספקי תוכן

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

פעילויות

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

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

פעילות מאפשרת את האינטראקציות העיקריות הבאות בין המערכת והאפליקציה:

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

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

שירותים

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

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

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

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

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

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

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

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

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

מקלטי שידור

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

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

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

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

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

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

ספקי תוכן

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

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

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

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

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

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

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

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

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

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

הפעלת רכיבים

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

אובייקט Intent נוצר עם אובייקט Intent, שמגדיר הודעה: הפעלה של רכיב ספציפי (Intent מפורש) או סוג ספציפי של רכיב (Intent מרומז).

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

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

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

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

יש שיטות נפרדות להפעלה של כל סוג רכיב:

• אפשר להתחיל פעילות או להגדיר משימה חדשה לביצוע, על ידי העברה של Intent אל startActivity() או, אם רוצים שהפעילות תחזיר תוצאה, startActivityForResult().
• ב-Android 5.0 (רמת API 21) ואילך, אפשר להשתמש הכיתה JobScheduler כדי לתזמן פעולות. בגרסאות קודמות של Android, אפשר להתחיל שירות או מתן הוראות חדשות לשירות מתמשך על ידי מעביר Intent אל startService(). אפשר ליצור קישור לשירות על ידי העברת Intent אל bindService().
• אפשר להתחיל שידור על ידי העברת Intent לשיטות כמו sendBroadcast() או sendOrderedBroadcast().
• אפשר לבצע שאילתה לספק תוכן query() על ContentResolver.

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

קובץ המניפסט

לפני שמערכת Android תוכל להפעיל רכיב של אפליקציה, המערכת צריכה לדעת ש הרכיב קיים על ידי קריאת קובץ המניפסט של האפליקציה, AndroidManifest.xml. האפליקציה שלך מצהירה על כל הרכיבים שלה בקובץ הזה, שנמצא ברמה הבסיסית (root) של של האפליקציה.

המניפסט עושה כמה פעולות בנוסף להצהרה על רכיבי האפליקציה, כמו:

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

הצהרה על רכיבים

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

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

בתוך <application> לרכיב, המאפיין android:icon מפנה למשאבים עבור סמל שמזהה את אפליקציה.

ברכיב <activity>, המאפיין android:name מציין את שם הסיווג המוגדר במלואו של המאפיין המחלקה המשנית Activity, המאפיין android:label מציין מחרוזת כתווית שגלויה למשתמש עבור הפעילות.

צריך להצהיר על כל רכיבי האפליקציה באמצעות הרכיבים הבאים:

• <activity> רכיבים לפעילויות
• רכיבי <service> של שירותים
• <receiver> רכיבים למקלטי שידורים
• <provider> רכיבים לספקי תוכן

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

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

הצהרה על יכולות רכיבים

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

זהירות: אם אתם משתמשים בכוונה כדי להתחיל Service, חשוב לוודא שהאפליקציה מאובטחת באמצעות תוכן בוטה בכוונה טובה. שימוש מתוך כוונה מרומזת להפעלת שירות הוא סיכון אבטחה, כי לא ניתן להיות בטוחים איזה שירות מגיב לכוונה והמשתמש לא יכול לראות איזה שירות מתחיל. החל מ-Android 5.0 (רמת API 21), המערכת מקפיצה הודעת שגיאה (throw) לחריגה אם מתקשרים ל-bindService() מתוך כוונה מרומזת. אין להצהיר על מסנני Intent עבור השירותים שלכם.

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

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

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

<manifest ... >
    ...
    <application ... >
        <activity android:name="com.example.project.ComposeEmailActivity">
            <intent-filter>
                <action android:name="android.intent.action.SEND" />
                <data android:type="*/*" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
    </application>
</manifest>

אם אפליקציה אחרת יוצרת Intent עם הפעולה ACTION_SEND ומעבירה אותה אל startActivity(), המערכת עשויה להתחיל את הפעילות כדי שהמשתמש יוכל לכתוב טיוטה ולשלוח באימייל.

מידע נוסף על יצירת מסנני Intent זמין במסמך מנגנוני Intent ומסנני Intent.

להצהיר על הדרישות לגבי האפליקציה

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

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

לדוגמה, נניח שהאפליקציה שלך דורשת מצלמה ומשתמשת בממשקי API שנוספו ל-Android 8.0 (רמת API 26). עליכם להצהיר על הדרישות האלה. הערכים של minSdkVersion ושל targetSdkVersion מוגדרים כאן קובץ build.gradle של מודול האפליקציה:

android {
  ...
  defaultConfig {
    ...
    minSdkVersion 26
    targetSdkVersion 29
  }
}

הערה: אל תגדירו את minSdkVersion וגם targetSdkVersion ישירות בקובץ המניפסט, כי הם מחליפים אותם ב-Gradle במהלך תהליך ה-build. מידע נוסף זמין במאמר הבא: ציון דרישות לגבי רמת ה-API.

יש לך אפשרות להצהיר על תכונת המצלמה בקובץ המניפסט של האפליקציה:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    ...
</manifest>

בעקבות ההצהרות בדוגמאות האלה, במכשירים שאין להם מצלמה לא ניתן להתקין את האפליקציה מ-Google Play בגרסת Android גרסה נמוכה מ-8.0. עם זאת, אפשר גם להצהיר שהאפליקציה שלך משתמשת במצלמה, אבל לא נדרש. כדי לעשות את זה, צריך להגדיר את required ל-false, יש לבדוק בזמן הריצה אם יש במכשיר מצלמה, ומשביתים את כל תכונות המצלמה לפי הצורך.

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

משאבי אפליקציות

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

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

לכל משאב שכוללים בפרויקט Android, כלי ה-build של ה-SDK מגדירים ערך ייחודי מספר שלם, ואפשר להשתמש בו כדי להפנות למשאב מקוד האפליקציה או משאבים אחרים שמוגדרים ב-XML. לדוגמה, אם האפליקציה מכילה קובץ תמונה בשם logo.png (נשמר בספרייה res/drawable/), כלי ה-SDK יוצרים מזהה משאב בשם R.drawable.logo. המזהה הזה ממופה למספר שלם ספציפי לאפליקציה, שאפשר להשתמש בהם כדי להפנות לתמונה ולהוסיף אותה לממשק המשתמש.

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

לדוגמה, באמצעות הגדרת מחרוזות ממשק משתמש ב-XML, ניתן לתרגם את המחרוזות ולשמור את המחרוזות האלה בקבצים נפרדים. לאחר מכן מערכת Android מחילה את מחרוזות שפה מתאימות לממשק המשתמש על סמך מגדיר שפה שאתם מוסיפים לשם ספריית המשאבים, למשל res/values-fr/ למחרוזת צרפתית והערכים של השפה של המשתמש.

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

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

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

מקורות מידע נוספים

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