fix: do not crash at launch when the SDK cannot set the log directory by Ryanmello07 · Pull Request #473 · urnetwork/android

Ryanmello07 · 2026-09-01T03:32:47Z

One file, +10/−1.

MainApplication.onCreate calls Sdk.setLogDir(path) unguarded. gomobile binds that Go function's error return as a checked Java exception, and Kotlin does not enforce checked exceptions — so it compiles, and then a log directory that cannot be written (storage full, quota, EIO) propagates straight out of onCreate as an unhandled crash on every launch.

The SDK's own doc comment states the opposite intent: logging must never be what breaks a launch. glog keeps whatever destination it already had, so continuing is safe.

try {
Sdk.setLogDir(path)
} catch (e:Exception) {
Log.i(TAG, "could not set the log dir to $path: ${e.message}")
}

Which function is called is unchanged — this is purely the guard.

Verification

Honestly: this was not compiled locally. The machine it was written on has no JDK and no Android SDK/NDK (java -version fails, ANDROID_HOME unset). It was verified by reading — the caught type is right for a gomobile-bound throwing call, imports are present, brace balance confirmed, and the diff touches exactly one file with no trailing whitespace. This PR's CI run is its first real compile check, which given the size seems a reasonable trade, but worth stating rather than implying otherwise.

🤖 Generated with Claude Code

Sdk.setLogDir is called unguarded in Application.onCreate. Go's SetLogDir returns an error, which gomobile binds into java as `throws Exception`, and kotlin does not enforce checked exceptions -- so the call compiles and then propagates straight out of onCreate: an unhandled crash on every launch on any install where the log directory cannot be written (storage full, quota, EIO). A recoverable logging problem became an unbootable app. Wrap the existing call so the failure is logged and startup continues; glog keeps whatever destination it already had. Logging must never be what breaks a launch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that #473 added -- the sdk still returns an error when the directory cannot be created, because its os.TempDir() fallback lands on /data/local/tmp, which an app uid cannot write. The retention pass (clearOldLogs) only ever prunes the directory glog is currently pointed at, so moving the root would strand whatever pre-upgrade builds wrote into filesDir: up to four files of up to 16MB each, never pruned again, and no longer reachable through Sdk.getLogDir() -- which is what the feedback screen's share and export buttons read. A user who upgraded and then reported an incident that predated the upgrade would attach none of the logs that recorded it. So migrateLegacyLogFiles moves those files into the new per-process directory BEFORE glog is repointed, which hands the merged set to the same retention pass rather than doubling the storage. It renames rather than copies, never overwrites a file already under the new root (a name collision means an earlier launch already migrated it), and never deletes a log it could not move. Android is single-process, so "app" is the only subdirectory that ever appears; the layout matches iOS, where the app and the network extension would otherwise prune each other's history out of a shared directory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

Ryanmello07 · 2026-09-01T03:32:47Z

One file, +10/−1.

MainApplication.onCreate calls Sdk.setLogDir(path) unguarded. gomobile binds that Go function's error return as a checked Java exception, and Kotlin does not enforce checked exceptions — so it compiles, and then a log directory that cannot be written (storage full, quota, EIO) propagates straight out of onCreate as an unhandled crash on every launch.

The SDK's own doc comment states the opposite intent: logging must never be what breaks a launch. glog keeps whatever destination it already had, so continuing is safe.

try {
Sdk.setLogDir(path)
} catch (e:Exception) {
Log.i(TAG, "could not set the log dir to $path: ${e.message}")
}

Which function is called is unchanged — this is purely the guard.

Verification

Honestly: this was not compiled locally. The machine it was written on has no JDK and no Android SDK/NDK (java -version fails, ANDROID_HOME unset). It was verified by reading — the caught type is right for a gomobile-bound throwing call, imports are present, brace balance confirmed, and the diff touches exactly one file with no trailing whitespace. This PR's CI run is its first real compile check, which given the size seems a reasonable trade, but worth stating rather than implying otherwise.

🤖 Generated with Claude Code

