פתרון בעיות

תיקון השגיאה 'תנועת Chromium HTTP אינה מותרת' שגיאות

השגיאה הזו תתרחש אם האפליקציה מבקשת תנועת HTTP ללא טקסט (כלומר, http:// במקום https://), כשהגדרות אבטחת הרשת שלו עושים זאת ולא תאפשר זאת. אם האפליקציה מטרגטת את Android 9 (רמת API 28) ואילך, טקסט ללא הצפנה לפי הגדרות ברירת המחדל, התנועה ב-HTTP מושבתת.

אם האפליקציה צריכה לפעול עם תנועת HTTP של טקסט ללא הצפנה, צריך להשתמש ב- הגדרה של אבטחת רשת שמאפשרת זאת. לצפייה ב-Android מסמכים בנושא אבטחת רשת לקבלת פרטים. כדי להפעיל את כל התנועה ב-HTTP ללא טקסט חופשי, אפשר פשוט להוסיף android:usesCleartextTraffic="true" לרכיב application של האפליקציה AndroidManifest.xml.

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

תיקון של 'SSLHandshakeחריג', 'CertPathValidator מפרסמים' ו-"ERR_CERT_AUTHORITY_INVALID" שגיאות

SSLHandshakeException, CertPathValidatorException וגם כל ערכי ERR_CERT_AUTHORITY_INVALID מציינים בעיה ב-SSL של השרת אישור. השגיאות האלה לא ספציפיות ל-ExoPlayer. צפייה מסמכי תיעוד SSL של Android אפשר לקבל פרטים נוספים.

למה יש קובצי מדיה שלא ניתן לחפש?

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

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

למה יש חיפוש לא מדויק בקובצי MP3 מסוימים?

קובצי MP3 עם קצב העברת נתונים משתנה (VBR) בכלל לא מתאימים לתרחישים לדוגמה לדרוש דילוג מדויק. יש לכך שתי סיבות:

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

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

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

למה הדילוג בסרטון איטי?

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

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

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

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

מדוע קובצי MPEG-TS מסוימים לא מופעלים?

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

ExoPlayer ייראה תקוע במצב אגירת נתונים כשיתבקשו להפעיל קובץ MPEG-TS ללא תמונות מפתח AUD או IDR. אם צריך להפעיל קבצים כאלה, אפשר לעשות זאת באמצעות FLAG_DETECT_ACCESS_UNITS FLAG_ALLOW_NON_IDR_KEYFRAMES בהתאמה. את הדגלים האלה אפשר להגדיר DefaultExtractorsFactory באמצעות setTsExtractorFlags או ב DefaultHlsExtractorFactory באמצעות constructor. לשימוש ב-FLAG_DETECT_ACCESS_UNITS אין תופעות לוואי מלבד יקרות מבחינה חישובית לזיהוי גבולות פריימים שמבוססים על AUD. שימוש ב- FLAG_ALLOW_NON_IDR_KEYFRAMES עלול לגרום לפגיעה זמנית בצפייה הפעלת הפעלה ומיד לאחר מכן חיפוש בזמן הפעלת קובצי MPEG-TS.

מדוע לא ניתן למצוא כתוביות בקובצי MPEG-TS מסוימים?

חלק מקובצי MPEG-TS כוללים טראקים בפורמט CEA-608, אבל לא מוצהר עליהם מטא-נתונים בקונטיינר, ולכן ExoPlayer לא יכול לזהות אותם. אפשר באופן ידני לציין טראקים של כתוביות באמצעות רשימה של הטראקים פורמטים של כתוביות בDefaultExtractorsFactory, כולל נגישות ערוצים שבהם אפשר להשתמש כדי לזהות אותם בזרם MPEG-TS:

Kotlin

val extractorsFactory =
  DefaultExtractorsFactory()
    .setTsSubtitleFormats(
      listOf(
        Format.Builder()
          .setSampleMimeType(MimeTypes.APPLICATION_CEA608)
          .setAccessibilityChannel(accessibilityChannel)
          // Set other subtitle format info, such as language.
          .build()
      )
    )
val player: Player =
  ExoPlayer.Builder(context, DefaultMediaSourceFactory(context, extractorsFactory)).build()

Java

DefaultExtractorsFactory extractorsFactory =
    new DefaultExtractorsFactory()
        .setTsSubtitleFormats(
            ImmutableList.of(
                new Format.Builder()
                    .setSampleMimeType(MimeTypes.APPLICATION_CEA608)
                    .setAccessibilityChannel(accessibilityChannel)
                    // Set other subtitle format info, such as language.
                    .build()));
Player player =
    new ExoPlayer.Builder(context, new DefaultMediaSourceFactory(context, extractorsFactory))
        .build();

למה קובצי MP4/FMP4 מסוימים לא פועלים באופן תקין?

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

אם אתה רואה שחלק מהמדיה חסר באופן בלתי צפוי או חוזר על עצמו, אפשר לנסות להגדיר את Mp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS או FragmentedMp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS, שחולץ כדי להתעלם מרשימות עריכה. אפשר להגדיר אותן DefaultExtractorsFactory באמצעות setMp4ExtractorFlags או setFragmentedMp4ExtractorFlags.

למה חלק מהשידורים נכשלים עם קוד תגובת HTTP 301 או 302?

קודי התגובה 301 ו-302 של HTTP מצביעים שניהם על הפניה אוטומטית. תיאורים קצרים ניתן למצוא אותו בוויקיפדיה. כש-ExpoPlayer שולח בקשה ומקבל עם קוד הסטטוס 301 או 302, בדרך כלל היא תעקוב אחר ההפניה האוטומטית ולהתחיל את ההפעלה כרגיל. המקרה היחיד שבו זה לא קורה כברירת מחדל מיועד להפניות אוטומטיות בין פרוטוקולים. כתובת אתר להפניה מחדש במספר פרוטוקולים היא כתובת אתר להפניה מחדש מ-HTTPS ל-HTTP או להיפך (או פחות, בין צמדים אחרים של ). תוכלו לבדוק אם כתובת URL גורמת להפניה אוטומטית במגוון פרוטוקולים באמצעות כלי שורת הפקודה wget באופן הבא:

wget "https://yourserver.com/test.mp3" 2>&1  | grep Location

הפלט אמור להיראות ככה:

Location: https://second.com/test.mp3 [following]
Location: http://third.com/test.mp3 [following]

בדוגמה הזו יש שתי הפניות לכתובות אחרות. כתובת ה-URL הראשונה להפניה אוטומטית היא מ- https://yourserver.com/test.mp3 עד https://second.com/test.mp3. שניהם HTTPS, ולכן זו לא הפניה אוטומטית בין פרוטוקולים. ההפניה השנייה לכתובת אחרת היא מ- https://second.com/test.mp3 עד http://third.com/test.mp3. הכתובת הזו מפנה לכתובת אחרת מ-HTTPS ל-HTTP, ולכן גם הפניות אוטומטיות בין פרוטוקולים. הפעולה של ExoPlayer לא תעקוב אחר ההפניה האוטומטית הזו בהגדרת ברירת המחדל שלה, כלומר ההפעלה תיכשל.

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

למה חלק מהשידורים נכשלים עם UnIdentifieInputFormatError?

השאלה הזו מתייחסת לכשלים בהפעלה באופן הבא:

UnrecognizedInputFormatException: None of the available extractors
(MatroskaExtractor, FragmentedMp4Extractor, ...) could read the stream.

יש שתי סיבות אפשריות לכשל הזה. הסיבה השכיחה ביותר היא ניסית להפעיל DASH (mpd), HLS (m3u8) או SmoothStreaming (ism, isml) אבל השחקן מנסה להפעיל אותו בסטרימינג מתקדם. לשחק כך חייבים להיות תלויים במודול ExoPlayer המתאים. במקרים שבהם ה-URI של השידור לא מסתיים בסיומת הקובץ הרגילה, אפשר גם להעביר MimeTypes.APPLICATION_MPD, MimeTypes.APPLICATION_M3U8 או MimeTypes.APPLICATION_SS עד setMimeType מתוך MediaItem.Builder כדי לבצע באופן מפורש לציין את סוג השידור.

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

למה הפרמטר setPlaybackParameters לא פועל בצורה תקינה במכשירים מסוימים?

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

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

למה מופיעה ההודעה "יש גישה לנגן בשרשור הלא נכון" מה המשמעות של שגיאות?

כדאי לעיין בהערה לגבי חלוקה לשרשורים בדף 'תחילת העבודה'.

כיצד אוכל לתקן את השגיאה "שורת סטטוס לא צפויה: ICY 200 OK"?

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

איך אפשר לשאול אם השידור החי הוא שידור חי?

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

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

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

  1. אתם צריכים שיהיה לכם שירות שפועל בחזית. זה מונע מהמערכת החל מהרג התהליך ועד לפינוי משאבים.
  2. צריך להחזיק את WifiLock ואת WakeLock. הן מבטיחות משאירה את המעבד (CPU) ורדיו ה-Wi-Fi במצב פעיל. ניתן לעשות זאת בקלות אם משתמשים ExoPlayer באמצעות שיחה אל setWakeMode, שיבוצע באופן אוטומטי להשיג ולשחרר את המנעולים הנדרשים בזמנים הנכונים.

חשוב לשחרר את המנעולים (אם לא משתמשים ב-setWakeMode) ולהפסיק השירות ברגע שהאודיו מושמע יותר.

למה ExoPlayer תומך בתוכן שלי, אבל ספריית ExoPlayer Cast לא תומכת בו?

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

למה התוכן לא מופעל אבל לא מוצגת שגיאה?

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

[ ] Track:x, id=x, mimeType=mime/type, ... , supported=NO_UNSUPPORTED_TYPE

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

איך אפשר לטעון ספריית פענוח שתשמש להפעלה?

  • לרוב ספריות המפענח יש שלבים ידניים כדי לבדוק את יחסי התלות וליצור את יחסי התלות, ודא שביצעת את השלבים ב-README של הספרייה הרלוונטית. לדוגמה, עבור ספריית ExoPlayer FFmpeg, צריך לפעול לפי הוראות ב-libraries/decoder_ffmpeg/README.md, כולל העברה דגלי הגדרות אישיות כדי להפעיל מפענחים עבור כל פורמט שרוצים להפעיל.
  • בספריות שיש בהן קוד נייטיב, צריך לוודא שמשתמשים של Android NDK כפי שמצוין ב-README, ועליך לבדוק אם יש שמופיעות במהלך הגדרת התצורה והבנייה. אתם אמורים לראות את .so הקבצים מופיעים בספריית המשנה libs בנתיב של הספרייה, עבור כל אחד לארכיטקטורה נתמכת אחרי ביצוע השלבים שבקובץ README.
  • כדי לנסות את ההפעלה באמצעות הספרייה שבאפליקציית ההדגמה: הפעלת מפענחים בחבילה. אפשר לעיין ב-README של הספרייה הוראות לשימוש בספרייה מהאפליקציה שלכם.
  • אם אתם משתמשים ב-DefaultRenderersFactory, אתם אמורים לראות רמת מידע שורת יומן כגון "Loaded FFMpegAudioRenderer" ב-Logcat כשהמפענח נטען. אם מאפיין זה חסר, יש לוודא שהאפליקציה תלויה של ספריית הפענוח.
  • אם מופיעים יומנים ברמת אזהרה מ-LibraryLoader ב-Logcat, מציין שטעינת הרכיב המקורי של הספרייה נכשלה. אם במקרה, עליך לוודא שביצעת את השלבים ב-README של הספרייה בצורה נכונה ושלא פלטו שגיאות כלשהן במהלך ביצוע ההוראות.

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

האם אפשר להפעיל סרטונים ב-YouTube ישירות דרך ExoPlayer?

לא, ExoPlayer לא יכול להפעיל סרטונים מ-YouTube, כמו כתובות URL של הטופס https://www.youtube.com/watch?v=... במקום זאת, צריך להשתמש בכלי YouTube ,IFrame Player API וזו הדרך הרשמית להפעיל סרטונים ב-YouTube ב-Android.

הפעלת הסרטון מקוטעת

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

אם סרטונים מטושטשים במכשיר שבו פועלת גרסת Android החל מ-Android 6.0 (רמת API 23) ועד Android 11 (רמת API 30) כולל, במיוחד כאשר מפעילים תוכן המוגן באמצעות DRM או תוכן בקצב פריימים גבוה, ניתן לנסות הפעלת תורים במאגרי נתונים זמניים אסינכרוניים.

שגיאות של איתור שגיאות בקוד (lint) מ-API לא יציב

Media3 מבטיח תאימות בינארית לקבוצת משנה של פלטפורמת ה-API. חלקים שלא מבטיחים תאימות בינארית מסומנים @UnstableApi. כדי להבהיר את ההבחנה הזו, שימושים לא יציבים בסמלי API יוצרים שגיאת איתור שגיאות בקוד, אלא אם מוסיפים להם הערות עם @OptIn.

ההערה @UnstableApi לא מרמזת דבר על האיכות או הביצועים של API, אלא רק על העובדה שהוא לא 'קפוא API'.

יש שתי אפשרויות לטיפול בשגיאות של איתור שגיאות בקוד (lint) לא יציבות ב-API:

  • עוברים להשתמש ב-API יציב שמשיג את אותה התוצאה.
  • ממשיכים להשתמש ב-API הלא יציב ומוסיפים הערות על השימוש עם @OptIn, שמוצג מאוחר יותר.
הוספת ההערה @OptIn

אתם יכולים להיעזר ב-Android Studio כדי להוסיף את ההערה:

צילום מסך: איך מוסיפים את הערת ההסכמה
איור 2: הוספת הערה מסוג @androidx.annotations.OptIn עם Android Studio.

אפשר גם להוסיף ידנית הערות לאתרי שימוש ספציפיים ב-Kotlin:

import androidx.annotation.OptIn
import androidx.media3.common.util.UnstableApi

@OptIn(UnstableApi::class)
fun functionUsingUnstableApi() { ... }

וגם ב-Java:

import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;

@OptIn(markerClass = UnstableApi.class)
private void methodUsingUnstableApis() { ... }

אפשר לצרף חבילות שלמות על ידי הוספת קובץ package-info.java:

@OptIn(markerClass = UnstableApi.class)
package name.of.your.package;

import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;

אפשר להצטרף לפרויקטים שלמים על ידי הסתרת השגיאה הספציפית של איתור השגיאות בקוד קובץ אחד (lint.xml):

 <?xml version="1.0" encoding="utf-8"?>
 <lint>
   <issue id="UnsafeOptInUsageError">
     <option name="opt-in" value="androidx.media3.common.util.UnstableApi" />
   </issue>
 </lint>

יש גם הערה מסוג kotlin.OptIn שאין להשתמש בה. זו חשוב להשתמש בהערה androidx.annotation.OptIn.