自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。
内核网络单元测试
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
从 Android 5.0 开始，要使 Android 网络堆栈在 Linux 内核中正常运行，开发者需要集成近期才提交给上游或尚未提交给上游的多个补丁程序。手动验证需要的内核功能或跟踪缺失的补丁并不容易，因此，Android 团队打算共享他们使用的测试方案，以确保内核按预期运行。
运行测试的原因
运行这些测试的原因主要有 3 个：
- 设备上使用的 Linux 内核的确切版本通常是特定于设备的，如果不运行测试，就很难了解所有内核是否都能够正常工作。
- 将内核补丁向前移植和向后移植到不同的内核版本或不同的设备树时，可能会导致出现一些细微的问题；如果不运行测试，将很难发现这些问题。
- 新的网络功能可能需要新的内核功能，或需要修复内核 bug。
如果未通过测试，设备的网络栈将无法正常运作，从而导致出现用户可见的连接 bug，例如 Wi-Fi 网络断开连接。设备还可能会无法通过 Android 兼容性测试套件 (CTS) 测试。
使用测试
测试会使用 User-Mode Linux 来启动内核，如同 Linux 主机上的一个进程。请参阅搭建构建环境，查看合适的操作系统版本。单元测试框架会使用适当的磁盘映像启动内核，并从主机文件系统运行测试。测试使用 Python 进行编写，并使用 TAP 接口来测试内核行为和套接字 API。
针对 ARCH=um 编译内核
如需运行测试，内核必须针对 ARCH=um SUBARCH=x86_64 进行编译。此架构在上游和通用 Android 内核树（例如 android-4.4）中均受支持。不过，有时设备内核不能在此模式下编译，因为设备树的通用文件（例如 sys/exit.c）中包含特定于设备或特定于硬件的代码。
在很多情况下，只要确保特定于硬件的代码位于 #ifdef 之后，就足够了。通常，这应该是配置选项中的 #ifdef，用于控制与代码相关的特定功能。如果没有这样的配置选项，应将特定于硬件的代码放在 #ifndef CONFIG_UML 块中。
一般情况下，此项修复应该由内核树提供方（例如，芯片组供应商或 SoC 供应商）负责。我们正在与原始设备制造商 (OEM) 和供应商合作，确保当前和未来的内核将针对 ARCH=um
SUBARCH=x86_64 进行编译，而无需进行任何更改。
运行测试
测试位于 kernel/tests/net/test 下。建议您从 AOSP main 运行测试，因为它们是最新的；在某些情况下，给定 Android 版本正常运行所必需的内核功能尚未在该给定版本中进行全面测试。如需了解如何运行测试，请参阅内核网络测试自述文件。总而言之，从您的内核树顶部运行：
ANDROID_TREE/kernel/tests/net/test/run_net_test.sh all_tests.sh
通过测试
内核网络测试 Python 源文件包含注释，这些注释会指定通过测试所必需的已知内核提交。应该在通用内核树（所有通用内核分支 android-4.4 及更高版本，在 AOSP 的 kernel/common 项目中）中通过测试。因此，若要在内核上通过测试，只需从相应的通用内核分支不断合并。
贡献
报告问题
请使用组件-网络标签在 Android 问题跟踪器中报告内核网络测试出现的任何问题。
记录提交项并添加测试
请如上文所述报告问题；如果可能，请在发生以下情况时上传更改以修复问题：
- 测试没有在通用内核树上通过
- 您发现在源代码注释中没有提及某项必要的补丁
- 需要进行重大更改才能在上游内核通过测试
- 您认为测试是多余指定的，或者未来的内核测试会失败
- 您希望添加更多测试或扩大现有测试的覆盖面。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-03-26。
[null,null,["最后更新时间 (UTC)：2025-03-26。"],[],[],null,["# Kernel networking unit tests\n\nSince Android 5.0, proper operation of the Android networking stack on Linux\nkernels requires a number of commits that were upstreamed relatively recently\nor have not yet made it upstream. It is not easy to manually verify the\nrequired kernel functionality or track the missing commits, so the Android team\nis sharing the tests it uses to ensure the kernel behaves as expected.\n\nReasons to run the tests\n------------------------\n\nThese tests exist for three main\nreasons:\n\n1. The exact version of the Linux kernel used on a device is typically device-specific, and it's difficult to know whether any kernel works properly without running the tests.\n2. Forward-porting and back-porting the kernel patches to different kernel versions or different device trees may introduce subtle issues that can be impossible to spot without running the tests.\n3. New networking features may require new kernel functionality or kernel bug fixes.\n\nIf the tests don't pass, the device's network stack\nbehaves incorrectly, causing user-visible connectivity bugs (such as falling off\nWi-Fi networks). The device will likely also fail Android Compatibility Test\nSuite (CTS) tests.\n\nUse the tests\n-------------\n\nThe tests use [User-Mode Linux](http://user-mode-linux.sourceforge.net/) to boot the\nkernel as a process on a Linux host machine. See\n[Establishing a Build Environment](/docs/setup/initializing) for\nsuitable operating system versions. The unit test framework\nboots the kernel with an appropriate disk image and runs the tests from the\nhost file system. The tests are written in Python and use TAP interfaces to\nexercise kernel behaviour and the socket API.\n\n### Compile the kernel for ARCH=um\n\nFor the tests to run,\nthe kernel must compile for `ARCH=um SUBARCH=x86_64`. This is a\nsupported architecture both upstream and in the common Android kernel trees\n(such as `android-4.4`). But sometimes device\nkernels do not compile in this mode because device trees contain\ndevice-specific or hardware-specific code in common files (for example\n`sys/exit.c`).\n\nIn many cases, it's sufficient to ensure that\nhardware-specific code is behind an `#ifdef`. Typically this should\nbe an `#ifdef` on a configuration option that controls the specific\nfeature relevant to the code. If there is no such configuration option, put\nhardware-specific code inside `#ifndef CONFIG_UML` blocks.\n\nIn\ngeneral, fixing this should be the responsibility of the kernel tree provider\n(such as the chipset or SoC vendor). We're working with OEMs and vendors to ensure\nthat current and future kernels compile for `ARCH=um\nSUBARCH=x86_64` without requiring any changes.\n\n### Run the tests\n\nThe tests are at [`kernel/tests/net/test`](https://android.googlesource.com/kernel/tests/+/android16-release/net/test).\nIt is recommended that the tests **be run from AOSP main** because they\nare the most up-to-date; in some cases, kernel features that are necessary for\nproper operation in a given Android release do not yet have full test coverage\nin the given release. For information on how to run the tests, see the [kernel\nnetwork test README file](https://android.googlesource.com/kernel/tests/+/android16-release/net/test/README). Basically, from the top of your kernel tree, run: \n\n```\nANDROID_TREE/kernel/tests/net/test/run_net_test.sh all_tests.sh\n```\n\n### Pass the tests\n\nThe kernel network test Python\nsource files contain comments that specify kernel commits that are known to be\nrequired to pass the tests. The tests should pass in the common kernel trees - all\ncommon kernel branches `android-4.4` and higher - in the\n[`kernel/common`](https://android-review.googlesource.com/#/q/project:kernel/common)\nproject in AOSP. Therefore, passing the tests on a kernel is simply a matter of\ncontinuously merging from the corresponding common kernel branch.\n\nContributions\n-------------\n\n### Report issues\n\nReport any issues with the kernel network tests in the [Android\nissue tracker](https://code.google.com/p/android/issues/entry?template=Developer%20bug%20report) with the [Component-Networking](https://code.google.com/p/android/issues/list?q=label%3AComponent-Networking)\nlabel.\n\n### Document commits and adding tests\n\nReport issues as described above, and if possible upload a change to fix the issue,\nif:\n\n- The tests do not pass on the common kernel trees\n- You find a necessary commit that is not mentioned in the source comments,\n- Getting the tests to pass on upstream kernels requires major changes\n- You believe that the tests are overspecified, or the test fail on future kernels\n- You'd like to add more tests or more coverage to existing tests."]]