Sdk.setLogDir is called unguarded in Application.onCreate. Go's SetLogDir returns an error, which gomobile binds into java as `throws Exception`, and kotlin does not enforce checked exceptions -- so the call compiles and then propagates straight out of onCreate: an unhandled crash on every launch on any install where the log directory cannot be written (storage full, quota, EIO). A recoverable logging problem became an unbootable app. Wrap the existing call so the failure is logged and startup continues; glog keeps whatever destination it already had. Logging must never be what breaks a launch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that #473 added -- the sdk still returns an error when the directory cannot be created, because its os.TempDir() fallback lands on /data/local/tmp, which an app uid cannot write. The retention pass (clearOldLogs) only ever prunes the directory glog is currently pointed at, so moving the root would strand whatever pre-upgrade builds wrote into filesDir: up to four files of up to 16MB each, never pruned again, and no longer reachable through Sdk.getLogDir() -- which is what the feedback screen's share and export buttons read. A user who upgraded and then reported an incident that predated the upgrade would attach none of the logs that recorded it. So migrateLegacyLogFiles moves those files into the new per-process directory BEFORE glog is repointed, which hands the merged set to the same retention pass rather than doubling the storage. It renames rather than copies, never overwrites a file already under the new root (a name collision means an earlier launch already migrated it), and never deletes a log it could not move. Android is single-process, so "app" is the only subdirectory that ever appears; the layout matches iOS, where the app and the network extension would otherwise prune each other's history out of a shared directory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

Ryanmello07 · 2026-09-01T03:32:47Z

One file, +10/−1.

MainApplication.onCreate calls Sdk.setLogDir(path) unguarded. gomobile binds that Go function's error return as a checked Java exception, and Kotlin does not enforce checked exceptions — so it compiles, and then a log directory that cannot be written (storage full, quota, EIO) propagates straight out of onCreate as an unhandled crash on every launch.

The SDK's own doc comment states the opposite intent: logging must never be what breaks a launch. glog keeps whatever destination it already had, so continuing is safe.

try {
Sdk.setLogDir(path)
} catch (e:Exception) {
Log.i(TAG, "could not set the log dir to $path: ${e.message}")
}

Which function is called is unchanged — this is purely the guard.

Verification

Honestly: this was not compiled locally. The machine it was written on has no JDK and no Android SDK/NDK (java -version fails, ANDROID_HOME unset). It was verified by reading — the caught type is right for a gomobile-bound throwing call, imports are present, brace balance confirmed, and the diff touches exactly one file with no trailing whitespace. This PR's CI run is its first real compile check, which given the size seems a reasonable trade, but worth stating rather than implying otherwise.

🤖 Generated with Claude Code

Sdk.setLogDir is called unguarded in Application.onCreate. Go's SetLogDir returns an error, which gomobile binds into java as `throws Exception`, and kotlin does not enforce checked exceptions -- so the call compiles and then propagates straight out of onCreate: an unhandled crash on every launch on any install where the log directory cannot be written (storage full, quota, EIO). A recoverable logging problem became an unbootable app. Wrap the existing call so the failure is logged and startup continues; glog keeps whatever destination it already had. Logging must never be what breaks a launch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that #473 added -- the sdk still returns an error when the directory cannot be created, because its os.TempDir() fallback lands on /data/local/tmp, which an app uid cannot write. The retention pass (clearOldLogs) only ever prunes the directory glog is currently pointed at, so moving the root would strand whatever pre-upgrade builds wrote into filesDir: up to four files of up to 16MB each, never pruned again, and no longer reachable through Sdk.getLogDir() -- which is what the feedback screen's share and export buttons read. A user who upgraded and then reported an incident that predated the upgrade would attach none of the logs that recorded it. So migrateLegacyLogFiles moves those files into the new per-process directory BEFORE glog is repointed, which hands the merged set to the same retention pass rather than doubling the storage. It renames rather than copies, never overwrites a file already under the new root (a name collision means an earlier launch already migrated it), and never deletes a log it could not move. Android is single-process, so "app" is the only subdirectory that ever appears; the layout matches iOS, where the app and the network extension would otherwise prune each other's history out of a shared directory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

Ryanmello07 · 2026-09-01T03:32:47Z

One file, +10/−1.

MainApplication.onCreate calls Sdk.setLogDir(path) unguarded. gomobile binds that Go function's error return as a checked Java exception, and Kotlin does not enforce checked exceptions — so it compiles, and then a log directory that cannot be written (storage full, quota, EIO) propagates straight out of onCreate as an unhandled crash on every launch.

The SDK's own doc comment states the opposite intent: logging must never be what breaks a launch. glog keeps whatever destination it already had, so continuing is safe.

