fix: gate pubky auth handler

[ben-kaufman]

Description

This PR prevents Bitkit from advertising itself as a pubkyauth handler unless the Paykit UI is enabled and the current Pubky identity has a matching local secret key.

Previously, the main activity registered the scheme unconditionally, so Android could route Pubky App authorization links to Bitkit even when the production UI was unavailable or the identity was managed by Pubky Ring. The handler now lives on a disabled-by-default activity alias. Bitkit enables it only while local authorization is possible and disables it again when the feature or identity state changes.

Preview

N/A — no UI changes.

QA Notes

Manual Tests

• 1. With Paykit UI disabled, request Pubky authorization: Bitkit is not offered or selected.
• 2. With Paykit UI enabled but no Pubky identity, request authorization: Bitkit is not offered or selected.
• 3. With a Ring-managed identity, request authorization: Bitkit is not offered or selected.
• 4. With a Bitkit-managed identity, request authorization: Bitkit opens the authorization screen.
• 5. Remove the local identity or disable Paykit UI, then retry: Bitkit no longer handles the link.

Automated Checks

• PubkyAuthHandlerRegistrarTest.kt: covers eligibility, state transitions, idempotent startup, and PackageManager failure recovery.
• PubkyAuthManifestTest.kt: ensures the main activity no longer claims pubkyauth and the alias is disabled by default.
• Local compile, complete dev unit suite, and detekt passed.

[greptile-apps]

Greptile Summary

The PR conditionally advertises Bitkit as a pubkyauth handler only when Paykit UI is enabled and the current Pubky identity has a matching local secret key.

• Moves the pubkyauth intent filter from MainActivity to a disabled-by-default activity alias.
• Adds an application-scoped registrar that observes feature and identity state and toggles the alias.
• Adds unit and manifest tests covering eligibility, transitions, idempotent startup, and package-manager failures.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or independently actionable non-blocking issues identified.

The manifest alias, runtime eligibility reconciliation, and deep-link handling remain consistent, and the investigated state-transition and lifecycle paths did not establish an observable changed-code failure.

Important Files Changed

Filename	Overview
app/src/main/AndroidManifest.xml	Moves pubkyauth routing to an exported activity alias that is disabled until runtime eligibility is established.
app/src/main/java/to/bitkit/App.kt	Injects and starts the handler registrar during application initialization.
app/src/main/java/to/bitkit/services/PubkyAuthHandlerRegistrar.kt	Observes feature and identity state and safely reconciles the activity-alias enabled state.
app/src/test/java/to/bitkit/build/PubkyAuthManifestTest.kt	Verifies that only the disabled alias declares the pubkyauth scheme.
app/src/test/java/to/bitkit/services/PubkyAuthHandlerRegistrarTest.kt	Covers eligibility decisions, state transitions, idempotent startup, and recovery after package-manager failures.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[App starts] --> B[Observe Paykit setting and Pubky public key]
B --> C{Paykit UI enabled?}
C -- No --> D[Disable pubkyauth activity alias]
C -- Yes --> E{Identity exists and local secret matches?}
E -- No --> D
E -- Yes --> F[Enable pubkyauth activity alias]
F --> G[Android can route pubkyauth links to MainActivity]

Loading

_{Reviews (1): Last reviewed commit: "chore: name changelog for pr" | Re-trigger Greptile}

[ovitrif]

Approved. This change prevents Bitkit from advertising the pubkyauth handler unless Paykit UI is enabled and the current identity has a matching local secret.

[ben-kaufman]

Description

This PR prevents Bitkit from advertising itself as a pubkyauth handler unless the Paykit UI is enabled and the current Pubky identity has a matching local secret key.

Previously, the main activity registered the scheme unconditionally, so Android could route Pubky App authorization links to Bitkit even when the production UI was unavailable or the identity was managed by Pubky Ring. The handler now lives on a disabled-by-default activity alias. Bitkit enables it only while local authorization is possible and disables it again when the feature or identity state changes.

