Privacy Policy

Last updated: 2026-05-26

SmsForwarder ("the App") is an Android app that runs locally on the user's device to forward text messages, picture messages, call events, and (when the user enables it) notifications from other apps. This Privacy Policy explains what information the App accesses, processes, stores, and sends when the user configures forwarding destinations.

1. Core Principles

  • The App does not upload SMS, MMS, call, contact, notification, forwarding-rule, or channel-configuration data to the developer for collection, analytics, advertising, or sale.
  • The App does not include advertising SDKs, third-party analytics SDKs, or user tracking SDKs.
  • Forwarding destinations are configured by the user, such as a Telegram bot, an email account, an HTTP webhook, a Slack incoming webhook, a Bark server, a WhatsApp number, a Google Drive folder, or another phone number. Information is sent to those destinations only when the user configures and enables the relevant channel.
  • When a user on the Advanced subscription enables AI processing through the built-in cloud option, the message text and the requested operation are sent to a developer-operated AI proxy. The proxy relays the request to a third-party LLM provider, returns the structured result, and does not log, persist, or cache the message body. See the AI Processing (Advanced Subscription) section for the proxy endpoint and the full data flow.
  • When the user uses the Email channel's built-in sending option, the email is delivered through a developer-operated relay instead of the user's own outgoing mail server. The relay sends the message on the user's behalf and does not log, persist, or cache the email content. See the Built-in Email Sending section for the endpoint and the full data flow.
  • When the user turns on the optional Web Access feature, a browser on another device can read recent SMS and send SMS through the user's phone. In "local network" mode the browser connects to the phone directly over the local Wi-Fi network. In "access from anywhere" mode the browser connects through a developer-operated relay that forwards the session to the phone in real time; the relay does not log, persist, or cache message content. See the Web Access section for the full data flow.
  • If the user voluntarily sends logs, screenshots, backup files, or support details to the developer, the developer will receive the information the user chose to provide and will use it only for support.

1.1 Prominent In-App Disclosure