try {
Sdk.setLogDir(path)
} catch (e:Exception) {
Log.i(TAG, "could not set the log dir to $path: ${e.message}")
}

Which function is called is unchanged — this is purely the guard.

Verification

Honestly: this was not compiled locally. The machine it was written on has no JDK and no Android SDK/NDK (java -version fails, ANDROID_HOME unset). It was verified by reading — the caught type is right for a gomobile-bound throwing call, imports are present, brace balance confirmed, and the diff touches exactly one file with no trailing whitespace. This PR's CI run is its first real compile check, which given the size seems a reasonable trade, but worth stating rather than implying otherwise.

🤖 Generated with Claude Code

Sdk.setLogDir is called unguarded in Application.onCreate. Go's SetLogDir returns an error, which gomobile binds into java as `throws Exception`, and kotlin does not enforce checked exceptions -- so the call compiles and then propagates straight out of onCreate: an unhandled crash on every launch on any install where the log directory cannot be written (storage full, quota, EIO). A recoverable logging problem became an unbootable app. Wrap the existing call so the failure is logged and startup continues; glog keeps whatever destination it already had. Logging must never be what breaks a launch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that #473 added -- the sdk still returns an error when the directory cannot be created, because its os.TempDir() fallback lands on /data/local/tmp, which an app uid cannot write. The retention pass (clearOldLogs) only ever prunes the directory glog is currently pointed at, so moving the root would strand whatever pre-upgrade builds wrote into filesDir: up to four files of up to 16MB each, never pruned again, and no longer reachable through Sdk.getLogDir() -- which is what the feedback screen's share and export buttons read. A user who upgraded and then reported an incident that predated the upgrade would attach none of the logs that recorded it. So migrateLegacyLogFiles moves those files into the new per-process directory BEFORE glog is repointed, which hands the merged set to the same retention pass rather than doubling the storage. It renames rather than copies, never overwrites a file already under the new root (a name collision means an earlier launch already migrated it), and never deletes a log it could not move. Android is single-process, so "app" is the only subdirectory that ever appears; the layout matches iOS, where the app and the network extension would otherwise prune each other's history out of a shared directory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

Ryanmello07 · 2026-09-01T03:32:47Z

One file, +10/−1.

MainApplication.onCreate calls Sdk.setLogDir(path) unguarded. gomobile binds that Go function's error return as a checked Java exception, and Kotlin does not enforce checked exceptions — so it compiles, and then a log directory that cannot be written (storage full, quota, EIO) propagates straight out of onCreate as an unhandled crash on every launch.

The SDK's own doc comment states the opposite intent: logging must never be what breaks a launch. glog keeps whatever destination it already had, so continuing is safe.

try {
Sdk.setLogDir(path)
} catch (e:Exception) {
Log.i(TAG, "could not set the log dir to $path: ${e.message}")
}

Which function is called is unchanged — this is purely the guard.

Verification

Honestly: this was not compiled locally. The machine it was written on has no JDK and no Android SDK/NDK (java -version fails, ANDROID_HOME unset). It was verified by reading — the caught type is right for a gomobile-bound throwing call, imports are present, brace balance confirmed, and the diff touches exactly one file with no trailing whitespace. This PR's CI run is its first real compile check, which given the size seems a reasonable trade, but worth stating rather than implying otherwise.

🤖 Generated with Claude Code

Sdk.setLogDir is called unguarded in Application.onCreate. Go's SetLogDir returns an error, which gomobile binds into java as `throws Exception`, and kotlin does not enforce checked exceptions -- so the call compiles and then propagates straight out of onCreate: an unhandled crash on every launch on any install where the log directory cannot be written (storage full, quota, EIO). A recoverable logging problem became an unbootable app. Wrap the existing call so the failure is logged and startup continues; glog keeps whatever destination it already had. Logging must never be what breaks a launch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that #473 added -- the sdk still returns an error when the directory cannot be created, because its os.TempDir() fallback lands on /data/local/tmp, which an app uid cannot write. The retention pass (clearOldLogs) only ever prunes the directory glog is currently pointed at, so moving the root would strand whatever pre-upgrade builds wrote into filesDir: up to four files of up to 16MB each, never pruned again, and no longer reachable through Sdk.getLogDir() -- which is what the feedback screen's share and export buttons read. A user who upgraded and then reported an incident that predated the upgrade would attach none of the logs that recorded it. So migrateLegacyLogFiles moves those files into the new per-process directory BEFORE glog is repointed, which hands the merged set to the same retention pass rather than doubling the storage. It renames rather than copies, never overwrites a file already under the new root (a name collision means an earlier launch already migrated it), and never deletes a log it could not move. Android is single-process, so "app" is the only subdirectory that ever appears; the layout matches iOS, where the app and the network extension would otherwise prune each other's history out of a shared directory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

