Bug Attack: stability, logging, export, theme, and firewall fixes

[Mainkill1]

Hi,

This is a large integration PR that collects the fixes and improvements we have been building across the beta branch. Sorry for the huge amount of work landing in one place; the changes started with a few reliability and performance fixes, then grew into a broader cleanup of rule application, logging, exports, themes, widgets, and generated firewall behavior.

Because this is intentionally broad, the easiest way to manage it may be to keep this as a draft review surface and, if needed, create a temporary integration branch such as stupid-large-changes for testing and follow-up cleanup before anything lands directly in beta.

High-Level Summary

This branch focuses on making AFWall more reliable when applying rules, easier to diagnose when root or rule application fails, less confusing in log/export flows, and more consistent in theme handling. It also includes several firewall rule corrections for IPv6, Tor, LAN, tethering, VPN handling, widgets, and profile app discovery.

The changes are grouped so they can be reviewed by area:

1. Root and rule apply behavior
2. Logging and export handling
3. Settings export picker behavior
4. Theme presets and custom theme colors
5. Firewall rule generation fixes
6. Profile app discovery and app list behavior
7. Widget and plugin stability fixes
8. Included review build artifacts

Recommended Review Approach

I recommend treating this as an integration branch rather than a small targeted patch.

Suggested handling:

1. Keep this PR in draft while reviewing the larger behavior changes.
2. Branch from it into something like stupid-large-changes if you want a separate manual-test branch.
3. Review by section instead of trying to reason about the whole diff at once.
4. Split, revert, or defer individual areas if any part needs more time.
5. Merge to beta only after the complete package looks acceptable.

Found Bugs

Rule Apply Completion Could Finish Too Early

The rule apply path could treat IPv4 and IPv6 command batches as separate completions. If IPv4 finished first, the original callback could run while IPv6 was still applying.

That could dismiss the progress dialog early, report success too soon, or save rule state before the full apply sequence had finished.

The apply flow now behaves as one combined operation. IPv4 runs first, IPv6 follows when enabled, and the original callback is invoked only after the final required command batch completes.

Apply Dialogs Could Get Stuck Or Misreport State

Some root/apply paths did not tie UI completion tightly enough to the actual root command lifecycle. When a command failed or a follow-up apply path continued after the UI callback, the app could leave a dialog visible or report the wrong final state.

The apply flow now routes success and failure through a consistent completion path so the UI can close cleanly and display the correct final result.

Revoked Or Stale Root Grants Were Hard To Diagnose

A device can have a cached root request that later gets revoked by the root manager. In that state the app may look like it previously had permission, but command execution fails when rules are applied.

The root and apply paths now log more useful information when root access fails, rule application fails, or a command path cannot complete. Successful rule-related actions also write base log entries so there is a trace of what was attempted even when no exception occurs.

Boot Apply Could Reinstall Rules While Firewall Was Disabled

The boot receiver could schedule rule application even when the saved firewall state said the firewall was disabled.

That meant a reboot or delayed boot action could restore firewall rules after the user intentionally disabled protection.

Boot apply now checks the persisted firewall enabled state before scheduling initial or delayed apply work. If the firewall is disabled, no root rule batch is queued.

Fingerprint Security Could Break After Enrollment Changes

Android can invalidate biometric keystore keys when fingerprints are removed, re-enrolled, or the device lock screen changes.

The app could still have fingerprint security saved as enabled and continue trying to authenticate with a stale key.

Fingerprint setup and authentication now detect invalidated keys, missing enrollment, and insecure lock-screen state. When stale state is found, the outdated preference is disabled, the reason is logged, and the normal unavailable/failure path is used.

Protected Content Could Appear Behind Launch Security

The app list and profile controls could be visible behind the launch security prompt. On devices using pattern, fingerprint, or device security gates, protected content could appear before authentication completed.

The main list, search and filter controls, and profile controls now remain hidden until launch security reports success. Failed or canceled security keeps protected views unavailable.

Plugin Profile IDs Could Crash On Bad Input

Tasker/Locale plugin payloads could pass empty or non-numeric profile IDs. Those values were parsed later and could throw number parsing exceptions.

Plugin bundle handling now validates that the requested profile ID exists and is numeric before receiver or apply logic parses it.

Picker Export URI Permission Used The Wrong Flag Shape

The system picker export path masked returned intent flags and passed that computed bitmask into takePersistableUriPermission().

Android expects the explicit read/write URI grant constants. The helper now checks what was requested and what the picker actually granted, then persists only the exact read or write grant constant. Read and write persistence failures are logged separately.

Widget Callback Messages Could Be Reused

The widget profile apply path created a Message before an async root callback and reused it when the callback completed.

Android Message instances cannot be enqueued more than once after use, so repeated callback delivery could fail.

The callback now allocates a fresh message at delivery time.

Widget Activity Held Static View References

The old widget activity stored button view references in static fields. Static view references can outlive the activity instance and leak stale activity context after recreation or configuration changes.

Those references are now normal instance fields tied to the activity lifecycle.

Widget Disable Could Bypass Confirmation

Disabling the firewall from widgets could bypass the configured disable confirmation unless another security prompt was enabled.

Both widget implementations now route disable actions through the confirmation flow used by the app. Canceling stops the action, while accepting continues into the existing security path when needed.

Firewall Rule Fixes

IPv6 Control Traffic

The generated IPv6 rules could block required ICMPv6 control messages. Blocking router solicitation, router advertisement, neighbor solicitation, or neighbor advertisement can break IPv6 routing and neighbor discovery.