When the App is launched for the first time on a device, an in-app disclosure dialog is shown before any sensitive permission is requested and before any forwarding takes place. The dialog explains, in summary form, that:

  • The App reads incoming SMS / MMS content, sender numbers, call events, and (if the user enables notification capture, or enables a text-message rule with the RCS source type turned on) selected notifications from other apps when the user enables forwarding and grants the related Android permissions.
  • The data is sent only to the destinations the user configures (Telegram, email — through the user's own mail server or a developer-operated relay — HTTP webhook, Slack, Bark, WhatsApp, Google Drive, or another phone number) and, when the user enables the optional AI features that come with the Advanced subscription, to one cloud AI path of the user's choice — either the built-in cloud AI proxy operated by the developer, or a cloud AI provider that the user configures with their own API key.
  • The developer does not collect, upload, share, or sell SMS, MMS, call, or notification data, and does not use it for advertising or analytics.
  • The user can revoke any permission in Android system settings at any time and disable forwarding from inside the App.

The user must explicitly accept the disclosure before the App enables forwarding features. Consent is recorded per device and is not included in exported backup files, so every fresh install or device migration requires the disclosure to be accepted again. AI features additionally require a separate one-time AI consent dialog (see the AI Processing (Advanced Subscription) section).

2. Information the App Processes

SMS and MMS Information (RECEIVE_SMS / RECEIVE_MMS / RECEIVE_WAP_PUSH / SEND_SMS / READ_SMS)

When SMS or MMS forwarding is enabled and the required permissions are granted, the App reads incoming messages locally on the device so it can apply the user's forwarding rules. This may include:

  • The sender phone number.
  • The message body or, for MMS, the readable text portion of the message.
  • The received time.
  • The SIM card, SIM slot, or subscription ID that received the message, when available from Android and permitted by the user.

Message content is processed locally and is sent only to forwarding channels configured and enabled by the user. Message content is not sent to the developer.

If the user configures an SMS delivery channel, the App uses SEND_SMS to send the forwarded content to the phone number entered by the user. The user may choose the system default SIM, a specific SIM, the SIM that received the original message, or restrict sending to when the device is offline.

READ_SMS is optional and is only relevant to the Web Access (PC Sync) feature described below. When the user grants READ_SMS, the Web Access browser session can read the full SMS inbox from the device's system SMS provider so the user can scroll through earlier conversations on a PC. When the user does not grant READ_SMS, the Web Access browser session only sees messages that the App has already recorded through its forwarding pipeline; the system SMS provider is not read. READ_SMS is only read on the device, and only when the browser session asks for inbox data while the permission is granted — there is no background uploader. When Web Access is in local network mode, the inbox content read under READ_SMS is returned directly to the browser on the local Wi-Fi network and never leaves the LAN. When Web Access is in access from anywhere mode, the App's response to the browser — including any inbox content read under READ_SMS — transits the developer-operated relay in real time on its way back to the browser; the relay does not log, persist, or cache that content (see the Web Access (PC Sync) section). The user can revoke READ_SMS at any time in Android system settings; the Web Access feature continues to work in its degraded, forwarded-history-only mode.

Call Events and Call Records (READ_PHONE_STATE / READ_PHONE_NUMBERS / READ_CALL_LOG / READ_CONTACTS)

When call forwarding is enabled and the required permissions are granted, the App listens for or reads the call information needed to forward call event notifications. This may include:

  • Call event type, such as incoming ringing, incoming answered, missed call, incoming ended, outgoing dialed, or outgoing ended.
  • Incoming or outgoing phone number.
  • Call event time.
  • Call duration, when available from the Android call log.
  • Cached contact name from the system call log or contact-related display information, when available and permitted.
  • The SIM card, SIM slot, or subscription ID involved in the call, when available from Android and permitted by the user.

The App does not upload the user's contacts and does not send call records to the developer. Call event details are sent only to the user's configured forwarding destinations when call forwarding is enabled.

Notifications from Other Apps (Notification Listener Access)

The App can optionally forward notifications posted by other apps. This feature is off by default and requires the user to grant Android's notification access (BIND_NOTIFICATION_LISTENER_SERVICE) and to add a rule that targets app notifications. When enabled, the App may read the source app's identifier (package name), title, and text of incoming notifications it is allowed to see, build a forwardable summary locally, and send it only to the user's configured destinations. The App does not send notification data to the developer. The user can revoke notification access at any time in Android system settings, which disables the feature.

SIM and Phone State Information (READ_PHONE_STATE / READ_PHONE_NUMBERS)

The App may read active SIM information to:

  • Show available SIM cards in the SMS channel editor.
  • Match SMS or call forwarding rules by SIM slot.
  • Include receiving SIM details in forwarded messages, such as SIM slot, carrier name, display name, or phone number when Android provides them.

This information is read and processed locally. It is not sent to the developer. If the user saves a channel or rule, the App may store the selected subscription ID or SIM-slot matching configuration locally.

Forwarding Channels, Rules, and App Settings

The App stores user-created forwarding configuration locally on the device, including:

  • Telegram channel name, Bot Token, and Chat ID.
  • Email channel name, recipient email address, an optional sender display name, and the sending mode. In built-in sending mode (the default for newly created email channels) no outgoing-mail credentials are stored. In custom-SMTP mode the channel also stores the sender email, the email password or app-specific authorization code, the SMTP host, port, and SSL/STARTTLS settings.
  • Webhook channel name, request URL, request method (such as POST or GET), any custom headers, and the message body template.
  • Slack channel name and incoming webhook URL.
  • Bark channel name, server URL, device key, and notification options.
  • WhatsApp channel name, sending mode (Meta Cloud API or CallMeBot), recipient phone number, and the credentials for the chosen mode (Meta access token, phone-number ID, and API version, or CallMeBot API key).
  • Google Drive channel name, target Drive folder name, target file name, new-entry insertion position (top or bottom of the file), the encrypted Google OAuth refresh token used for that channel, and the Google account email shown for identification.
  • SMS channel name, recipient phone number, SIM selection behavior, and "only send when offline" setting.
  • Optional HTTP/SOCKS5 proxy settings (host, port, username, password) for any networked channel — Telegram, Email, Webhook, Slack, Bark, WhatsApp, and Google Drive — stored per channel.
  • Forwarding rule name, enabled state, rule type, the list of one or more bound channels the rule fans out to, per-rule source-type toggles (SMS / RCS / MMS, for text-message rules), selected call event types, selected notification source apps, SIM-slot filter, and per-rule content filters (sender / phone number / contact name lists, title and body keyword lists, and — for users on the Advanced subscription — per-rule AI capability switches (one-time-code extraction, tags and spam score, translation with target language, summary with minimum length), AI-tag selections, and spam-score threshold).
  • The user-editable AI tag vocabulary, including each tag's identifier, display label, "when to apply" hint, and example messages. The two system tags otp and other are always present and cannot be edited.
  • Remote control allow list (phone numbers authorized to send command SMS to the device), the related on/off switch, the natural-language remote command toggle, and the result-delivery preferences (SMS reply to sender, push to selected delivery channels).
  • AI feature settings such as the master AI switch, selected cloud path (built-in cloud or BYOK), and the BYOK provider choice. The cloud-provider API key itself is stored separately under Android EncryptedSharedPreferences (AES-256) and is not included in the same database row. Per-rule AI capability switches are stored on the rule, as listed above.
  • Web Access settings: whether each mode (local network / access from anywhere) is enabled, the chosen local-network port, the access token (held on the device; in access-from-anywhere mode the browser's login handshake transits the developer-operated relay for forwarding to the phone, where it is validated, and the relay does not log, persist, or cache it — see the Web Access (PC Sync) section), and — when "access from anywhere" is enabled — the assigned remote tunnel slug.
  • Scheduled backup settings (cadence, target folder name, retention count, last successful run timestamp), and the encrypted Google OAuth refresh token used by scheduled backup, which is stored separately from any Google Drive forwarding channel's token.
  • General settings such as retry count, retry interval, request timeout, and forwarding-history retention limit.

These settings are stored in the App's local application data. Users should protect their device and backup files because channel settings may contain sensitive credentials such as Telegram Bot Tokens, email passwords or app-specific authorization codes, webhook URLs, Slack webhook URLs, Bark device keys, WhatsApp Meta access tokens, and CallMeBot API keys. The AI cloud-provider API key, the Google Drive channel and scheduled-backup OAuth refresh tokens, and the Web Access access token are, by contrast, held only in the device's encrypted preferences and are deliberately excluded from backup files and from Android Auto Backup.

Forwarding History and Diagnostic Logs

To help the user confirm whether forwarding succeeded, the App stores recent forwarding records locally. Records may include:

  • SMS sender or call phone number.
  • The message body, a call event summary, or a notification summary.
  • Timestamp, forwarding rule name, target count, delivered count, and success or failure status.
  • SIM slot, subscription ID, call event type, cached contact name, and call duration.
  • Delivery-channel debug information, such as Telegram or webhook responses, SMTP server responses, target phone number, sender and recipient email addresses, error messages, and partial technical error details.

Forwarding records are stored only on the user's device. The user can adjust the retention limit in the App settings, and the App automatically removes older records according to that limit. The default limit is 500 records, with a supported range from 20 to 10,000 records.

The App also maintains diagnostic logs on the device; older entries are automatically replaced as new ones are written. The user can export them as a zip file from the settings page and choose whether to share that file (for example, when reporting a problem). Diagnostic logs are not sent anywhere automatically.

AI Processing (Advanced Subscription)

When the user activates the optional AI features that come with the Advanced subscription and turns on individual AI capabilities for a forwarding rule (one-time-code extraction, tags and spam score, translation, summary), or turns on the #AI natural-language remote command on the Remote Control page, or opens the Ask AI in-app assistant (see below), the App may make AI requests to the cloud path the user has selected. AI processing is opt-in: the AI master switch, every per-rule AI capability switch, the #AI remote-control toggle, and the selected cloud path are all off by default until the user turns them on. A separate one-time AI consent dialog must be acknowledged before the master switch can be turned on, and before an Advanced subscription can be purchased.

AI processing always runs in the cloud — there is no on-device AI path. The user picks one of two cloud paths in AI settings:

  • Built-in cloud AI proxy (default for Advanced subscribers). The App sends the message text, optional sender / title metadata, and the requested operation list over HTTPS to a developer-operated proxy at smsforwarder-api.zobubo.com. The proxy relays the request, using the developer's own paid (billed) provider API keys, to a third-party LLM service — OpenAI, Anthropic, or Google Gemini — returns the structured result to the App, and discards the message body. The paid tier matters most for Gemini: under Google's Gemini API Additional Terms of Service, paid-tier requests are excluded from being used to improve Google products or train Google's generative models, whereas the free tier is not. OpenAI and Anthropic apply equivalent "do not train on API data" defaults to their standard API access. The proxy itself does not log, persist, or cache the message body; only request-level metrics (such as operation, response status, and per-subscriber usage counters) are kept.
  • Bring-your-own-key (BYOK). The user picks Google Gemini, Anthropic Claude, or OpenAI and pastes a personal API key into AI settings. Calls go directly from the device to the provider — generativelanguage.googleapis.com, api.anthropic.com, or api.openai.com — and include the user's API key in each request as that provider requires. The key is held only in Android EncryptedSharedPreferences (AES-256) and is never uploaded to the developer. The provider then processes the text under its own API terms and privacy policy. Whether the call falls under that provider's paid or free tier depends on the API key the user supplies; in particular, for Google Gemini only the paid (billed) tier excludes prompts and responses from Google's product-improvement and model-training data, so users who select Gemini are encouraged to use a paid API key.

When the sender phone number of an incoming SMS matches an entry in the user's local contacts, the App skips AI processing for that message and forwards it without any AI fields.

The AI step's outputs (extracted one-time code, tags, spam score, summary, and translation) are stored alongside the related forwarding history record on the device. They are subject to the same retention limit as the rest of the forwarding history. The original cloud request payload is not persisted on the device: only the parsed result is stored. AI failures never block forwarding.

The optional #AI natural-language remote command always uses the AI cloud path the user currently has selected (built-in cloud or BYOK). The original #AI SMS body and the structured command the AI rewrote it into are saved together in the local forwarding history record for the user's audit. The rewritten command is still validated against the same allow-list as the App's other remote commands; anything outside that list is dropped.

The optional Ask AI in-app assistant lets the user have a multi-turn conversation with the configured cloud AI provider to get help with their own configuration (e.g., debugging a rule that did not fire, drafting a forwarding template, writing a content-filter expression). Ask AI also uses the same cloud path the user has selected and is gated by the Advanced subscription. The text the user types into the chat, plus a redacted snapshot of the on-screen context (the rule, channel, or push record the user opened the chat from — with credentials, full message bodies, and phone numbers stripped before sending), is sent to the cloud provider so the assistant can reply with relevant suggestions. Ask AI conversations are stored locally in the App's database so the user can resume earlier chats; they are not uploaded to the developer and are removed by "clear all data" or by uninstalling the App. Ask AI has its own separate daily usage allowance, tracked alongside but independently of the message-classifier allowance.

The cloud AI providers used by both AI paths above are independent third-party services that the developer does not operate. Under the BYOK path the request is made directly from the device with the user's own API key, so the traffic is governed by that provider's API terms and privacy policy. Under the built-in cloud AI proxy path the same providers receive the message text from the developer-operated proxy, also as API key requests, and the same provider terms apply on top of the proxy's own handling. Users are encouraged to review each provider's published data-handling terms before enabling AI features. The most directly relevant reference for each:

Built-in Email Sending

The Email channel can send mail in one of two ways, chosen per channel:

  • Built-in sending (default for newly created email channels). The App does not connect to an outgoing mail server itself. Instead it sends the email subject and body (which contain the forwarded message content), the recipient address, and the optional sender display name over HTTPS to a developer-operated relay at smsforwarder-api.zobubo.com. The relay then delivers the message through a third-party email delivery service (Amazon SES) from a fixed verified sending address, with no reply-to address. Built-in sending requires an active subscription (Basic or Advanced), which is verified for each request. The relay does not log, persist, or cache the email content; only request-level metrics (such as response status and per-subscriber usage counters) are kept.
  • Custom SMTP. The user switches the channel to use their own outgoing mail (SMTP) account. The App connects directly to the SMTP server the user configured and sends the message using the user's own email account and password or app-specific authorization code. Nothing is routed through the developer-operated relay in this mode.

Email channels that were already configured with a custom SMTP account continue to use that SMTP server; the built-in default applies only to email channels created afterward. The built-in relay is operated by the developer and delivers mail through Amazon SES, an independent third-party email delivery service.

Google Drive Channel

When the user creates a Google Drive delivery channel, the App opens a Google sign-in screen in a Custom Tab. The user signs in with their own Google account and grants two OAuth scopes:

  • https://www.googleapis.com/auth/drive.file — lets the App create and modify only the files it has created itself in the user's Drive. The App cannot list, read, or modify other Drive files.
  • https://www.googleapis.com/auth/userinfo.email — lets the App display the signed-in Google account email on the channel card, so the user can verify which account is connected. The email is shown only on the device.

The OAuth refresh token returned by Google is stored on the device under Android EncryptedSharedPreferences (AES-256). It is not uploaded to the developer and is not included in backup files or in Android Auto Backup; the user re-authenticates the channel after a fresh install.

When a forwarding rule fires through the Google Drive channel, the App calls https://www.googleapis.com/drive/v3/ directly from the device, using the user's refresh token, to create (on first use) or append to the user's chosen log file inside the user's chosen folder. The forwarded message content and timestamp are stored inside that file, in the user's own Drive. The developer does not receive a copy. If the user has configured a proxy on the channel, requests to Google's APIs are routed through that proxy.

The same drive.file scope is also used by the optional Scheduled Google Drive Backup feature; see the Backup, Import, and Device Migration section below. Each Google Drive channel and the scheduled-backup feature each hold their own refresh token, so disconnecting one does not affect the other.

Web Access (PC Sync)

The optional Web Access feature lets the user open a browser on a separate device and read recent SMS, send SMS through the user's SIM card, and operate remote-control surfaces of the App from that browser. The feature has two independent modes that the user enables separately:

  • Local network access (requires Basic or Advanced subscription). The phone exposes an HTTP service on the local network at a port the user configures (1024–65535, with automatic fallback to a nearby free port if the chosen port is in use). The browser connects to the phone directly over the local Wi-Fi network; no traffic leaves the LAN. Local-network traffic is not encrypted (no HTTPS); the in-app screen calls this out and recommends using the feature only on trusted networks.
  • Access from anywhere (requires Advanced subscription). The phone keeps an outbound tunnel open to a developer-operated relay at smsforwarder-api.zobubo.com. The browser connects to a private URL on the relay (a per-device assigned slug, generated when the user enables this mode and reset when the user disables it). The relay forwards request and response traffic between the browser and the phone in real time and does not log, persist, or cache message content; only per-subscriber metrics (such as request counts and connection state) are kept. Browser ↔ relay traffic is over HTTPS.

Both modes share a single access token stored on the device. The browser must present this token to log in; the token is shown to the user in the App once when it is generated, and the user can rotate it at any time. Rotating the token signs out every active browser session immediately. In access from anywhere mode the browser's login request, including the access token it presents, passes through the developer-operated relay on its way to the phone; the relay forwards the handshake to the phone for validation in real time and does not log, persist, or cache the access token. The token is never uploaded to the developer as a stored credential, and is not included in backup files.

When the browser is logged in, the App responds with: recent message records (filtered to what the user's READ_SMS grant allows — if READ_SMS is not granted, only messages the App has already forwarded are returned; the user's full inbox is not), the matching outbound SMS API for the browser's compose box (which uses SEND_SMS on the phone and therefore consumes the user's carrier SMS allowance), and the same remote-control snapshots that #STATUS and #PING already return. The browser cannot reach the rest of the device, the rest of the App's data, or the user's contacts beyond what the in-app pages already display.

If the user's subscription lapses while either Web Access mode is enabled, the browser receives a "subscription required" response on every request until the subscription is renewed or the feature is turned off.

Remote Control over SMS

The user may authorize specific phone numbers to send command messages to the device. When this feature is enabled and the sender's number matches the user's allow list (matched in international format, for example +14155551234, with a maximum of 50 entries), the App can:

  • Send an SMS reply on the user's behalf when the command starts with #REPLY.
  • Toggle a specific forwarding rule, a specific delivery channel, or every rule of a given type (SMS, call, notification, or all) on or off when the command starts with #CTRL.
  • Return a status snapshot of the App's current forwarding state when the command is #STATUS.
  • Return a heartbeat snapshot of the device (battery, network, signal) when the command is #PING.
  • Return a link to this online command reference when the command is #HELP.
  • Re-sync the subscription state with Google Play when the command is #REFRESH.
  • (Advanced subscription only) Translate a free-form natural-language instruction into one of the structured commands above using the user's configured cloud AI provider, then run that structured command, when the command starts with #AI. See the AI Processing section above for the related cloud handling. #AI cannot run any command that is not already on the allow list.

Command SMS are processed locally. The number-matching list is stored locally and is not uploaded to the developer. Numbers not on the allow list are ignored. Result messages can optionally be returned to the sender by SMS, or pushed through one or more of the user's existing delivery channels, according to the user's preference.

Backup, Import, and Device Migration

The App provides local backup and import features. Exported JSON backup files include general settings, delivery channels (excluding the OAuth refresh token for Google Drive channels), forwarding rules (including their per-rule AI capability switches, translation target language, summary minimum length, and source-type toggles), the user-edited AI tag vocabulary, the remote control allow list, SIM labels, and the AI cloud-path selection (built-in cloud or BYOK, and the BYOK provider choice). Forwarding history records, Ask AI conversation history, the Web Access access token, and scheduled-backup state are not exported. The first-launch privacy disclosure consent and the one-time AI consent are not exported either, so they must be accepted again on a fresh install. The AI cloud-provider API key (BYOK path), the Google Drive forwarding channel and scheduled-backup OAuth refresh tokens, and the Web Access access token are deliberately excluded from backup files and from Android Auto Backup; they must be re-entered or re-authorized on a fresh install or a new device.

Backup files may contain sensitive information in plain text, including Telegram Bot Tokens, email passwords or app-specific authorization codes, webhook URLs, Slack webhook URLs, Bark device keys, WhatsApp Meta access tokens, and CallMeBot API keys. The user creates a backup file in one of two ways the App offers side by side: Share backup sends the file to another app through the Android share sheet, and Save to device lets the user pick a folder with the system Storage Access Framework picker. In either case, the App writes the file locally and does not upload it to the developer. Users should transfer backup files only through trusted channels and delete them when they are no longer needed.

The App also offers an optional Scheduled Google Drive backup. When the user enables it, the App authenticates against the user's Google account with the drive.file OAuth scope (independent of any Google Drive forwarding channel — the scheduled-backup feature holds its own refresh token, stored on the device under Android EncryptedSharedPreferences). On the chosen cadence (daily, weekly, or monthly) the App generates the same backup JSON described above, uploads it directly from the device to the user's chosen Drive folder, and prunes older backups according to the user's chosen retention count. The backup never passes through a developer-operated server in this mode. The user can disconnect the scheduled-backup feature at any time, which deletes the stored refresh token from the device; deleting older Drive files already uploaded is done through the user's Google Drive.

When importing a backup, the App reads the JSON file selected by the user and writes the data locally using the user's selected import mode, such as merge or replace.

Subscription and Google Play Purchase Information (com.android.vending.BILLING)

The App uses Google Play Billing for subscription features and uses Google Play to verify subscription status. Subscription purchase flows are handled by Google Play, and Google may process payment, account, device, and order information according to Google's own policies.

The App stores subscription state locally to determine which paid features are unlocked, including:

  • Whether the subscription is active.
  • The subscription tier (Basic or Advanced) and plan identifier (product ID).
  • The purchase token returned by Google Play.
  • The locally recorded subscription expiry time.
  • The most recent verification time.

This information is used to unlock or disable paid features. Subscription state and purchase tokens are otherwise kept on the device — except when the user actively invokes a feature that runs through the developer-operated backend at smsforwarder-api.zobubo.com (currently the built-in cloud AI proxy and the built-in email sending option). In that case, the App sends the Google Play purchase token over HTTPS to the backend's authentication endpoint; the backend validates the token against the Google Play Developer API, issues a short-lived session token (JWT) that the App reuses for subsequent relay requests so the raw purchase token does not need to be sent every time, and persists the validated subscription state (subscription tier, expiry time, latest verification timestamp, and per-subscriber usage counters) so that the entitlement check on each request is fast and so that the state can be kept in sync with Google Play's Real-Time Developer Notifications. The purchase token, the issued session token, and the persisted subscription state are used only for entitlement verification, abuse prevention, and per-subscriber usage accounting — they are not joined to message content, not used for advertising or cross-feature tracking, and not sold.

The App may use Google Play in-app update features to check whether a newer version is available. It may also open Google Play store listings or subscription management pages. Those pages and purchase management flows are provided by Google Play.

The App reads network state to determine whether a network connection is available, to support the "SMS only when offline" channel option, and to apply timeout and retry behavior for Telegram, SMTP, webhook, Slack, Bark, WhatsApp, AI cloud providers, Google Play, and other network requests initiated by configured features.

3. Network Requests and Third-Party Services

The App creates network requests only when the user configures, enables, or actively triggers a feature that requires them. These requests may include:

  • Telegram: sending the user's Bot Token, Chat ID, and forwarded content to api.telegram.org.
  • Email (custom SMTP): connecting to the user's configured SMTP server and sending the email account, password or app-specific authorization code, recipient address, and forwarded content.
  • Email (built-in sending, the default for newly created email channels, requires an active subscription): sending the email subject and body (containing the forwarded message content), the recipient address, and the optional sender display name over HTTPS to a developer-operated relay at smsforwarder-api.zobubo.com, which then delivers the message through a third-party email delivery service (Amazon SES). See the Built-in Email Sending section for what the relay does and does not store.
  • Webhook: sending forwarded content to the HTTP/HTTPS URL the user configured, using the user's chosen method, headers, and body template.
  • Slack: sending forwarded content to the Slack incoming webhook URL the user configured.
  • Bark: sending forwarded content to the Bark server the user configured (the official api.day.app server, or a self-hosted server).
  • WhatsApp: when the user picks the Meta Cloud API mode, sending forwarded content together with the configured phone-number ID and access token to graph.facebook.com. When the user picks the CallMeBot mode, sending forwarded content together with the recipient phone number and CallMeBot API key to api.callmebot.com.
  • Google Drive (forwarding channel and / or scheduled backup): sending the user's OAuth access token and the file payload (a forwarded message line, or a backup JSON file) directly to Google's Drive API at https://www.googleapis.com/drive/v3/, under the drive.file OAuth scope. The OAuth sign-in itself opens accounts.google.com in a Custom Tab. See the Google Drive Channel section for the data flow.
  • Web Access (local network mode, only when enabled): incoming HTTP requests from the user's browser on the local network. No outbound network requests are made by the App for this mode.
  • Web Access (access-from-anywhere mode, only when enabled): an outbound HTTPS tunnel from the phone to a developer-operated relay at smsforwarder-api.zobubo.com, which forwards browser sessions to the phone. See the Web Access (PC Sync) section for what the relay does and does not store.
  • Built-in cloud AI proxy (Advanced subscription, default AI path, only when AI is enabled): sending the message text, optional sender / title metadata, and the requested operation list over HTTPS to a developer-operated AI proxy. The Ask AI in-app assistant uses the same proxy endpoint with a separate per-subscriber daily allowance. See the AI Processing (Advanced Subscription) section for the proxy endpoint and what it does and does not store.
  • AI cloud providers via BYOK (only when the user has chosen BYOK): sending the message to be processed and the corresponding AI prompt directly to the user's chosen provider — generativelanguage.googleapis.com for Google Gemini, api.anthropic.com for Anthropic Claude, or api.openai.com for OpenAI. The provider's own API key, supplied by the user, is included in the request as required by that provider, and the request is then governed by that provider's API terms and privacy policy.
  • Optional proxying: when the user enables an HTTP or SOCKS5 proxy on a channel, the corresponding outbound traffic is routed through that proxy.
  • Google Play: checking app updates, querying subscription products, purchasing, restoring purchases, and verifying subscription status.
  • Google Play store or subscription management pages opened by the user.

When the user receives forwarded content through Telegram, email, an HTTP endpoint, Slack, Bark, WhatsApp, SMS, or any other third-party service, that third party may process the information according to its own privacy policy. The same applies to any AI cloud provider the user configures. Users should review the security and privacy practices of any destination or AI service they configure.

4. Android Permission Usage

The App requests the following Android permissions for these purposes:

  • RECEIVE_SMS: Receive and read new SMS messages for SMS forwarding.
  • RECEIVE_MMS and RECEIVE_WAP_PUSH: Receive incoming MMS for MMS forwarding.
  • SEND_SMS: Send forwarded content (or remote control replies) by SMS to the phone number configured by the user.
  • READ_SMS (optional): Read the device's full SMS inbox only when serving a Web Access (PC Sync) browser session, so the browser can show earlier conversations from the system SMS provider. When this permission is not granted, the Web Access browser session falls back to showing only the messages the App has recorded itself through forwarding. There is no background uploader: READ_SMS is only read on demand when a Web Access browser session requests inbox data. In local-network Web Access mode the response stays on the LAN; in access-from-anywhere Web Access mode the response transits the developer-operated relay in real time on its way back to the browser, with the relay not logging, persisting, or caching the content. See the SMS and MMS Information section and the Web Access (PC Sync) section for the full data flow.
  • READ_PHONE_STATE and READ_PHONE_NUMBERS: Read SIM and subscription information for SIM selection, SIM-slot matching, and forwarded-message details, and monitor call state to detect incoming and outgoing call events for call forwarding.
  • READ_CALL_LOG: Read recent call log entries to obtain call duration, phone number, and cached contact name.
  • READ_CONTACTS: Assist with contact name display for call events; the App does not upload contacts.
  • INTERNET: Send forwarded content to configured network channels and access Google Play related services.
  • ACCESS_NETWORK_STATE: Determine network availability for "SMS only when offline" behavior and request strategy.
  • POST_NOTIFICATIONS: Show foreground service and forwarding status notifications.
  • FOREGROUND_SERVICE, FOREGROUND_SERVICE_DATA_SYNC, and WAKE_LOCK: Keep the background forwarding service running reliably.
  • RECEIVE_BOOT_COMPLETED: Restore the forwarding service after device restart, app update, or quick boot when the user enables related behavior.
  • REQUEST_IGNORE_BATTERY_OPTIMIZATIONS: Ask the user to allow the App to ignore battery optimization so background forwarding is less likely to be stopped by Android.
  • com.android.vending.BILLING: Use Google Play subscriptions and purchases.

In addition to the runtime permissions above, the App declares a notification listener service that relies on the system-level binding permission BIND_NOTIFICATION_LISTENER_SERVICE. This is not a runtime permission. Instead, the user must turn on Android's "Notification access" (also called "Notification listener access") special access setting for SmsForwarder before the App can read notifications posted by other apps. The App reads notifications only after this special access is granted and the user has enabled notification forwarding in the App; the user can revoke the access at any time from the same Android settings page.

Users can revoke permissions and the notification listener special access at any time in Android system settings. Features that depend on revoked permissions or revoked special access may stop working.

5. Storage and Deletion

  • Forwarding configuration, app settings, forwarding history, and subscription state are stored in a local database on the device.
  • Forwarding history is automatically trimmed according to the retention limit selected by the user.
  • When the user deletes channels, rules, or forwarding records, the corresponding data is removed from the local database.
  • When the user uninstalls the App, Android generally removes the App's local data.
  • Information already sent to Telegram, email providers, SMS recipients, webhook endpoints, Slack, Bark, WhatsApp, Google Drive, AI cloud providers, Google Play, or other third-party services must be managed or deleted through those services.
  • Exported backup files and exported diagnostic log archives are stored wherever the user chooses to save or share them. The App cannot automatically delete copies that the user has placed outside the App.
  • The encrypted AI cloud-provider API key (BYOK path), the Google Drive forwarding-channel and scheduled-backup OAuth refresh tokens, and the Web Access access token remain on the device until the user uninstalls the App, disconnects the relevant feature, or runs the in-app "clear all data" action, any of which deletes them.
  • The in-app Settings → Data → Delete account and data action erases the local database and the encrypted credentials above, and asks the developer-operated backend to immediately remove the user's server-side records (subscription record, feedback uploads, remote-tunnel slug, and per-feature rate-limit counters other than the AI usage counters described next). The per-day and per-minute AI usage counters are retained for up to 31 days as opaque numerics tied to an internal account identifier, for abuse prevention (GDPR Art. 17(3)(e)); a nightly sweep removes them after 31 days. See the Data deletion page for the full procedure.

6. Information Sharing

The App does not maintain a developer-operated server that collects SMS, MMS, call, contact, notification, or rule data. The following cases may involve sharing information outside the device:

  • When the user configures and enables a forwarding channel, the App sends SMS, MMS, call event, or notification content to the user's selected destination (Telegram, email recipient, HTTP webhook, Slack, Bark, WhatsApp, Google Drive, or SMS recipient).
  • When the user uses the Email channel's built-in sending option, the App sends the email content, subject, recipient address, and optional sender display name to a developer-operated relay (see the Built-in Email Sending section for the endpoint), which delivers the message through a third-party email delivery service (Amazon SES). The relay does not log or persist the email content.
  • When the user enables the Google Drive forwarding channel and / or scheduled Google Drive backup, the App sends the forwarded message content or the backup JSON directly from the device to the user's own Google Drive under the drive.file OAuth scope. Google processes the upload under its own privacy policy.
  • When the user enables Web Access in access-from-anywhere mode, an HTTPS tunnel from the phone to the developer-operated relay carries browser sessions, including the SMS content the browser is reading and any SMS the browser composes. The relay does not log or persist the message content (see the Web Access (PC Sync) section).
  • When the user enables an HTTP or SOCKS5 proxy on a channel, the corresponding outbound traffic is routed through that proxy server.
  • When the user enables AI processing through the built-in cloud option (Advanced subscription), the App sends the message text and the corresponding operation request to a developer-operated AI proxy (see the AI Processing (Advanced Subscription) section for the endpoint). The proxy relays the request to a third-party LLM (OpenAI, Anthropic, or Google), returns the structured result to the App, and does not log or persist the message body.
  • When the user enables AI processing through the BYOK path and provides their own API key, the App sends the message text and the corresponding prompt directly to the user's chosen AI cloud provider for processing. The provider then handles that data under its own privacy policy.
  • When the user uses Google Play subscription, purchase restoration, app update, or subscription management features, Google Play processes the relevant purchase and account information.
  • When the user voluntarily sends feedback, logs, screenshots, or backup files to the developer, the developer receives the information the user chose to provide.
  • When required by law or necessary to protect the legal rights of users, the developer, or others.

7. Security Notes

The App is designed to keep data local where possible, but its features may involve sensitive SMS, MMS, call event, notification, and channel credential data. Users should:

  • Use the App only on trusted devices.
  • Protect the device with a screen lock or other security controls.
  • Safeguard Telegram Bot Tokens, email passwords or app-specific authorization codes, webhook URLs, Slack webhook URLs, Bark device keys, WhatsApp Meta access tokens, CallMeBot API keys, AI cloud-provider API keys, the Web Access access token, the Google Drive channel and scheduled-backup OAuth grants, and backup files.
  • Confirm that forwarding destinations are trusted accounts, email addresses, phone numbers, or services.
  • Limit remote control to phone numbers the user fully trusts; anyone able to send SMS from those numbers can trigger replies and toggle forwarding.
  • Review and redact diagnostic logs before sharing them, because logs may contain target phone numbers, sender or recipient email addresses, third-party service responses, and error details.

8. Children's Privacy

The App is not directed to children under 13 and does not knowingly collect personal information from children. If a parent or guardian believes that a child has provided personal information to the App or the developer, please contact the developer using the contact information below.

9. Changes to This Policy

This Privacy Policy may be updated when the App's features, permissions, or legal requirements change. Updates will be published on this documentation site or in app release notes.

10. Contact

For questions about this Privacy Policy or data handling practices, contact: