Build Fails and Runtime Instability on main Branch Due to Configuration Mismatches

[habipwalue]

Hello OpenArchive Team,
Thank you for your fantastic work on this project. I've been performing a deep analysis of the save-android and save-rust repositories to understand the P2P architecture. I'm creating this issue to document a chain of issues I encountered on the main branch that currently prevent a clean build and stable operation, which might be a hurdle for new contributors.

1. Build Failure in save-rust
   Following the README, the ./build-android.sh script fails during the compilation of save-rust.
   Error: unresolved import 'crate::server::server' in src/android_bridge.rs.
   Analysis: This seems to be a code inconsistency, where android_bridge.rs still uses old import paths (crate::server::server::...) after the server module was refactored to use a simpler path (crate::server::...).
   Workaround: Manually removing the extra ::server from the three import paths in android_bridge.rs allows the project to compile.
2. Runtime Instability & Performance Issues
   After patching the build, the save-android app runs, but it's very laggy and unstable. The root cause appears to be a disagreement between how the Rust backend starts and how the Android services expect to communicate with it.
   Logcat analysis reveals two conflicting operations happening simultaneously:
   Rust Server Starts on a Unix Socket: The backend correctly starts and logs Server started on Unix socket: .../rust_server.sock. The core functionalities of the app (listing groups, etc.) seem to rely on this socket.
   Android Service Polls a TCP Port: In parallel, SnowbirdService.kt starts a polling mechanism that continuously tries to check the server's health at a hardcoded TCP address: http://localhost:8080/status. This results in an endless loop of Server check failed: Failed to connect to localhost/127.0.0.1:8080 errors, causing significant performance issues.
   If I modify the Rust server in server.rs to listen on both the Unix socket and a TCP port (0.0.0.0:8080), the SnowbirdService becomes stable, and the core app functionalities also work. This suggests the intended setup is for the server to be reachable via both methods.
   Summary Question:
   Is this dual-communication model (Unix socket for the main app, TCP for the service) the intended architecture? It seems the current code on the main branch is missing the TCP .bind() call in server.rs and has an outdated import path in android_bridge.rs.
   A clarification on the intended configuration would be immensely helpful for understanding the project and for future contributions.
   Thank you for your guidance and for all your efforts on OpenArchive.