Preview

N/A — no UI changes.

QA Notes

Manual Tests

• 1. With Paykit UI disabled, request Pubky authorization: Bitkit is not offered or selected.
• 2. With Paykit UI enabled but no Pubky identity, request authorization: Bitkit is not offered or selected.
• 3. With a Ring-managed identity, request authorization: Bitkit is not offered or selected.
• 4. With a Bitkit-managed identity, request authorization: Bitkit opens the authorization screen.
• 5. Remove the local identity or disable Paykit UI, then retry: Bitkit no longer handles the link.

Automated Checks

• PubkyAuthHandlerRegistrarTest.kt: covers eligibility, state transitions, idempotent startup, and PackageManager failure recovery.
• PubkyAuthManifestTest.kt: ensures the main activity no longer claims pubkyauth and the alias is disabled by default.
• Local compile, complete dev unit suite, and detekt passed.

[greptile-apps]

Greptile Summary

The PR conditionally advertises Bitkit as a pubkyauth handler only when Paykit UI is enabled and the current Pubky identity has a matching local secret key.

• Moves the pubkyauth intent filter from MainActivity to a disabled-by-default activity alias.
• Adds an application-scoped registrar that observes feature and identity state and toggles the alias.
• Adds unit and manifest tests covering eligibility, transitions, idempotent startup, and package-manager failures.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or independently actionable non-blocking issues identified.

The manifest alias, runtime eligibility reconciliation, and deep-link handling remain consistent, and the investigated state-transition and lifecycle paths did not establish an observable changed-code failure.

Important Files Changed

Filename	Overview
app/src/main/AndroidManifest.xml	Moves pubkyauth routing to an exported activity alias that is disabled until runtime eligibility is established.
app/src/main/java/to/bitkit/App.kt	Injects and starts the handler registrar during application initialization.
app/src/main/java/to/bitkit/services/PubkyAuthHandlerRegistrar.kt	Observes feature and identity state and safely reconciles the activity-alias enabled state.
app/src/test/java/to/bitkit/build/PubkyAuthManifestTest.kt	Verifies that only the disabled alias declares the pubkyauth scheme.
app/src/test/java/to/bitkit/services/PubkyAuthHandlerRegistrarTest.kt	Covers eligibility decisions, state transitions, idempotent startup, and recovery after package-manager failures.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[App starts] --> B[Observe Paykit setting and Pubky public key]
B --> C{Paykit UI enabled?}
C -- No --> D[Disable pubkyauth activity alias]
C -- Yes --> E{Identity exists and local secret matches?}
E -- No --> D
E -- Yes --> F[Enable pubkyauth activity alias]
F --> G[Android can route pubkyauth links to MainActivity]

Loading

_{Reviews (1): Last reviewed commit: "chore: name changelog for pr" | Re-trigger Greptile}

[ovitrif]

Approved. This change prevents Bitkit from advertising the pubkyauth handler unless Paykit UI is enabled and the current identity has a matching local secret.

[ben-kaufman]

Description

This PR prevents Bitkit from advertising itself as a pubkyauth handler unless the Paykit UI is enabled and the current Pubky identity has a matching local secret key.

Previously, the main activity registered the scheme unconditionally, so Android could route Pubky App authorization links to Bitkit even when the production UI was unavailable or the identity was managed by Pubky Ring. The handler now lives on a disabled-by-default activity alias. Bitkit enables it only while local authorization is possible and disables it again when the feature or identity state changes.

Preview

N/A — no UI changes.

QA Notes

Manual Tests

• 1. With Paykit UI disabled, request Pubky authorization: Bitkit is not offered or selected.
• 2. With Paykit UI enabled but no Pubky identity, request authorization: Bitkit is not offered or selected.
• 3. With a Ring-managed identity, request authorization: Bitkit is not offered or selected.
• 4. With a Bitkit-managed identity, request authorization: Bitkit opens the authorization screen.
• 5. Remove the local identity or disable Paykit UI, then retry: Bitkit no longer handles the link.

