feat: per-process glog root, and migrate pre-upgrade log files into it by Ryanmello07 · Pull Request #474 · urnetwork/android

Ryanmello07 · 2026-09-01T05:50:41Z

3 files, +212/−8. First of three stacked Android PRs. Needs urnetwork/sdk#149 (merged).

Switches MainApplication from Sdk.setLogDir(filesDir) to Sdk.setLogDirForProcess(<filesDir>/logs, "app"), keeping the try/catch guard from #473.

The migration is the part that matters

Pre-upgrade builds wrote glog files straight into filesDir. Once the root moves, nothing ever prunes or exports that directory again — so the old files become both dead storage (up to ~64 MB: 4 files × the 16 MiB cap) and unreachable evidence. A user who upgrades and then exports to report an incident predating the upgrade would get none of the logs that recorded it.

The migration runs before glog is pointed at the new directory, so the SDK's retention pass treats the moved files as part of the app's own history and keeps the newest four of the merged set. Running it first also means glog isn't yet writing into filesDir in this process, so the renames can't race a live file handle.

Behaviour change worth knowing

FeedbackScreen's existing Share/Export log buttons read Sdk.getLogDir(), which now returns <filesDir>/logs/app rather than <filesDir>. That's the intended outcome, and the migration is precisely what keeps those buttons showing pre-upgrade logs.

res/xml/file_paths.xml already declares <files-path name="logs" path="."/> (the whole filesDir), so FileProvider still resolves the new subdirectory with no manifest change.

One-way door, stated plainly

The migration is a one-way rename with no rollback: a user who downgrades to a pre-upgrade build won't see the moved files, since the old build reads filesDir directly. That seems clearly right — the alternative strands them permanently — but it is a real one-way door and isn't covered by a test.

Verification

Not compiled locally — no JDK, Android SDK or NDK available. This PR's CI run is the first place the Kotlin compiler and the four new tests actually execute. Verified by inspection: every SDK symbol greped against the Go source at sdk@main (including confirming SetLogDirForProcess really can return an error, so the guard isn't dead code), brace/paren balance, overload resolution, and all four tests walked by hand against the implementation.

🤖 Generated with Claude Code

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that urnetwork#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-01T05:50:41Z

3 files, +212/−8. First of three stacked Android PRs. Needs urnetwork/sdk#149 (merged).

Switches MainApplication from Sdk.setLogDir(filesDir) to Sdk.setLogDirForProcess(<filesDir>/logs, "app"), keeping the try/catch guard from #473.

The migration is the part that matters

Pre-upgrade builds wrote glog files straight into filesDir. Once the root moves, nothing ever prunes or exports that directory again — so the old files become both dead storage (up to ~64 MB: 4 files × the 16 MiB cap) and unreachable evidence. A user who upgrades and then exports to report an incident predating the upgrade would get none of the logs that recorded it.

The migration runs before glog is pointed at the new directory, so the SDK's retention pass treats the moved files as part of the app's own history and keeps the newest four of the merged set. Running it first also means glog isn't yet writing into filesDir in this process, so the renames can't race a live file handle.

Behaviour change worth knowing

FeedbackScreen's existing Share/Export log buttons read Sdk.getLogDir(), which now returns <filesDir>/logs/app rather than <filesDir>. That's the intended outcome, and the migration is precisely what keeps those buttons showing pre-upgrade logs.

res/xml/file_paths.xml already declares <files-path name="logs" path="."/> (the whole filesDir), so FileProvider still resolves the new subdirectory with no manifest change.

One-way door, stated plainly

The migration is a one-way rename with no rollback: a user who downgrades to a pre-upgrade build won't see the moved files, since the old build reads filesDir directly. That seems clearly right — the alternative strands them permanently — but it is a real one-way door and isn't covered by a test.

Verification

Not compiled locally — no JDK, Android SDK or NDK available. This PR's CI run is the first place the Kotlin compiler and the four new tests actually execute. Verified by inspection: every SDK symbol greped against the Go source at sdk@main (including confirming SetLogDirForProcess really can return an error, so the guard isn't dead code), brace/paren balance, overload resolution, and all four tests walked by hand against the implementation.