Ryanmello07 · 2026-09-01T03:32:47Z

One file, +10/−1.

MainApplication.onCreate calls Sdk.setLogDir(path) unguarded. gomobile binds that Go function's error return as a checked Java exception, and Kotlin does not enforce checked exceptions — so it compiles, and then a log directory that cannot be written (storage full, quota, EIO) propagates straight out of onCreate as an unhandled crash on every launch.

The SDK's own doc comment states the opposite intent: logging must never be what breaks a launch. glog keeps whatever destination it already had, so continuing is safe.

try {
Sdk.setLogDir(path)
} catch (e:Exception) {
Log.i(TAG, "could not set the log dir to $path: ${e.message}")
}

Which function is called is unchanged — this is purely the guard.

Verification

Honestly: this was not compiled locally. The machine it was written on has no JDK and no Android SDK/NDK (java -version fails, ANDROID_HOME unset). It was verified by reading — the caught type is right for a gomobile-bound throwing call, imports are present, brace balance confirmed, and the diff touches exactly one file with no trailing whitespace. This PR's CI run is its first real compile check, which given the size seems a reasonable trade, but worth stating rather than implying otherwise.

🤖 Generated with Claude Code

Sdk.setLogDir is called unguarded in Application.onCreate. Go's SetLogDir returns an error, which gomobile binds into java as `throws Exception`, and kotlin does not enforce checked exceptions -- so the call compiles and then propagates straight out of onCreate: an unhandled crash on every launch on any install where the log directory cannot be written (storage full, quota, EIO). A recoverable logging problem became an unbootable app. Wrap the existing call so the failure is logged and startup continues; glog keeps whatever destination it already had. Logging must never be what breaks a launch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that #473 added -- the sdk still returns an error when the directory cannot be created, because its os.TempDir() fallback lands on /data/local/tmp, which an app uid cannot write. The retention pass (clearOldLogs) only ever prunes the directory glog is currently pointed at, so moving the root would strand whatever pre-upgrade builds wrote into filesDir: up to four files of up to 16MB each, never pruned again, and no longer reachable through Sdk.getLogDir() -- which is what the feedback screen's share and export buttons read. A user who upgraded and then reported an incident that predated the upgrade would attach none of the logs that recorded it. So migrateLegacyLogFiles moves those files into the new per-process directory BEFORE glog is repointed, which hands the merged set to the same retention pass rather than doubling the storage. It renames rather than copies, never overwrites a file already under the new root (a name collision means an earlier launch already migrated it), and never deletes a log it could not move. Android is single-process, so "app" is the only subdirectory that ever appears; the layout matches iOS, where the app and the network extension would otherwise prune each other's history out of a shared directory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

Ryanmello07 · 2026-09-01T03:32:47Z

One file, +10/−1.

MainApplication.onCreate calls Sdk.setLogDir(path) unguarded. gomobile binds that Go function's error return as a checked Java exception, and Kotlin does not enforce checked exceptions — so it compiles, and then a log directory that cannot be written (storage full, quota, EIO) propagates straight out of onCreate as an unhandled crash on every launch.

The SDK's own doc comment states the opposite intent: logging must never be what breaks a launch. glog keeps whatever destination it already had, so continuing is safe.

try {
Sdk.setLogDir(path)
} catch (e:Exception) {
Log.i(TAG, "could not set the log dir to $path: ${e.message}")
}

Which function is called is unchanged — this is purely the guard.

Verification

Honestly: this was not compiled locally. The machine it was written on has no JDK and no Android SDK/NDK (java -version fails, ANDROID_HOME unset). It was verified by reading — the caught type is right for a gomobile-bound throwing call, imports are present, brace balance confirmed, and the diff touches exactly one file with no trailing whitespace. This PR's CI run is its first real compile check, which given the size seems a reasonable trade, but worth stating rather than implying otherwise.

🤖 Generated with Claude Code