Automated Checks

• PubkyAuthHandlerRegistrarTest.kt: covers eligibility, state transitions, idempotent startup, and PackageManager failure recovery.
• PubkyAuthManifestTest.kt: ensures the main activity no longer claims pubkyauth and the alias is disabled by default.
• Local compile, complete dev unit suite, and detekt passed.

[greptile-apps]

Greptile Summary

The PR conditionally advertises Bitkit as a pubkyauth handler only when Paykit UI is enabled and the current Pubky identity has a matching local secret key.

• Moves the pubkyauth intent filter from MainActivity to a disabled-by-default activity alias.
• Adds an application-scoped registrar that observes feature and identity state and toggles the alias.
• Adds unit and manifest tests covering eligibility, transitions, idempotent startup, and package-manager failures.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or independently actionable non-blocking issues identified.

The manifest alias, runtime eligibility reconciliation, and deep-link handling remain consistent, and the investigated state-transition and lifecycle paths did not establish an observable changed-code failure.

Important Files Changed

Filename	Overview
app/src/main/AndroidManifest.xml	Moves pubkyauth routing to an exported activity alias that is disabled until runtime eligibility is established.
app/src/main/java/to/bitkit/App.kt	Injects and starts the handler registrar during application initialization.
app/src/main/java/to/bitkit/services/PubkyAuthHandlerRegistrar.kt	Observes feature and identity state and safely reconciles the activity-alias enabled state.
app/src/test/java/to/bitkit/build/PubkyAuthManifestTest.kt	Verifies that only the disabled alias declares the pubkyauth scheme.
app/src/test/java/to/bitkit/services/PubkyAuthHandlerRegistrarTest.kt	Covers eligibility decisions, state transitions, idempotent startup, and recovery after package-manager failures.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[App starts] --> B[Observe Paykit setting and Pubky public key]
B --> C{Paykit UI enabled?}
C -- No --> D[Disable pubkyauth activity alias]
C -- Yes --> E{Identity exists and local secret matches?}
E -- No --> D
E -- Yes --> F[Enable pubkyauth activity alias]
F --> G[Android can route pubkyauth links to MainActivity]

Loading

_{Reviews (1): Last reviewed commit: "chore: name changelog for pr" | Re-trigger Greptile}

[ovitrif]

Approved. This change prevents Bitkit from advertising the pubkyauth handler unless Paykit UI is enabled and the current identity has a matching local secret.

[ben-kaufman]

Description

This PR prevents Bitkit from advertising itself as a pubkyauth handler unless the Paykit UI is enabled and the current Pubky identity has a matching local secret key.

Previously, the main activity registered the scheme unconditionally, so Android could route Pubky App authorization links to Bitkit even when the production UI was unavailable or the identity was managed by Pubky Ring. The handler now lives on a disabled-by-default activity alias. Bitkit enables it only while local authorization is possible and disables it again when the feature or identity state changes.

Preview

N/A — no UI changes.

QA Notes

Manual Tests

• 1. With Paykit UI disabled, request Pubky authorization: Bitkit is not offered or selected.
• 2. With Paykit UI enabled but no Pubky identity, request authorization: Bitkit is not offered or selected.
• 3. With a Ring-managed identity, request authorization: Bitkit is not offered or selected.
• 4. With a Bitkit-managed identity, request authorization: Bitkit opens the authorization screen.
• 5. Remove the local identity or disable Paykit UI, then retry: Bitkit no longer handles the link.

Automated Checks

• PubkyAuthHandlerRegistrarTest.kt: covers eligibility, state transitions, idempotent startup, and PackageManager failure recovery.
• PubkyAuthManifestTest.kt: ensures the main activity no longer claims pubkyauth and the alias is disabled by default.
• Local compile, complete dev unit suite, and detekt passed.

[greptile-apps]

Greptile Summary