🤖 Generated with Claude Code

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that urnetwork#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-01T05:50:41Z

3 files, +212/−8. First of three stacked Android PRs. Needs urnetwork/sdk#149 (merged).

Switches MainApplication from Sdk.setLogDir(filesDir) to Sdk.setLogDirForProcess(<filesDir>/logs, "app"), keeping the try/catch guard from #473.

The migration is the part that matters

Pre-upgrade builds wrote glog files straight into filesDir. Once the root moves, nothing ever prunes or exports that directory again — so the old files become both dead storage (up to ~64 MB: 4 files × the 16 MiB cap) and unreachable evidence. A user who upgrades and then exports to report an incident predating the upgrade would get none of the logs that recorded it.

The migration runs before glog is pointed at the new directory, so the SDK's retention pass treats the moved files as part of the app's own history and keeps the newest four of the merged set. Running it first also means glog isn't yet writing into filesDir in this process, so the renames can't race a live file handle.

Behaviour change worth knowing

FeedbackScreen's existing Share/Export log buttons read Sdk.getLogDir(), which now returns <filesDir>/logs/app rather than <filesDir>. That's the intended outcome, and the migration is precisely what keeps those buttons showing pre-upgrade logs.

res/xml/file_paths.xml already declares <files-path name="logs" path="."/> (the whole filesDir), so FileProvider still resolves the new subdirectory with no manifest change.

One-way door, stated plainly

The migration is a one-way rename with no rollback: a user who downgrades to a pre-upgrade build won't see the moved files, since the old build reads filesDir directly. That seems clearly right — the alternative strands them permanently — but it is a real one-way door and isn't covered by a test.

Verification

Not compiled locally — no JDK, Android SDK or NDK available. This PR's CI run is the first place the Kotlin compiler and the four new tests actually execute. Verified by inspection: every SDK symbol greped against the Go source at sdk@main (including confirming SetLogDirForProcess really can return an error, so the guard isn't dead code), brace/paren balance, overload resolution, and all four tests walked by hand against the implementation.

🤖 Generated with Claude Code

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that urnetwork#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-01T05:50:41Z

3 files, +212/−8. First of three stacked Android PRs. Needs urnetwork/sdk#149 (merged).

Switches MainApplication from Sdk.setLogDir(filesDir) to Sdk.setLogDirForProcess(<filesDir>/logs, "app"), keeping the try/catch guard from #473.

The migration is the part that matters

Pre-upgrade builds wrote glog files straight into filesDir. Once the root moves, nothing ever prunes or exports that directory again — so the old files become both dead storage (up to ~64 MB: 4 files × the 16 MiB cap) and unreachable evidence. A user who upgrades and then exports to report an incident predating the upgrade would get none of the logs that recorded it.

The migration runs before glog is pointed at the new directory, so the SDK's retention pass treats the moved files as part of the app's own history and keeps the newest four of the merged set. Running it first also means glog isn't yet writing into filesDir in this process, so the renames can't race a live file handle.

Behaviour change worth knowing

FeedbackScreen's existing Share/Export log buttons read Sdk.getLogDir(), which now returns <filesDir>/logs/app rather than <filesDir>. That's the intended outcome, and the migration is precisely what keeps those buttons showing pre-upgrade logs.

res/xml/file_paths.xml already declares <files-path name="logs" path="."/> (the whole filesDir), so FileProvider still resolves the new subdirectory with no manifest change.

One-way door, stated plainly

The migration is a one-way rename with no rollback: a user who downgrades to a pre-upgrade build won't see the moved files, since the old build reads filesDir directly. That seems clearly right — the alternative strands them permanently — but it is a real one-way door and isn't covered by a test.

Verification

Not compiled locally — no JDK, Android SDK or NDK available. This PR's CI run is the first place the Kotlin compiler and the four new tests actually execute. Verified by inspection: every SDK symbol greped against the Go source at sdk@main (including confirming SetLogDirForProcess really can return an error, so the guard isn't dead code), brace/paren balance, overload resolution, and all four tests walked by hand against the implementation.

🤖 Generated with Claude Code

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that urnetwork#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-01T05:50:41Z

