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

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Wi-Fi Aware

התכונה Wi-Fi Aware שנוספה ב-Android 8.0 מאפשרת למכשירים תומכים לגלות, להתחבר ולמדוד מרחק (נוספה ב-Android 9) אחד מהשני ישירות באמצעות פרוטוקול Wi-Fi Aware, ללא גישה לאינטרנט או לרשת סלולרית. התכונה הזו, שמבוססת על Wi-Fi Alliance‏ (WFA) Wi-Fi Aware specification (גרסאות 2.0, ‏ 3.0, ‏ 3.1 ו-4.0), מאפשרת שיתוף של נתונים עם קצב העברה גבוה בין מכשירים ואפליקציות מהימנים שלא מחוברים לרשת.

לתיאור מפורט של ארכיטקטורת Wi-Fi Aware ב-Android 17 ומעלה, אפשר לעיין במאמר בנושא ארכיטקטורת Wi-Fi Aware.

דוגמאות ומקור

כדי להשתמש בתכונה הזו, יצרני המכשירים צריכים להטמיע את Wi-Fi Vendor HAL. ב-Android מגרסה 14 ואילך, ממשק Vendor HAL מוגדר באמצעות AIDL. בגרסה 13 של Android ובגרסאות קודמות, ממשק ה-HAL של הספק מוגדר באמצעות HIDL.

כדי להשתמש בתכונה Wi-Fi Aware, פועלים לפי ההוראות בממשק ה-Wi-Fi. בהתאם לממשק שהוטמע, זה יכול להיות:

‫AIDL: hardware/interfaces/wifi/aidl
‫HIDL: ‏ hardware/interfaces/wifi/1.2 ואילך

אפשר לעיין ב-Wi-Fi HAL מדור קודם כדי לראות איך הוא קשור לממשקי AIDL ו-HIDL:‏ hardware/libhardware_legacy/+/android17-release/include/hardware_legacy/wifi_nan.h.

הטמעה

יצרני המכשירים צריכים לספק תמיכה גם במסגרת וגם ב-HAL/קושחה:

Framework:
- קוד של פרויקט קוד פתוח של Android‏ (AOSP)
- הפעלת Aware: נדרשים feature flag ו-build flag
תמיכה ב-Wi-Fi Aware ‏ (NAN) HAL (שמשמעותה תמיכה בקושחה)

כדי להטמיע את התכונה הזו, יצרני המכשירים מטמיעים את ממשק ה-Wi-Fi ומפעילים שני feature flags:

ב-BoardConfig.mk או ב-BoardConfig-common.mk שנמצאים ב-device/<oem>/<device>, מוסיפים את הדגל הבא:
```
WIFI_HIDL_FEATURE_AWARE := true
```
ב-device.mk שנמצא ב-device/<oem>/<device>, משנים את משתנה הסביבה PRODUCT_COPY_FILES כך שיכלול תמיכה בתכונת Wi-Fi Aware:
```
PRODUCT_COPY_FILES +=
frameworks/native/data/etc/android.hardware.wifi.aware.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.aware.xml
```

התכונה Wi-Fi Aware כוללת מדידת מרחק למכשירי עמיתים באמצעות פרוטוקול IEEE 802.11mc,‏ שנקרא גם זמן הלוך ושוב (RTT). תכונת המשנה הזו של Wi-Fi Aware מותנית בכך שהמכשיר תומך בתכונה Wi-Fi RTT, כלומר, נדרש שהמכשיר יתמוך גם ב-Wi-Fi Aware וגם ב-Wi-Fi RTT. פרטים נוספים זמינים במאמר בנושא Wi-Fi RTT.

אחרת, כל מה שנדרש לתכונה הזו כלול ב-AOSP.

המערכת מתעלמת מהדגל WIFI_HIDL_FEATURE_AWARE אם מציינים את הדגל WIFI_HAL_INTERFACE_COMBINATIONS. מידע נוסף מופיע במאמר בנושא בו זמניות של ממשקי Wi-Fi מרובים.

רנדומיזציה של כתובות MAC

מערכת Android דורשת שכתובת ה-MAC של ממשקי הגילוי (NMI) והנתונים (NDP) של Wi-Fi Aware תהיה אקראית ולא זהה לכתובת ה-MAC האמיתית של המכשיר. כתובות ה-MAC צריכות להיות:

הכתובת משתנה באופן אקראי בכל פעם שמפעילים או מפעילים מחדש את Wi-Fi Aware.
כשהתכונה Wi-Fi Aware מופעלת, כתובת ה-MAC חייבת להיות אקראית במרווחי זמן קבועים שמוגדרים על ידי הפרמטר NanConfigRequest.macAddressRandomizationIntervalSec. כברירת מחדל, משך הזמן הזה מוגדר ב-Framework ל-30 דקות.

הערה: בהתאם למפרט של Wi-Fi Aware, יכול להיות שהאקראיות תושעה בזמן שמוגדר NDP. ההשעיה לא מרמזת על שימוש בכתובת ה-MAC של היצרן (אסור להשתמש בה אף פעם ב-Wi-Fi Aware), אלא על כך שכתובת ה-MAC נקבעת מחדש באופן אקראי בתדירות נמוכה יותר מהנדרש.

השהיה והמשך

ב-Android מגרסה 14 ואילך, Wi-Fi Aware תומך ביכולת של אפליקציות עם הרשאות להשהות ולהפעיל מחדש סשנים פעילים של גילוי (כולל כל נתיבי הנתונים שמשויכים לסשנים האלה). התמיכה ביכולת הזו מאפשרת למכשירים לחדש מהר יותר את סשני החיפוש ולצרוך פחות חשמל, כי אפשר להשהות את סשני החיפוש.

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

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

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

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

אימות

‫Android מספקת קבוצה של בדיקות יחידה, בדיקות Compatibility Test Suite ‏ (CTS) ובדיקות CTS Verifier כדי לאמת את התכונה Wi-Fi Aware. אפשר גם לבדוק את Wi-Fi Aware באמצעות Vendor Test Suite (VTS).

בדיקות יחידה

בדיקות החבילה של Wi-Fi Aware מופעלות באמצעות:

בדיקות שירות:

atest com.android.server.wifi.aware

בדיקות בחשבון ניהול:

atest android.net.wifi.aware

בדיקות בחבילה לבדיקות תאימות (CTS)

משתמשים בבדיקות CTS כדי לאמת את התכונה Wi-Fi Aware. בדיקות CTS מזהות מתי התכונה מופעלת וכוללות אוטומטית את הבדיקות שקשורות אליה.

אפשר להפעיל את בדיקות ה-CTS באמצעות:

atest SingleDeviceTest

בדיקות CTS Verifier

בדיקות CTS Verifier מאמתות את ההתנהגות של Wi-Fi Aware באמצעות שני מכשירים: מכשיר בדיקה ומכשיר תקין. כדי להריץ את הבדיקות, פותחים את CTS Verifier ועוברים לקטע Wi-Fi Aware Tests.