The PR conditionally advertises Bitkit as a pubkyauth handler only when Paykit UI is enabled and the current Pubky identity has a matching local secret key.

• Moves the pubkyauth intent filter from MainActivity to a disabled-by-default activity alias.
• Adds an application-scoped registrar that observes feature and identity state and toggles the alias.
• Adds unit and manifest tests covering eligibility, transitions, idempotent startup, and package-manager failures.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or independently actionable non-blocking issues identified.

The manifest alias, runtime eligibility reconciliation, and deep-link handling remain consistent, and the investigated state-transition and lifecycle paths did not establish an observable changed-code failure.

Important Files Changed

Filename	Overview
app/src/main/AndroidManifest.xml	Moves pubkyauth routing to an exported activity alias that is disabled until runtime eligibility is established.
app/src/main/java/to/bitkit/App.kt	Injects and starts the handler registrar during application initialization.
app/src/main/java/to/bitkit/services/PubkyAuthHandlerRegistrar.kt	Observes feature and identity state and safely reconciles the activity-alias enabled state.
app/src/test/java/to/bitkit/build/PubkyAuthManifestTest.kt	Verifies that only the disabled alias declares the pubkyauth scheme.
app/src/test/java/to/bitkit/services/PubkyAuthHandlerRegistrarTest.kt	Covers eligibility decisions, state transitions, idempotent startup, and recovery after package-manager failures.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[App starts] --> B[Observe Paykit setting and Pubky public key]
B --> C{Paykit UI enabled?}
C -- No --> D[Disable pubkyauth activity alias]
C -- Yes --> E{Identity exists and local secret matches?}
E -- No --> D
E -- Yes --> F[Enable pubkyauth activity alias]
F --> G[Android can route pubkyauth links to MainActivity]

Loading

_{Reviews (1): Last reviewed commit: "chore: name changelog for pr" | Re-trigger Greptile}

[ovitrif]

Approved. This change prevents Bitkit from advertising the pubkyauth handler unless Paykit UI is enabled and the current identity has a matching local secret.

[ben-kaufman]

Description

This PR prevents Bitkit from advertising itself as a pubkyauth handler unless the Paykit UI is enabled and the current Pubky identity has a matching local secret key.

Previously, the main activity registered the scheme unconditionally, so Android could route Pubky App authorization links to Bitkit even when the production UI was unavailable or the identity was managed by Pubky Ring. The handler now lives on a disabled-by-default activity alias. Bitkit enables it only while local authorization is possible and disables it again when the feature or identity state changes.

Preview

N/A — no UI changes.

QA Notes

Manual Tests

• 1. With Paykit UI disabled, request Pubky authorization: Bitkit is not offered or selected.
• 2. With Paykit UI enabled but no Pubky identity, request authorization: Bitkit is not offered or selected.
• 3. With a Ring-managed identity, request authorization: Bitkit is not offered or selected.
• 4. With a Bitkit-managed identity, request authorization: Bitkit opens the authorization screen.
• 5. Remove the local identity or disable Paykit UI, then retry: Bitkit no longer handles the link.

Automated Checks

• PubkyAuthHandlerRegistrarTest.kt: covers eligibility, state transitions, idempotent startup, and PackageManager failure recovery.
• PubkyAuthManifestTest.kt: ensures the main activity no longer claims pubkyauth and the alias is disabled by default.
• Local compile, complete dev unit suite, and detekt passed.

[greptile-apps]

Greptile Summary

The PR conditionally advertises Bitkit as a pubkyauth handler only when Paykit UI is enabled and the current Pubky identity has a matching local secret key.

• Moves the pubkyauth intent filter from MainActivity to a disabled-by-default activity alias.
• Adds an application-scoped registrar that observes feature and identity state and toggles the alias.
• Adds unit and manifest tests covering eligibility, transitions, idempotent startup, and package-manager failures.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or independently actionable non-blocking issues identified.

The manifest alias, runtime eligibility reconciliation, and deep-link handling remain consistent, and the investigated state-transition and lifecycle paths did not establish an observable changed-code failure.

