Description
The audit logs in Browser Limit lack sufficient detail to be genuinely useful for debugging or understanding what happened during detection and uninstall events. Key information is missing, and the export format is limited.
Problems
1. shizukuResult field exists but is never populated
The LogEntry model has a shizukuResult field, but it is never written to in any call site (AppInstallReceiver, OverlayActivity, LogsScreen recheck). When an uninstall fails, there is no record of the Shizuku command output or error.
2. No error details captured on failure
When decision == "Error", there is no field to store the exception message, stack trace, or reason code. You just see "Error" with no way to know what went wrong.
3. No app version tracking
The app's version code / version name is not captured. If a user reinstalls a browser or an update bypasses detection, there is no way to correlate the event with the app version.
4. No search, filter, or pagination in the log viewer
With up to 500 stored logs, there is no way to search by package name, filter by decision type, or view logs within a date range.
5. Poor export format
The bulk export produces a simple pipe-delimited text file with no headers, no CSV/JSON option, and no share intent integration. It always exports all logs or nothing.
6. No log sharing
Logs can only be saved to the Downloads folder. There is no share/send intent, making it cumbersome to attach logs to a bug report.
Proposed Improvements
- Populate
shizukuResult in all call sites with actual Shizuku output
- Add an
errorDetails / exceptionMessage field to LogEntry
- Capture
appVersionCode and appVersionName at detection time
- Add search/filter UI to the logs screen (by package name, decision, date range)
- Add CSV and JSON export options
- Add a share intent for log export
- Consider adding detection duration / API call timing to help diagnose performance issues
Affected Area
- Audit Log
- Detection / Engine
- Overlay / Countdown
Description
The audit logs in Browser Limit lack sufficient detail to be genuinely useful for debugging or understanding what happened during detection and uninstall events. Key information is missing, and the export format is limited.
Problems
1.
shizukuResultfield exists but is never populatedThe
LogEntrymodel has ashizukuResultfield, but it is never written to in any call site (AppInstallReceiver, OverlayActivity, LogsScreen recheck). When an uninstall fails, there is no record of the Shizuku command output or error.2. No error details captured on failure
When
decision == "Error", there is no field to store the exception message, stack trace, or reason code. You just see "Error" with no way to know what went wrong.3. No app version tracking
The app's version code / version name is not captured. If a user reinstalls a browser or an update bypasses detection, there is no way to correlate the event with the app version.
4. No search, filter, or pagination in the log viewer
With up to 500 stored logs, there is no way to search by package name, filter by decision type, or view logs within a date range.
5. Poor export format
The bulk export produces a simple pipe-delimited text file with no headers, no CSV/JSON option, and no share intent integration. It always exports all logs or nothing.
6. No log sharing
Logs can only be saved to the Downloads folder. There is no share/send intent, making it cumbersome to attach logs to a bug report.
Proposed Improvements
shizukuResultin all call sites with actual Shizuku outputerrorDetails/exceptionMessagefield toLogEntryappVersionCodeandappVersionNameat detection timeAffected Area