| Filename | Latest commit message | Latest commit date |
|---|---|---|
04fb3862a9
Per commit description of https://android-review.git.corp.google.com/c/platform/packages/modules/Connectivity/+/3109108 "Use SingleWriterBpfMap in BpfNetMaps": - firewall.cpp writes to sConfigurationMap, sUidOwnerMap, and sDataSaverEnabledMap, but that code only runs in tests because it requires root privileges. So either those maps need to not use SingleWriterBpfMap in the BpfNetMaps (which would affect performance), or we need to prevent the tests from grabbing the locks, or the tests will (presumably) fail. This avoids grabbing the locks from the test, even though this is absolutely terrible and likely breaks things... But in general the entire firewall.cpp file (and libconnectivity_native_test_utils target) are just one large modularization violation in need of major escalation... Test via: atest resolv_{gold,stress,integration,unit}_test Without this patch: resolv_gold_test: Passed: 16 resolv_integration_test: Passed: 53, Failed: 2, Ignored: 118, Assumption Failed: 0 (Completed With ERRORS) resolv_stress_test: Passed: 2 resolv_unit_test: Passed: 124, Failed: 2 4 tests failed -------------- ResolverMultinetworkTest#DnsWithVpn PrivateDns/TransportParameterizedTest#BlockDnsQuery/DoT CallbackTest#tagSocketCallback ResolvGetAddrInfoTest#InvalidParameters With this patch: resolv_gold_test: Passed: 16 resolv_integration_test: Passed: 178 resolv_stress_test: Passed: 2 resolv_unit_test: Passed: 126 Test: TreeHugger Signed-off-by: Maciej Żenczykowski <maze@google.com> Change-Id: Ie97d015ef66c3864a23484e7ed190fe7d091af5c |
||
| .. | ||
| bpf_headers | ||
| bpf_syscall_wrappers | ||
| bpfmapjni | ||
| bpfutiljni | ||
| ip_checksum | ||
| netjniutils | ||
| nettestutils | ||
| tcutils | ||
| README.md | ||
JNI
As a general rule, jarjar every static library dependency used in a mainline module into the modules's namespace (especially if it is also used by other modules)
Fully-qualified name of java class needs to be hard-coded into the JNI .so, because JNI_OnLoad does not take any parameters. This means that there needs to be a different .so target for each post-jarjared package, so for each module.
This is the guideline to provide JNI library shared with modules:
-
provide a common java library in frameworks/libs/net with the Java class (e.g. BpfMap.java).
-
provide a common native library in frameworks/libs/net with the JNI and provide the native register function with class_name parameter. See register_com_android_net_module_util_BpfMap function in frameworks/libs/net/common/native/bpfmapjni/com_android_net_module_util_BpfMap.cpp as an example.
When you want to use JNI library from frameworks/lib/net:
-
Each module includes the java library (e.g. net-utils-device-common-bpf) and applies its jarjar rules after build.
-
Each module creates a native library in their directory, which statically links against the common native library (e.g. libnet_utils_device_common_bpf), and calls the native registered function by hardcoding the post-jarjar class_name. Linkage MUST be static because common functions in the file (e.g.,
register_com_android_net_module_util_BpfMap) will appear in the library (.so) file, and different versions of the library loaded in the same process by different modules will in general have different versions. It's important that each of these libraries loads the common function from its own library. Static linkage should guarantee this because static linkage resolves symbols at build time, not runtime.