Important Files Changed

Filename	Overview
app/src/main/AndroidManifest.xml	Moves pubkyauth routing to an exported activity alias that is disabled until runtime eligibility is established.
app/src/main/java/to/bitkit/App.kt	Injects and starts the handler registrar during application initialization.
app/src/main/java/to/bitkit/services/PubkyAuthHandlerRegistrar.kt	Observes feature and identity state and safely reconciles the activity-alias enabled state.
app/src/test/java/to/bitkit/build/PubkyAuthManifestTest.kt	Verifies that only the disabled alias declares the pubkyauth scheme.
app/src/test/java/to/bitkit/services/PubkyAuthHandlerRegistrarTest.kt	Covers eligibility decisions, state transitions, idempotent startup, and recovery after package-manager failures.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[App starts] --> B[Observe Paykit setting and Pubky public key]
B --> C{Paykit UI enabled?}
C -- No --> D[Disable pubkyauth activity alias]
C -- Yes --> E{Identity exists and local secret matches?}
E -- No --> D
E -- Yes --> F[Enable pubkyauth activity alias]
F --> G[Android can route pubkyauth links to MainActivity]

Loading

_{Reviews (1): Last reviewed commit: "chore: name changelog for pr" | Re-trigger Greptile}

[ovitrif]

Approved. This change prevents Bitkit from advertising the pubkyauth handler unless Paykit UI is enabled and the current identity has a matching local secret.

[ben-kaufman]

Description

This PR prevents Bitkit from advertising itself as a pubkyauth handler unless the Paykit UI is enabled and the current Pubky identity has a matching local secret key.

Previously, the main activity registered the scheme unconditionally, so Android could route Pubky App authorization links to Bitkit even when the production UI was unavailable or the identity was managed by Pubky Ring. The handler now lives on a disabled-by-default activity alias. Bitkit enables it only while local authorization is possible and disables it again when the feature or identity state changes.

Preview

N/A — no UI changes.

QA Notes

Manual Tests

• 1. With Paykit UI disabled, request Pubky authorization: Bitkit is not offered or selected.
• 2. With Paykit UI enabled but no Pubky identity, request authorization: Bitkit is not offered or selected.
• 3. With a Ring-managed identity, request authorization: Bitkit is not offered or selected.
• 4. With a Bitkit-managed identity, request authorization: Bitkit opens the authorization screen.
• 5. Remove the local identity or disable Paykit UI, then retry: Bitkit no longer handles the link.

Automated Checks

• PubkyAuthHandlerRegistrarTest.kt: covers eligibility, state transitions, idempotent startup, and PackageManager failure recovery.
• PubkyAuthManifestTest.kt: ensures the main activity no longer claims pubkyauth and the alias is disabled by default.
• Local compile, complete dev unit suite, and detekt passed.

[greptile-apps]

Greptile Summary

The PR conditionally advertises Bitkit as a pubkyauth handler only when Paykit UI is enabled and the current Pubky identity has a matching local secret key.

• Moves the pubkyauth intent filter from MainActivity to a disabled-by-default activity alias.
• Adds an application-scoped registrar that observes feature and identity state and toggles the alias.
• Adds unit and manifest tests covering eligibility, transitions, idempotent startup, and package-manager failures.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or independently actionable non-blocking issues identified.

The manifest alias, runtime eligibility reconciliation, and deep-link handling remain consistent, and the investigated state-transition and lifecycle paths did not establish an observable changed-code failure.

Important Files Changed