Sdk.setLogDir is called unguarded in Application.onCreate. Go's SetLogDir returns an error, which gomobile binds into java as `throws Exception`, and kotlin does not enforce checked exceptions -- so the call compiles and then propagates straight out of onCreate: an unhandled crash on every launch on any install where the log directory cannot be written (storage full, quota, EIO). A recoverable logging problem became an unbootable app. Wrap the existing call so the failure is logged and startup continues; glog keeps whatever destination it already had. Logging must never be what breaks a launch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that #473 added -- the sdk still returns an error when the directory cannot be created, because its os.TempDir() fallback lands on /data/local/tmp, which an app uid cannot write. The retention pass (clearOldLogs) only ever prunes the directory glog is currently pointed at, so moving the root would strand whatever pre-upgrade builds wrote into filesDir: up to four files of up to 16MB each, never pruned again, and no longer reachable through Sdk.getLogDir() -- which is what the feedback screen's share and export buttons read. A user who upgraded and then reported an incident that predated the upgrade would attach none of the logs that recorded it. So migrateLegacyLogFiles moves those files into the new per-process directory BEFORE glog is repointed, which hands the merged set to the same retention pass rather than doubling the storage. It renames rather than copies, never overwrites a file already under the new root (a name collision means an earlier launch already migrated it), and never deletes a log it could not move. Android is single-process, so "app" is the only subdirectory that ever appears; the layout matches iOS, where the app and the network extension would otherwise prune each other's history out of a shared directory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

Ryanmello07 · 2026-09-01T03:32:47Z

One file, +10/−1.

MainApplication.onCreate calls Sdk.setLogDir(path) unguarded. gomobile binds that Go function's error return as a checked Java exception, and Kotlin does not enforce checked exceptions — so it compiles, and then a log directory that cannot be written (storage full, quota, EIO) propagates straight out of onCreate as an unhandled crash on every launch.

The SDK's own doc comment states the opposite intent: logging must never be what breaks a launch. glog keeps whatever destination it already had, so continuing is safe.

try {
Sdk.setLogDir(path)
} catch (e:Exception) {
Log.i(TAG, "could not set the log dir to $path: ${e.message}")
}

Which function is called is unchanged — this is purely the guard.

Verification

Honestly: this was not compiled locally. The machine it was written on has no JDK and no Android SDK/NDK (java -version fails, ANDROID_HOME unset). It was verified by reading — the caught type is right for a gomobile-bound throwing call, imports are present, brace balance confirmed, and the diff touches exactly one file with no trailing whitespace. This PR's CI run is its first real compile check, which given the size seems a reasonable trade, but worth stating rather than implying otherwise.

🤖 Generated with Claude Code

Sdk.setLogDir is called unguarded in Application.onCreate. Go's SetLogDir returns an error, which gomobile binds into java as `throws Exception`, and kotlin does not enforce checked exceptions -- so the call compiles and then propagates straight out of onCreate: an unhandled crash on every launch on any install where the log directory cannot be written (storage full, quota, EIO). A recoverable logging problem became an unbootable app. Wrap the existing call so the failure is logged and startup continues; glog keeps whatever destination it already had. Logging must never be what breaks a launch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that #473 added -- the sdk still returns an error when the directory cannot be created, because its os.TempDir() fallback lands on /data/local/tmp, which an app uid cannot write. The retention pass (clearOldLogs) only ever prunes the directory glog is currently pointed at, so moving the root would strand whatever pre-upgrade builds wrote into filesDir: up to four files of up to 16MB each, never pruned again, and no longer reachable through Sdk.getLogDir() -- which is what the feedback screen's share and export buttons read. A user who upgraded and then reported an incident that predated the upgrade would attach none of the logs that recorded it. So migrateLegacyLogFiles moves those files into the new per-process directory BEFORE glog is repointed, which hands the merged set to the same retention pass rather than doubling the storage. It renames rather than copies, never overwrites a file already under the new root (a name collision means an earlier launch already migrated it), and never deletes a log it could not move. Android is single-process, so "app" is the only subdirectory that ever appears; the layout matches iOS, where the app and the network extension would otherwise prune each other's history out of a shared directory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014vN7zh8WeQYCtirhcA3aWw

Ryanmello07 merged commit af4baef into urnetwork:mainSep 1, 2026
2 checks passed

Ryanmello07 mentioned this pull request Sep 1, 2026
feat: per-process glog root, and migrate pre-upgrade log files into it #474
Merged