feat: Android host adapter (android/truapi-host) + hosts/android submodule

[TarikGul]

Android TrUAPI host adapter

Brings Android to parity with the iOS host adapter (ios/truapi-host): the truapi repo owns a Kotlin host-adapter package, and vendors the Android app as a submodule so the core can be built and diagnosed against it.

What this adds

• android/truapi-host/ — the Kotlin host-adapter package over the truapi-server UniFFI core, the analogue of ios/truapi-host. TrUAPIHost.kt exposes the current FFI surface: HostBridge (device/remote permission split, a single confirmUserAction, chainConnect/Send/Close, lookupPreimage, theme, feature support), HostStorage + HostCoreStorage, TrUAPIHostCore (WS-bridge lifecycle, local-session activation, permission-authorization status, native change notifications), and LocalhostBridgeBootstrap. Products in a WebView reach the core over the localhost WebSocket bridge; the core signs on-device (signing-host role) with no separate phone.

• Build tooling (Makefile): uniffi-kotlin (generate Kotlin bindings), android-jni (cargo-ndk cross-compile of libtruapi_server.so per ABI), and android-publish-local. check-android-parity fails if the canonical TrUAPIHost.kt shell drifts from the copy vendored in the app (skips cleanly when the submodule is uninitialized). Generated bindings and jniLibs are gitignored.

• hosts/android submodule — vendors polkadot-app-android-v2 (branch tg/truapi-rust-core), mirroring hosts/ios. .gitmodules uses the HTTPS URL. Its app-side integration (a bindings/truapi-host rust-android module, a functional DefaultHostBridge + WebSocketChainProvider, and an instrumented diagnostics harness) lives in that repo's companion PR.

Verified on an Android emulator

The vendored app drives the host playground through the core end-to-end: the built-in Diagnosis sweep runs every TrUAPI method, with on-device signing/ permission approval prompts (no phone). All Signing methods pass and sign
locally; Account/Entropy/Local Storage/Notifications/Permissions pass. Remaining failures are funding/allowance-gated (Payment needs a balance; Preimage/Resource Allocation need on-chain allowances) or unimplemented on this host (Chat), consistent with the deployed-host diagnosis.

Notes

• The canonical package is shell-only, matching ios/truapi-host (no default-host/chain-provider helpers — those are app-side).
• TrUAPIHost.kt is duplicated between here and the vendored app copy; make check-android-parity guards against drift until it's single-sourced.
• JitPack distribution is documented as the target but is not yet wired (no root jitpack.yml); local integration uses make android-publish-local + mavenLocal(). Noted in android/truapi-host/README.md.

[pgherveou]

will test it out

One note before before I look into the code.
We have to be make sure the mobile integration is using the signing host logic and not the pairing host logic as mobile apps are accounts holder.

I am a bit surprised that this work without some of the changes to the signing host that I pushed to
#264 and backported in #288

[TarikGul]

@pgherveou Calrification: so signing did fail with the ring-vrf path which was expected but for sr25519 signing worked fine. I only used the signing host - no pairing at all.

This is the list of pass fail:

✅ Passed (37)

Account
- Account/connection_status_subscribe
- Account/get_account
- Account/get_account_alias
- Account/get_legacy_accounts
- Account/get_user_id
- Account/request_login

Chain (all)
- Chain/get_head_header, get_head_body, get_head_storage
- Chain/call_head
- Chain/unpin_head, continue_head, stop_head_operation
- Chain/get_spec_genesis_hash, get_spec_chain_name, get_spec_properties
- Chain/broadcast_transaction, stop_transaction

Signing (all — on-device sr25519)
- Signing/create_transaction
- Signing/create_transaction_with_legacy_account
- Signing/sign_raw, sign_payload
- Signing/sign_raw_with_legacy_account, sign_payload_with_legacy_account

Entropy — Entropy/derive
Local Storage — read, write, clear
Notifications — send_push_notification, cancel_push_notification
Permissions — request_device_permission, request_remote_permission
System — handshake, feature_supported, navigate_to
Theme — Theme/subscribe

❌ Failed (27)

Chat (all — not implemented in core)
- create_room, register_bot, list_subscribe, post_message, action_subscribe, custom_message_render_subscri

Coin Payment (all — need a funded balance)
- create_purse, query_purse, rebalance_purse, delete_purse, create_receivable, listen_for_payment

Payment (all — need a funded balance)
- balance_subscribe, top_up, request, status_subscribe

Statement Store (all — not implemented in core)
- subscribe, create_proof, submit, create_proof_authenticated

Preimage — lookup_subscribe, submit (allowance-gated)
Resource Allocation — request (allowance-gated / native-only)
Account — create_account_proof (ring-VRF; comes from  #288)

[TarikGul]

Holding this until #288 lands. Two things depend on it:

1. Signing host: mobile is an account holder, so it signs through the signing host. The respondToPairing surface isn't exposed over the native binding yet, and that's part of the signing-host work in feat(core): implement missing signing host fn #288.
2. create_account_proof: this is the ring-VRF path, which is the one method that fails right now on the emulator. feat(core): implement missing signing host fn #288 backports the signing-host ring-VRF changes that make it work.

Once #288 is in the mobile base I'll wire respondToPairing.