Filename	Overview
app/src/main/AndroidManifest.xml	Moves pubkyauth routing to an exported activity alias that is disabled until runtime eligibility is established.
app/src/main/java/to/bitkit/App.kt	Injects and starts the handler registrar during application initialization.
app/src/main/java/to/bitkit/services/PubkyAuthHandlerRegistrar.kt	Observes feature and identity state and safely reconciles the activity-alias enabled state.
app/src/test/java/to/bitkit/build/PubkyAuthManifestTest.kt	Verifies that only the disabled alias declares the pubkyauth scheme.
app/src/test/java/to/bitkit/services/PubkyAuthHandlerRegistrarTest.kt	Covers eligibility decisions, state transitions, idempotent startup, and recovery after package-manager failures.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[App starts] --> B[Observe Paykit setting and Pubky public key]
B --> C{Paykit UI enabled?}
C -- No --> D[Disable pubkyauth activity alias]
C -- Yes --> E{Identity exists and local secret matches?}
E -- No --> D
E -- Yes --> F[Enable pubkyauth activity alias]
F --> G[Android can route pubkyauth links to MainActivity]

Loading

_{Reviews (1): Last reviewed commit: "chore: name changelog for pr" | Re-trigger Greptile}

[ovitrif]

Approved. This change prevents Bitkit from advertising the pubkyauth handler unless Paykit UI is enabled and the current identity has a matching local secret.

[ben-kaufman]

Description

This PR prevents Bitkit from advertising itself as a pubkyauth handler unless the Paykit UI is enabled and the current Pubky identity has a matching local secret key.

Previously, the main activity registered the scheme unconditionally, so Android could route Pubky App authorization links to Bitkit even when the production UI was unavailable or the identity was managed by Pubky Ring. The handler now lives on a disabled-by-default activity alias. Bitkit enables it only while local authorization is possible and disables it again when the feature or identity state changes.

Preview

N/A — no UI changes.

QA Notes

Manual Tests

• 1. With Paykit UI disabled, request Pubky authorization: Bitkit is not offered or selected.
• 2. With Paykit UI enabled but no Pubky identity, request authorization: Bitkit is not offered or selected.
• 3. With a Ring-managed identity, request authorization: Bitkit is not offered or selected.
• 4. With a Bitkit-managed identity, request authorization: Bitkit opens the authorization screen.
• 5. Remove the local identity or disable Paykit UI, then retry: Bitkit no longer handles the link.

Automated Checks

• PubkyAuthHandlerRegistrarTest.kt: covers eligibility, state transitions, idempotent startup, and PackageManager failure recovery.
• PubkyAuthManifestTest.kt: ensures the main activity no longer claims pubkyauth and the alias is disabled by default.
• Local compile, complete dev unit suite, and detekt passed.

[greptile-apps]

Greptile Summary

The PR conditionally advertises Bitkit as a pubkyauth handler only when Paykit UI is enabled and the current Pubky identity has a matching local secret key.

• Moves the pubkyauth intent filter from MainActivity to a disabled-by-default activity alias.
• Adds an application-scoped registrar that observes feature and identity state and toggles the alias.
• Adds unit and manifest tests covering eligibility, transitions, idempotent startup, and package-manager failures.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or independently actionable non-blocking issues identified.

The manifest alias, runtime eligibility reconciliation, and deep-link handling remain consistent, and the investigated state-transition and lifecycle paths did not establish an observable changed-code failure.

Important Files Changed

Filename	Overview
app/src/main/AndroidManifest.xml	Moves pubkyauth routing to an exported activity alias that is disabled until runtime eligibility is established.
app/src/main/java/to/bitkit/App.kt	Injects and starts the handler registrar during application initialization.
app/src/main/java/to/bitkit/services/PubkyAuthHandlerRegistrar.kt	Observes feature and identity state and safely reconciles the activity-alias enabled state.
app/src/test/java/to/bitkit/build/PubkyAuthManifestTest.kt	Verifies that only the disabled alias declares the pubkyauth scheme.
app/src/test/java/to/bitkit/services/PubkyAuthHandlerRegistrarTest.kt	Covers eligibility decisions, state transitions, idempotent startup, and recovery after package-manager failures.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[App starts] --> B[Observe Paykit setting and Pubky public key]
B --> C{Paykit UI enabled?}
C -- No --> D[Disable pubkyauth activity alias]
C -- Yes --> E{Identity exists and local secret matches?}
E -- No --> D
E -- Yes --> F[Enable pubkyauth activity alias]
F --> G[Android can route pubkyauth links to MainActivity]