3 files, +212/−8. First of three stacked Android PRs. Needs urnetwork/sdk#149 (merged).

Switches MainApplication from Sdk.setLogDir(filesDir) to Sdk.setLogDirForProcess(<filesDir>/logs, "app"), keeping the try/catch guard from #473.

The migration is the part that matters

Pre-upgrade builds wrote glog files straight into filesDir. Once the root moves, nothing ever prunes or exports that directory again — so the old files become both dead storage (up to ~64 MB: 4 files × the 16 MiB cap) and unreachable evidence. A user who upgrades and then exports to report an incident predating the upgrade would get none of the logs that recorded it.

The migration runs before glog is pointed at the new directory, so the SDK's retention pass treats the moved files as part of the app's own history and keeps the newest four of the merged set. Running it first also means glog isn't yet writing into filesDir in this process, so the renames can't race a live file handle.

Behaviour change worth knowing

FeedbackScreen's existing Share/Export log buttons read Sdk.getLogDir(), which now returns <filesDir>/logs/app rather than <filesDir>. That's the intended outcome, and the migration is precisely what keeps those buttons showing pre-upgrade logs.

res/xml/file_paths.xml already declares <files-path name="logs" path="."/> (the whole filesDir), so FileProvider still resolves the new subdirectory with no manifest change.

One-way door, stated plainly

The migration is a one-way rename with no rollback: a user who downgrades to a pre-upgrade build won't see the moved files, since the old build reads filesDir directly. That seems clearly right — the alternative strands them permanently — but it is a real one-way door and isn't covered by a test.

Verification

Not compiled locally — no JDK, Android SDK or NDK available. This PR's CI run is the first place the Kotlin compiler and the four new tests actually execute. Verified by inspection: every SDK symbol greped against the Go source at sdk@main (including confirming SetLogDirForProcess really can return an error, so the guard isn't dead code), brace/paren balance, overload resolution, and all four tests walked by hand against the implementation.

🤖 Generated with Claude Code

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that urnetwork#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-01T05:50:41Z

3 files, +212/−8. First of three stacked Android PRs. Needs urnetwork/sdk#149 (merged).

Switches MainApplication from Sdk.setLogDir(filesDir) to Sdk.setLogDirForProcess(<filesDir>/logs, "app"), keeping the try/catch guard from #473.

The migration is the part that matters

Pre-upgrade builds wrote glog files straight into filesDir. Once the root moves, nothing ever prunes or exports that directory again — so the old files become both dead storage (up to ~64 MB: 4 files × the 16 MiB cap) and unreachable evidence. A user who upgrades and then exports to report an incident predating the upgrade would get none of the logs that recorded it.

The migration runs before glog is pointed at the new directory, so the SDK's retention pass treats the moved files as part of the app's own history and keeps the newest four of the merged set. Running it first also means glog isn't yet writing into filesDir in this process, so the renames can't race a live file handle.

Behaviour change worth knowing

FeedbackScreen's existing Share/Export log buttons read Sdk.getLogDir(), which now returns <filesDir>/logs/app rather than <filesDir>. That's the intended outcome, and the migration is precisely what keeps those buttons showing pre-upgrade logs.

res/xml/file_paths.xml already declares <files-path name="logs" path="."/> (the whole filesDir), so FileProvider still resolves the new subdirectory with no manifest change.

One-way door, stated plainly

The migration is a one-way rename with no rollback: a user who downgrades to a pre-upgrade build won't see the moved files, since the old build reads filesDir directly. That seems clearly right — the alternative strands them permanently — but it is a real one-way door and isn't covered by a test.

Verification

Not compiled locally — no JDK, Android SDK or NDK available. This PR's CI run is the first place the Kotlin compiler and the four new tests actually execute. Verified by inspection: every SDK symbol greped against the Go source at sdk@main (including confirming SetLogDirForProcess really can return an error, so the guard isn't dead code), brace/paren balance, overload resolution, and all four tests walked by hand against the implementation.

🤖 Generated with Claude Code

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that urnetwork#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-01T05:50:41Z

