feat: add product flavors and TorProvider abstraction

[moehamade]

Introduces build flavors to separate Tor functionality from the standard build, reducing APK size for users who don't need Tor.

• Creates standard and tor product flavors.
• The standard flavor is the default, lightweight build.
• The tor flavor includes the Arti (Tor) dependency and is identified by the .tor application ID suffix.
• Adds a TorProvider interface and a TorProviderFactory to abstract Tor implementation details between flavors.

Prepares architecture for optional Tor support to reduce APK size from 142MB to ~4-5MB for standard builds

Closes #454

Description

Checklist

• I have read the contribution guidelines: https://github.com/permissionlesstech/bitchat-android?tab=readme-ov-file#contributing
• I have performed a self-review of my code

• I have mentioned the corresponding issue and the relevant keyword (e.g., "Closes: #xy") in the description (see https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
• If it is a core feature, I have added automated tests

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[moehamade]

Summary

This PR introduces product flavors to support optional Tor integration and optimizes the CI pipeline for efficiency. It addresses APK size concerns (#454 ) while maintaining feature parity across builds.

Key Achievements

1. Product Flavor Architecture

• Standard flavor: Lightweight build without Tor dependencies
• Tor flavor: Full privacy build with Guardian Project Arti integration
• Abstraction layer: TorProvider interface with flavor-specific implementations
  • StandardTorProvider: No-op implementation, always reports NOT_AVAILABLE
  • RealTorProvider: Full Arti integration with bootstrap monitoring
• Design: Prepared for Phase 2 Dynamic Feature Module support (no refactoring needed)

2. UI Improvements

• Tor toggle behavior:
  • Disabled in standard flavor with visual feedback
  • Info icon (ⓘ) with tooltip explaining unavailability
  • Prevents user confusion about missing Tor functionality
• Graceful degradation: App works identically in both flavors, Tor features simply unavailable in standard

3. Build System Enhancements

• Flavor-specific dependencies: Arti library only included in tor flavor (torImplementation)
• Separate ProGuard rules: proguard-standard.pro and proguard-tor.pro
• Source set structure:
  app/src/
  ├── main/ (186 files - shared code)
  ├── standard/ (2 files - StandardTorProvider + factory)
  └── tor/ (2 files - RealTorProvider + factory)

4. CI/CD Optimization

• Merged test + lint jobs: Eliminated redundant setup overhead
• Conditional tor lint: Only runs when app/src/tor/ files change in PRs (~95% time savings)
• Parallelized builds: 4 concurrent builds via matrix strategy
• Time improvement: 18-26 min → ~8-11 min (50-60% faster)

APK Size Results (from CI artifacts)

Flavor	Build Type	APK Size	Use Case
standard	debug	21.9 MB	Development without Tor
standard	release	3.53 MB	Play Store / lightweight distribution ✅
tor	debug	78.4 MB	Development with Tor
tor	release	60 MB	Privacy-focused distribution

Size reduction: Standard release is 94% smaller than tor release (3.53 MB vs 60 MB)

Relation to #507

This PR serves as a temporary workaround for #507 by providing two distribution options:

1. Standard flavor (3.53 MB): Play Store friendly, covers mainstream use cases
2. Tor flavor (60 MB): Direct distribution for privacy-conscious users

The TorProvider abstraction is designed to support Phase 2: Dynamic Feature Modules, which will allow:

• Users download standard build from Play Store (~4 MB)
• Tor can be downloaded on-demand as a feature module (~56 MB additional)
• No code refactoring needed - just swap StandardTorProvider → DynamicTorProvider

Files Changed

Core Architecture:

• app/src/main/net/TorProvider.kt - Abstraction interface
• app/src/main/net/TorProviderFactory.kt - Singleton factory
• app/src/standard/net/StandardTorProvider.kt - No-op implementation
• app/src/tor/net/RealTorProvider.kt - Full Arti integration

UI Updates:

• app/src/main/ui/AboutSheet.kt - Tor toggle disabled with info icon

Build Configuration:

• app/build.gradle.kts - Product flavors, flavor-specific dependencies
• app/proguard-standard.pro - Standard flavor ProGuard rules
• app/proguard-tor.pro - Tor/Arti ProGuard rules

CI/CD:

• .github/workflows/android-build.yml - Optimized parallel workflow

Testing

✅ CI passes with optimized workflow✅ APK sizes verified from CI artifacts✅ Both flavors build successfully✅ Standard flavor correctly disables Tor UI elements✅ Tor flavor maintains full functionality

Screenshot:

Standard	Tor Build

[moehamade]

Hey @callebtc , as mentioned above, this is directly related to #507 Would really appreciate if you can take a look at it. Thank you!

[callebtc]

Hey @callebtc , as mentioned above, this is directly related to #507 Would really appreciate if you can take a look at it. Thank you!

sorry I couldn't check this out earlier but damn!

[callebtc]

@moehamade could you help me understand how this solves #507 ? we do not want to release a version without tor on play store, and maybe even not on github. tor should be a must when dealing with nostr relays, especially when location channels are used.

[moehamade]

I already finished the feature but I didn't update the PR. I thought we're not doing that anymore... I managed to compile rust library and place it under Android project. I now have working Android app with Fresh Arti library directly compiled from source. What I did in this PR was simply provide the necessary abstractions so I can create a Java Native Interface (JNI) so I can easily bridge it with the custom library since It's written in Rust. And the product flavors was just a quick way for us to release without Tor. But as it is no it doesn't solve our issue.

But this requires a discussion and there is no direct way to contact you, I included 2 compiled .so files for each architecture (Arm and x86_64 ). So in order to reduce size by half, should I only include the Arm library? or will people require support for emulators as well? We could provide both libraries for debug builds and only Arm for release since people wouldn't be able to chat on emulators anyway.

The other stuff we should discuss is what features do we really need from the Arti library? Do we need support to access .onion sites? because such stuff will still increase the size of the compiled library, and I should know what features we want and what features I can safely remove to reduce app size.

Let me know.

[callebtc]

@moehamade appreciate it! let's talk directly on signal if you don't mind. could you send me your signal username here or to bitchat-dev at pm .me?

[callebtc]

So in order to reduce size by half, should I only include the Arm library?

I think we should be good with releasing only the arm library, yes

We could provide both libraries for debug builds and only Arm for release since people wouldn't be able to chat on emulators anyway.

this sounds like a great plan

The other stuff we should discuss is what features do we really need from the Arti library? Do we need support to access .onion sites? because such stuff will still increase the size of the compiled library, and I should know what features we want and what features I can safely remove to reduce app size.

this is very considerate of you, thank you. we should compare what the actual file size differences are for these options. I've been thinking about file-transfers using onion services before, it could be a really cool way for direct phone to phone connections in the future.