Loading

_{Reviews (1): Last reviewed commit: "chore: name changelog for pr" | Re-trigger Greptile}

[ovitrif]

Approved. This change prevents Bitkit from advertising the pubkyauth handler unless Paykit UI is enabled and the current identity has a matching local secret.

[ben-kaufman]

Description

This PR prevents Bitkit from advertising itself as a pubkyauth handler unless the Paykit UI is enabled and the current Pubky identity has a matching local secret key.

Previously, the main activity registered the scheme unconditionally, so Android could route Pubky App authorization links to Bitkit even when the production UI was unavailable or the identity was managed by Pubky Ring. The handler now lives on a disabled-by-default activity alias. Bitkit enables it only while local authorization is possible and disables it again when the feature or identity state changes.

Preview

N/A — no UI changes.

QA Notes

Manual Tests

• 1. With Paykit UI disabled, request Pubky authorization: Bitkit is not offered or selected.
• 2. With Paykit UI enabled but no Pubky identity, request authorization: Bitkit is not offered or selected.
• 3. With a Ring-managed identity, request authorization: Bitkit is not offered or selected.
• 4. With a Bitkit-managed identity, request authorization: Bitkit opens the authorization screen.
• 5. Remove the local identity or disable Paykit UI, then retry: Bitkit no longer handles the link.

Automated Checks

• PubkyAuthHandlerRegistrarTest.kt: covers eligibility, state transitions, idempotent startup, and PackageManager failure recovery.
• PubkyAuthManifestTest.kt: ensures the main activity no longer claims pubkyauth and the alias is disabled by default.
• Local compile, complete dev unit suite, and detekt passed.

[greptile-apps]

Greptile Summary

The PR conditionally advertises Bitkit as a pubkyauth handler only when Paykit UI is enabled and the current Pubky identity has a matching local secret key.

• Moves the pubkyauth intent filter from MainActivity to a disabled-by-default activity alias.
• Adds an application-scoped registrar that observes feature and identity state and toggles the alias.
• Adds unit and manifest tests covering eligibility, transitions, idempotent startup, and package-manager failures.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete blocking or independently actionable non-blocking issues identified.

The manifest alias, runtime eligibility reconciliation, and deep-link handling remain consistent, and the investigated state-transition and lifecycle paths did not establish an observable changed-code failure.

Important Files Changed

Filename	Overview
app/src/main/AndroidManifest.xml	Moves pubkyauth routing to an exported activity alias that is disabled until runtime eligibility is established.
app/src/main/java/to/bitkit/App.kt	Injects and starts the handler registrar during application initialization.
app/src/main/java/to/bitkit/services/PubkyAuthHandlerRegistrar.kt	Observes feature and identity state and safely reconciles the activity-alias enabled state.
app/src/test/java/to/bitkit/build/PubkyAuthManifestTest.kt	Verifies that only the disabled alias declares the pubkyauth scheme.
app/src/test/java/to/bitkit/services/PubkyAuthHandlerRegistrarTest.kt	Covers eligibility decisions, state transitions, idempotent startup, and recovery after package-manager failures.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[App starts] --> B[Observe Paykit setting and Pubky public key]
B --> C{Paykit UI enabled?}
C -- No --> D[Disable pubkyauth activity alias]
C -- Yes --> E{Identity exists and local secret matches?}
E -- No --> D
E -- Yes --> F[Enable pubkyauth activity alias]
F --> G[Android can route pubkyauth links to MainActivity]

Loading

_{Reviews (1): Last reviewed commit: "chore: name changelog for pr" | Re-trigger Greptile}

[ovitrif]

Approved. This change prevents Bitkit from advertising the pubkyauth handler unless Paykit UI is enabled and the current identity has a matching local secret.