mirror of
https://github.com/permissionlesstech/bitchat-android.git
synced 2026-08-08 06:46:11 +00:00
61588db474
* chore(deps): upgrade to AGP 9.3.1, Gradle 9.6.1, Kotlin 2.4.10, SDK 37 Bring the toolchain and every dependency to latest stable. No app source changes were required. Toolchain: - AGP 8.10.1 -> 9.3.1, Gradle 8.13 -> 9.6.1, Kotlin 2.2.0 -> 2.4.10 - compileSdk 35 -> 37, targetSdk 35 -> 37 (Android 17, stable) - Java 8 -> 11 AGP 9 migration (built-in Kotlin): - Drop org.jetbrains.kotlin.android; AGP 9 provides Kotlin natively and the plugin is incompatible with the new DSL - Migrate kotlinOptions.jvmTarget to kotlin.compilerOptions (the String setter is a hard error in Kotlin 2.4) - Drop android.enableJetifier (deprecated, removed in AGP 10, no support library deps remain) Libraries: - Compose BOM 2025.06.01 -> 2026.06.01, activity-compose 1.10.1 -> 1.13.0 - core-ktx 1.16.0 -> 1.19.0, lifecycle 2.9.1 -> 2.11.0 (unified with lifecycle-process, which had drifted to 2.8.7) - okhttp 4.12.0 -> 5.4.0, coroutines 1.10.2 -> 1.11.0, gson 2.13.1 -> 2.14.0 - BouncyCastle 1.70 -> 1.85, switching bcprov-jdk15on -> bcprov-jdk18on (jdk15on is abandoned; same org.bouncycastle packages) - Tink 1.10.0 -> 1.23.0, CameraX 1.5.2 -> 1.6.1, gms-location 21.3.0 -> 21.4.0 - security-crypto 1.1.0-beta01 -> 1.1.0, navigation-compose 2.9.1 -> 2.9.8 - exifinterface 1.3.7 -> 1.4.2, moved from a hardcoded coordinate into the version catalog - Tests: espresso 3.6.1 -> 3.7.0, test-ext 1.2.1 -> 1.3.0, mockito-kotlin 4.1.0 -> 6.3.0; mockito-inline (deprecated) -> mockito-core 5.23.0; coroutines-test 1.6 -> 1.11.0, now sharing the coroutines version ref instead of drifting Robolectric stays pinned at 4.15: 4.16+ breaks EncryptionServiceTest with "AndroidKeyStore not found". Bisected away from security-crypto and shown not to be SDK-level related. Unpinning needs an EncryptionService refactor, which is deliberately left to a follow-up PR. targetSdk behaviour changes for API 36 and 37 were audited against the source: edge-to-edge and predictive back are already handled, ACCESS_LOCAL_NETWORK is not needed (loopback only, for Arti's SOCKS proxy), the reflection in ChatViewModel touches instance rather than static final fields, and there is no RFCOMM or scheduleAtFixedRate usage. Verified: compileDebugKotlin, testDebugUnitTest (96 tests, 0 failures), bundleRelease with R8, gradlew help, and build --dry-run. The 6 R8 "cannot parse kotlin metadata" warnings present under AGP 8.13.2 are gone under 9.3.1. Not verified on hardware. BLE mesh, foreground services, Nostr relay websockets, Tor, and the Noise handshake still need a device smoke test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: declare ACCESS_LOCAL_NETWORK for Wi-Fi Aware on Android 17 Android 17 (API 37) makes local network protection mandatory for apps targeting it. WifiAwareMeshService reaches peers over link-local IPv6 TCP sockets (connectAwareClientSocket), which may be gated by the new ACCESS_LOCAL_NETWORK runtime permission once targetSdk is raised to 37. The official local network permission documentation frames the feature as LAN access and does not explicitly state whether Wi-Fi Aware peer-to-peer networks are in scope, so this is defensive rather than confirmed-necessary. The sockets are bound to a dedicated Aware Network obtained via requestNetwork, not the user's subnet. Declaring it costs nothing: ACCESS_LOCAL_NETWORK shares the NEARBY_DEVICES group with NEARBY_WIFI_DEVICES, so users who have already granted the latter are not prompted again. The runtime request is gated on SDK_INT >= 37 so older devices are unaffected. Raised by automated review on #750. Verified: compileDebugKotlin, testDebugUnitTest (124 tests, 0 failures), bundleRelease, and ACCESS_LOCAL_NETWORK present in the merged manifest. Not verified on an Android 17 device. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs: correct ACCESS_LOCAL_NETWORK permission-group claim Device testing on Android 17 (API 37) disproved the earlier claim that ACCESS_LOCAL_NETWORK is effectively free because it shares the NEARBY_DEVICES group with NEARBY_WIFI_DEVICES. Granting NEARBY_WIFI_DEVICES alone leaves ACCESS_LOCAL_NETWORK denied: pm grant ... NEARBY_WIFI_DEVICES -> NEARBY_WIFI_DEVICES: granted=true -> ACCESS_LOCAL_NETWORK: granted=false The two are tracked and granted independently, so ACCESS_LOCAL_NETWORK has to be requested explicitly. That is exactly what the wifiAwarePermissions() list already does, so no behavioural change is needed — only the comments were wrong. Whether the runtime dialog bundles the two into a single prompt remains unverified, since enabling Wi-Fi Aware from Debug Settings after onboarding never triggers a permission request at all (pre-existing, unrelated to this branch). Comment-only change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: request Wi-Fi Aware permissions when enabling it from Debug Settings Enabling Wi-Fi Aware from the Debug Settings sheet never requested the permissions it needs. The permission flow is reachable only through PermissionManager.getRequiredPermissions(), which gates the Wi-Fi Aware entries behind shouldRequireWifiAwarePermission() — and that returns false unless the debug toggle is already on. Since the toggle defaults to off, onboarding never asks, and flipping it later starts WifiAwareController directly, which only checks the permission and bails. The result was a silent dead end: Wi-Fi Aware could never start, and the controller logged "Missing NEARBY_WIFI_DEVICES permission" on a 5s retry loop indefinitely. Reproduced on a Pixel 9a (Android 17) and a Samsung SM-A366E (Android 16); both needed adb grants to get the transport running at all. The toggle and the Start chip now request the permissions first and only enable the transport once NEARBY_WIFI_DEVICES is granted. ACCESS_LOCAL_NETWORK is treated as best-effort since it does not exist below API 37 — confirmed by `pm grant` rejecting it as an unknown permission on the Android 16 device. The list comes from PermissionManager.wifiAwarePermissions() so the API 37 gate has a single definition. Also corrects the permission-group comments now that both levels are verified on Android 17: grants are tracked independently (granting NEARBY_WIFI_DEVICES alone leaves ACCESS_LOCAL_NETWORK denied), but the two share the NEARBY_DEVICES group so requesting them together produces a single "Nearby devices" prompt. Verified on device: after a clean uninstall/reinstall, toggling Wi-Fi Aware produced one prompt and left both permissions granted with the USER_SET flag. Addresses the second automated review finding on #750. Verified: compileDebugKotlin, testDebugUnitTest (124 tests, 0 failures). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix: version-gate Wi-Fi Aware permissions, check live grant state Two issues from automated review of ee1ee3ad. wifiAwarePermissions() returned NEARBY_WIFI_DEVICES unconditionally, but that permission only exists from API 33 while minSdk is 26 and Wi-Fi Aware is available from API 26. On an API 26-32 device the new enable path would request an unknown permission, receive a denial, and never enable a transport that needs no runtime permission there at all — a regression introduced by the previous commit. Both entries are now version-gated. The result callback also inferred the Nearby grant from the result map, which omits permissions that were already held and so filtered out before launching. It now reads the live permission state instead. A denied ACCESS_LOCAL_NETWORK still does not block enabling: the controller starts fine without it (verified on Android 17), and its necessity for link-local sockets remains unproven, so a denial should not disable a transport that otherwise works. Also trims the comments added in the last two commits down to the density of the surrounding code. Verified: compileDebugKotlin, testDebugUnitTest (124 tests, 0 failures). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>