Our Commitment
We take the security of OpenDroid and our users seriously. As an open-source project that interacts with sensitive device permissions (Accessibility Service, phone, SMS, system settings), we recognize the importance of promptly addressing security concerns.
Supported Versions
Only the latest release version of OpenDroid is actively supported with security updates.
| Version | Status |
|---|---|
| ≥ 1.0 (Latest Release) | ✓ Supported |
| < 1.0 (Pre-release) | ✗ Not Supported |
Reporting a Vulnerability
If you believe you have found a security vulnerability in OpenDroid, please report it responsibly:
Step 1: Contact Us Privately
Send a detailed report to opendroid.ai@gmail.com or yashabalam707@gmail.com with:
- A clear description of the vulnerability
- Steps to reproduce the issue
- Potential impact assessment
- Any proof-of-concept code (if applicable)
- Your contact information for follow-up
Step 2: Our Response
After receiving your report:
- Within 48 hours: We will acknowledge receipt of your report
- Within 7 days: We will provide an initial assessment and severity classification
- Within 30 days: We will work on a fix and coordinate a disclosure timeline with you
Step 3: Disclosure
Once the vulnerability is patched:
- We will release a security update with the fix
- We will publish a security advisory on the GitHub repository
- We will credit you for the discovery (if desired)
Security Best Practices for Users
To ensure the security of your OpenDroid installation:
- Keep updated: Always use the latest version of OpenDroid
- Secure your device: Use a strong screen lock and enable device encryption
- Protect API keys: Never share your LLM API keys publicly
- Review permissions: Periodically review the permissions granted to OpenDroid
- Use trusted sources: Only download OpenDroid from the official GitHub repository
- Local models: For maximum privacy, use Ollama with local models instead of cloud providers
Scope
The following areas are in scope for security reports:
- Accessibility Service misuse or data leakage
- Unauthorized access to device functions
- API key exposure or insecure storage
- Memory system data leaks
- Injection vulnerabilities in LLM prompts that could lead to malicious actions
- Insecure communication with third-party APIs
Out of Scope
- Vulnerabilities in third-party LLM provider APIs
Security Philosophy
OpenDroid operates with full Android system permissions (Accessibility, System Settings, Notifications). Consequently, security is engineered directly into our architecture through principle of least privilege, strict input sanitization, and local encrypted storage.
Key Security Features
Local Key Storage
All API keys provided by users (Gemini, OpenAI, Claude, Groq, ElevenLabs) are encrypted at rest with AES-256-GCM using a key generated and held inside the Android KeyStore, never in application memory or plaintext preferences. Older installs that stored credentials in DataStore are migrated to this store automatically; the legacy plaintext value is removed only once the migration succeeds, and is left in place for a later retry if it doesn't (it is not used at runtime once migration has started). Whether the KeyStore key is additionally isolated in dedicated secure hardware (StrongBox/TEE) depends on the device.
Intent & Action Verification
Every high-consequence system action (making calls, sending messages, changing system settings) undergoes strict schema verification before execution to prevent prompt injection or rogue LLM output execution.
Compound Intent Guard
Detects and validates chained actions (e.g. multi-step automation scripts) to prevent unauthorized side-effects.