3 files, +212/−8. First of three stacked Android PRs. Needs urnetwork/sdk#149 (merged).

Switches MainApplication from Sdk.setLogDir(filesDir) to Sdk.setLogDirForProcess(<filesDir>/logs, "app"), keeping the try/catch guard from #473.

The migration is the part that matters

Pre-upgrade builds wrote glog files straight into filesDir. Once the root moves, nothing ever prunes or exports that directory again — so the old files become both dead storage (up to ~64 MB: 4 files × the 16 MiB cap) and unreachable evidence. A user who upgrades and then exports to report an incident predating the upgrade would get none of the logs that recorded it.

The migration runs before glog is pointed at the new directory, so the SDK's retention pass treats the moved files as part of the app's own history and keeps the newest four of the merged set. Running it first also means glog isn't yet writing into filesDir in this process, so the renames can't race a live file handle.

Behaviour change worth knowing

FeedbackScreen's existing Share/Export log buttons read Sdk.getLogDir(), which now returns <filesDir>/logs/app rather than <filesDir>. That's the intended outcome, and the migration is precisely what keeps those buttons showing pre-upgrade logs.

res/xml/file_paths.xml already declares <files-path name="logs" path="."/> (the whole filesDir), so FileProvider still resolves the new subdirectory with no manifest change.

One-way door, stated plainly

The migration is a one-way rename with no rollback: a user who downgrades to a pre-upgrade build won't see the moved files, since the old build reads filesDir directly. That seems clearly right — the alternative strands them permanently — but it is a real one-way door and isn't covered by a test.

Verification

Not compiled locally — no JDK, Android SDK or NDK available. This PR's CI run is the first place the Kotlin compiler and the four new tests actually execute. Verified by inspection: every SDK symbol greped against the Go source at sdk@main (including confirming SetLogDirForProcess really can return an error, so the guard isn't dead code), brace/paren balance, overload resolution, and all four tests walked by hand against the implementation.

🤖 Generated with Claude Code

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that urnetwork#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-01T05:50:41Z

3 files, +212/−8. First of three stacked Android PRs. Needs urnetwork/sdk#149 (merged).

Switches MainApplication from Sdk.setLogDir(filesDir) to Sdk.setLogDirForProcess(<filesDir>/logs, "app"), keeping the try/catch guard from #473.

The migration is the part that matters

Pre-upgrade builds wrote glog files straight into filesDir. Once the root moves, nothing ever prunes or exports that directory again — so the old files become both dead storage (up to ~64 MB: 4 files × the 16 MiB cap) and unreachable evidence. A user who upgrades and then exports to report an incident predating the upgrade would get none of the logs that recorded it.

The migration runs before glog is pointed at the new directory, so the SDK's retention pass treats the moved files as part of the app's own history and keeps the newest four of the merged set. Running it first also means glog isn't yet writing into filesDir in this process, so the renames can't race a live file handle.

Behaviour change worth knowing

FeedbackScreen's existing Share/Export log buttons read Sdk.getLogDir(), which now returns <filesDir>/logs/app rather than <filesDir>. That's the intended outcome, and the migration is precisely what keeps those buttons showing pre-upgrade logs.

res/xml/file_paths.xml already declares <files-path name="logs" path="."/> (the whole filesDir), so FileProvider still resolves the new subdirectory with no manifest change.

One-way door, stated plainly

The migration is a one-way rename with no rollback: a user who downgrades to a pre-upgrade build won't see the moved files, since the old build reads filesDir directly. That seems clearly right — the alternative strands them permanently — but it is a real one-way door and isn't covered by a test.

Verification

Not compiled locally — no JDK, Android SDK or NDK available. This PR's CI run is the first place the Kotlin compiler and the four new tests actually execute. Verified by inspection: every SDK symbol greped against the Go source at sdk@main (including confirming SetLogDirForProcess really can return an error, so the guard isn't dead code), brace/paren balance, overload resolution, and all four tests walked by hand against the implementation.

🤖 Generated with Claude Code

MainApplication pointed glog at filesDir itself. Move it to <filesDir>/logs/app via Sdk.setLogDirForProcess, inside the try/catch that urnetwork#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