اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تفريغ الموارد في الأجهزة للربط
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تتيح ميزة "تخفيف عبء الاتصال بالإنترنت عبر شبكة Wi-Fi أو USB" للأجهزة توفير الطاقة وتحسين الأداء من خلال
تخفيف عبء حركة البيانات في عملية الاتصال بالإنترنت عبر شبكة Wi-Fi أو USB على الأجهزة. يتمّ تخفيف عبء معالجة طلبات ربط الشبكات عن طريق توفير مسار مباشر بين المودم والأجهزة الطرفية، مع تخطّي وحدة معالجة التطبيقات.
المواصفات
بدءًا من الإصدار 8.1 من Android، يمكن للأجهزة استخدام ميزة "تخفيف الضغط عن شبكة الجوّال" لتحميل توجيه IPv4 أو IPv6 أو IPv4+IPv6 إلى الجهاز.
لا تحتاج ميزة "تخفيف الحمل" إلى تخفيف حمل جميع الحِزم. إنّ الإطار العملي قادر على التعامل مع أي حزمة في البرنامج. تتم عادةً
معالجة حزم التحكّم في البرامج. بما أنّ منافذ IPv4 تتم مشاركتها بين حركة بيانات الجهاز المرتبط بالشبكة
وحركة بيانات الجهاز، يجب معالجة حزم إعداد/إلغاء جلسة IPv4 (مثل
SYN/SYN+ACK وFIN) في البرنامج حتى تتمكّن النواة من
إنشاء حالة التدفق. يقدّم الإطار طائرة التحكّم وآليات
الحالة. ويقدّم أيضًا للأجهزة معلومات عن الواجهات/البادئات في الاتجاهين الصاعد والهابِط.
بالنسبة إلى IPv4، يسمح الجهاز لحِزم إعداد جلسة ترجمة عنوان الشبكة (NAT) في IPv4 بالوصول إلى وحدة المعالجة المركزية. ينشئ kernel إدخالات NAT، ويرصد تنفيذ HAL إدخالات من أوصاف الملفات المقدَّمة من إطار العمل ويعالج هذه التدفقات في الأجهزة. وهذا يعني أنّ تنفيذ HAL لا يتطلب
CAP_NET_* لأنّ HAL يفتح NF_NETLINK_CONNTRACK مقبسًا
من إطار العمل. تُرسِل الأجهزة بصفة دورية تعديلات على حالة ترجمة عنوان الشبكة (NAT) لعمليات البث النشط حاليًا إلى الإطار العملي، ما يؤدي إلى إعادة تحميل إدخالات حالة تتبُّع اتصال الشبكة الأساسية المقابلة.
بالنسبة إلى IPv6، يبرمج إطار العمل قائمة ببادئات وجهات IPv6 التي يجب عدم نقل الزيارات إليها. يمكن نقل جميع الحِزم الأخرى المرتبطة.
لأغراض احتساب استخدام البيانات، تؤدي استطلاعات استخدام البياناتNetworkStatsService إلى أن يطلب الإطار الإحصائي إحصاءات الزيارات من الأجهزة. يُرسِل الإطار أيضًا
حدود استخدام البيانات إلى الجهاز من خلال HAL.
متطلبات الأجهزة
لتنفيذ ميزة "تخفيف الضغط عن شبكة الجوّال"، يجب أن يكون جهازك قادرًا على إعادة توجيه حزم IP بين المودم وشبكة Wi-Fi/USB بدون إرسال عدد الزيارات من خلال المعالج الرئيسي.
التنفيذ
لتفعيل ميزة نقل البيانات عبر شبكة الجوّال، يجب تنفيذ العنصرَين التاليَين:
واجهة HAL لضبط الشبكة (IOffloadConfig) وواجهة HAL للتحكّم في الشبكة (IOffloadControl).
واجهة HAL للضبط: IOffloadConfig
يبدأ
IOffloadConfig
HAL تنفيذ عملية نقل بيانات الربط. يزوِّد إطار العمل عملية تنفيذ HALNF_NETLINK_CONNTRACK ب sockets متصلة مسبقًا يمكن لعملية التنفيذ استخدامها لمراقبة تدفقات IPv4. يجب تسريع عمليات النقل المُعاد توجيهها فقط.
طبقة HAL للتحكّم: IOffloadControl
تتحكّم واجهة برمجة التطبيقات
IOffloadControl
HAL في تنفيذ ميزة "تخفيف الحمل". يجب تنفيذ الطرق التالية:
- بدء/إيقاف الأجهزة المخصّصة لتفريغ البيانات: استخدِم
initOffload/stopOffload واعفِ عناوين IP المحلية
أو الشبكات الأخرى من تفريغ البيانات باستخدام setLocalPrefixes.
- ضبط واجهة الإرسال وعنوان IPv4 وبوابات IPv6: استخدِم
setUpstreamParameters وضبط نطاقات عناوين IP للأجهزة المتلقية باستخدام addDownstream/removeDownstream.
- احتساب استخدام البيانات: استخدِم
getForwardedStats/setDataLimit.
يجب أن يرسل موفِّر HAL أيضًا عمليات استدعاء من خلال واجهة ITetheringOffloadCallback
، التي تُعلم الإطار العمل بما يلي:
- الأحداث غير المتزامنة، مثل بدء إيقاف ميزة "التخفيف من الحمل"
(OffloadCallbackEvent)
- تعديلات مهلة NAT التي يجب إرسالها بشكل دوري للإشارة إلى أنّ مجرى IPv4 معيّنًا يحتوي على حركة مرور ويجب ألا يغلقه kernel
التحقُّق
للتحقّق من تنفيذ ميزة "إلغاء ربط الجهاز بالشبكة"، استخدِم اختبارًا يدويًا أو آليًا للتحقّق من عمل ميزة "إلغاء ربط الجهاز بالشبكة" ونقطة اتصال Wi-Fi على النحو المتوقّع. تحتوي
مجموعة اختبارات المورّدين (VTS)
على اختبارات لواجهة HAL لتفريغ عمليات الربط.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Tethering hardware offload\n\nTethering offload enables devices to save power and improve performance by\noffloading the tethering traffic (over USB, Wi-Fi) to the hardware. The\ntethering traffic is offloaded by providing a direct path between the modem and\nthe peripherals, bypassing the app processor.\n\nSpecifications\n--------------\n\nStarting in Android 8.1, devices can use tethering offload to\noffload IPv4, IPv6, or IPv4+IPv6 forwarding to the hardware.\n\nThe offload feature doesn't need to offload all packets. The framework is\ncapable of handling any packet in software. Control packets are typically\nprocessed in software. Because IPv4 ports are shared between tethered traffic\nand device traffic, IPv4 session setup/teardown packets (for\nexample, SYN/SYN+ACK, FIN) must be processed in software so the kernel can\nconstruct the flow state. The framework provides the control plane and state\nmachines. It also provides the hardware with information on upstream and\ndownstream interfaces/prefixes.\n\nFor IPv4, the hardware allows IPv4 network address translation (NAT) session\nsetup packets to reach the CPU. The kernel creates NAT entries, and the HAL\nimplementation observes the entries from the framework-provided file descriptors\nand handles these flows in hardware. This means the HAL implementation doesn't\nrequire `CAP_NET_*` because the HAL gets opened `NF_NETLINK_CONNTRACK` sockets\nfrom the framework. Periodically, the hardware sends NAT state updates for\ncurrently active flows to the framework, which refreshes the corresponding\nkernel connection tracking state entries.\n\nFor IPv6, the framework programs a list of IPv6 destination prefixes to which\ntraffic must not be offloaded. All other tethered packets can be offloaded.\n\nFor data usage accounting, `NetworkStatsService` data usage polls causes the\nframework to request traffic stats from hardware. The framework also\ncommunicates data usage limits to the hardware via the HAL.\n\nHardware requirements\n---------------------\n\nTo implement tethering offload, your hardware must be capable of forwarding IP\npackets between the modem and Wi-Fi/USB without sending the traffic through the\nmain processor.\n\nImplementation\n--------------\n\nTo enable the tethering offload feature, you must implement the two following\nboth a config HAL (`IOffloadConfig`) and a control HAL (`IOffloadControl`).\n\n### Config HAL: IOffloadConfig\n\nThe\n[`IOffloadConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/tetheroffload/config/1.0/IOffloadConfig.hal)\nHAL starts the tethering offload implementation. The framework provides the HAL\nimplementation with pre-connected `NF_NETLINK_CONNTRACK` sockets that the\nimplementation can use to observe the IPv4 flows. Only forwarded flows must be\naccelerated.\n\n### Control HAL: IOffloadControl\n\nThe\n[`IOffloadControl`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/tetheroffload/control/1.0/IOffloadControl.hal)\nHAL controls the offload implementation. The following methods must be\nimplemented:\n\n- Start/stop offload hardware: Use `initOffload/stopOffload` and exempt local IP addresses or other networks from offload with `setLocalPrefixes`.\n- Set upstream interface, IPv4 address, and IPv6 gateways: Use `setUpstreamParameters` and configure downstream IP address ranges with `addDownstream/removeDownstream`.\n- Data usage accounting: Use `getForwardedStats/setDataLimit`.\n\nYour vendor HAL must also send callbacks through the `ITetheringOffloadCallback`\ninterface, which informs the framework of:\n\n- Asynchronous events such as offload being started and stopped (OffloadCallbackEvent)\n- NAT timeout updates, which must be sent periodically to indicate that a specific IPv4 flow contains traffic and must not be closed by the kernel\n\nValidation\n----------\n\nTo validate your implementation of tethering offload, use manual or automated\ntesting to verify tethering and Wi-Fi hotspot work as expected. The\n[Vendor Test Suite (VTS)](/docs/core/tests/vts)\ncontains tests for the tethering offload HALs."]]