The IPv6 generator now adds early returns for required control message types before normal app and network filtering.

LAN And Loopback Handling

When LAN control was enabled, loopback traffic could be routed into LAN filtering instead of being treated as local device traffic. LAN discovery also missed common broadcast and multicast destinations.

Loopback interface traffic now returns before LAN chains are evaluated. LAN matching was expanded for IPv4 broadcast/multicast and IPv6 local discovery ranges.

Tor Redirect Ordering

Tor-selected traffic could hit Wi-Fi, mobile, or other interface filter chains before reaching Tor redirect handling. That could reject traffic intended for local Orbot redirect ports unless the user also allowed the app on the plain network.

Tor filtering now runs before regular interface chains. The redirect path allows only the local Tor/Orbot ports used by the redirect flow, and the invalid inbound owner-match path was removed.

DHCP Replies For Tethering

Tethering rules depended on known tether-related UIDs, but DHCP service ownership can vary by Android version and device build.

When tethering is allowed, generated rules now allow DHCP server replies by protocol and port in the tether paths: UDP source port 67 to destination port 68.

VPN Network Changes

Modern Android versions do not reliably deliver every VPN change through legacy connectivity broadcasts.

A network callback now tracks Android Network objects with VPN transport. Rules are refreshed when VPN capability appears, disappears, or a tracked VPN network is lost. Non-VPN network loss is ignored by this callback to avoid extra applies for unrelated Wi-Fi or mobile disconnects.

VPN And Tether Interface Detection

WireGuard kernel interfaces such as wg+ were missing from VPN interface matching. Bluetooth PAN interfaces such as bnep+ could also fall outside tether controls.

The interface lists now include WireGuard and Bluetooth tether patterns while preserving existing behavior where tether-specific controls are not active.

Firewall Reject Logging

Some per-network reject chains could reject packets without logging first. That made blocked traffic invisible in the application log for users relying on those paths.

Reject-chain generation now emits the configured log target before the final reject in relevant chains. Log parsing also falls back through UID resolution so hidden or profile-discovered apps can be named instead of showing as deleted when metadata is available.

Notable Performance Improvements

Profile App Discovery Scan

Secondary-profile discovery could perform repeated shell permission checks and write noisy per-package info logs.

The scan now caches shell-based INTERNET permission checks during each scan. It also replaces high-volume per-package logs with compact summary entries while preserving warnings for failed shell probes.

Stable App List Sorting

UID sorting could produce unstable order when apps shared a UID or tied on the primary sort key. That could make the app list appear to jump between refreshes.

Sorting now applies deterministic tie-breakers after UID comparison.

Theme Apply Behavior

Theme application was adjusted so switching themes does not repeatedly trigger launch security checks or create avoidable UI refresh lag.

Theme refresh behavior is separated from protected launch security flow, which prevents theme changes from repeatedly invoking security checks and reduces the lag seen after selecting a new theme.

App Improvements

Package Name Search And Display

A UI preference now allows package names to be shown next to app labels.

Search now matches package names as well as labels, which makes system apps, duplicate labels, missing labels, and package-oriented troubleshooting easier to handle.

Secondary Profile App Discovery

Some apps installed only in work, private, or secondary Android profiles were not returned through normal package-manager APIs.

The app scan now supplements package-manager results with shell-discovered per-user package data. Profile-only apps are added with their discovered UID and profile marker so they can be configured in firewall rules.

Settings And Rules Export

The settings/rules exporter now supports Android's system picker flow when configured. A UI preference allows switching between the existing export behavior and the built-in picker behavior.

The picker path checks URI permissions, persists only granted access, and logs permission persistence failures clearly.

Log Export Flow

Log export behavior was cleaned up so sending and saving logs is handled through the export flow instead of duplicating send options across log menus.

Users can choose whether logs should be saved to disk or sent through the configured share/email path. A setting was also added to choose zipped or raw log export behavior, with the default left as raw/unzipped.

Log Menu Cleanup

The main application log kept zoom controls and the error-report action where they are useful, while the other log sections avoid duplicate send options.

The email/report setting now belongs under the Export Logs flow in the Logs and Rules area, so users have one clear place to choose whether to save logs or send them.

Theming Additions

This branch adds new donor-gated theme presets and expands custom theme controls.

Included theme work:

• Five new preset themes.
• Preset themes now also update the system application color.
• Custom theme colors are seeded from the selected preset theme, making small edits easier.
• Custom colors and preset themes now follow the same application path instead of diverging into separate behavior.
• Status bar and navigation bar colors update to match selected themes.
• The custom color picker has a normal title bar and back button matching other menus.
• The custom color picker avoids drawing under the status bar.
• Default Android app icons can be recolored through custom theme controls.
• Theme access no longer repeatedly invokes launch security checks while switching themes.

Theme features remain donor-gated, and donor-app behavior remains supported.

Build Artifacts

This branch includes debug and signed release APK artifacts under published-builds/Bug-Attack/2026-06-26/.

Those are included for convenience while the branch is being reviewed. If the binaries are not wanted in the final beta history, that folder can be dropped before final merge.

Closing Notes

This is a large branch, but the changes are grouped around concrete behavior problems: stuck apply dialogs, stale root failures, missing logs, export picker issues, profile discovery gaps, theme consistency, and firewall rule correctness across IPv6, Tor, LAN, tethering, VPN, and widgets.

The safest path is to treat this as a draft integration PR, review it by section, and only merge to beta once the full package is acceptable.

[Mainkill1]

Not Needed