SMS Backup+ review: Gmail and IMAP backup for Android messages

SMS Backup+ scope and Android use case

SMS Backup+ addresses a narrow but consequential problem: preserving Android communication records outside the phone. It backs up SMS, MMS and call log entries through Gmail or another IMAP server. The intended users are Android users who want a network-backed copy of their messages, especially people changing phones, reinstalling applications or restoring records after local data loss.

The application stores backed-up call logs under a configurable label that defaults to `Call log`. SMS records use the `SMS` label by default, and the call log label can be changed to `SMS` if both types should share one label. Call log content includes duration, phone number and call type. The documented example is:

267s (00:04:07) +44123456789 (incoming call)

This is useful when the backup needs to remain readable through an email or IMAP client rather than being locked inside an Android-only database. It is not a complete archive for every Android communication feature. The README explicitly says that Rich Communication Services, also called RCS, Advanced Messaging, Advanced Communications, joyn or Message+, is not supported and has no stated support plans.

There is also an important distinction between backup and restore. SMS and call logs can be transferred back to the phone. MMS files can be backed up, but the README warns that MMS are not restored. That boundary makes SMS Backup+ a selective recovery tool rather than a complete round-trip archive for all message formats.

Gmail and custom IMAP data flow

SMS Backup+ uses Gmail by default, while the same backup mechanism can target another IMAP server. Gmail labels correspond to IMAP folders, and the application creates the required folders during the first backup. The repository description names Gmail and Gcal as the default destinations, while the README also documents Google Calendar integration for call log entries.

Authentication changed because of Google API policy. Earlier versions could use XOAuth2 for supported operations, including contact matching and writing call log records to a calendar. The README states that Google's June 2019 sensitivity-scope policy prevents SMS Backup+ from using XOAuth2 to save messages into the mailbox. Message backup through Gmail consequently requires a password for IMAP access. That password can be a generated application password, which can be revoked without changing the user's normal Google password.

For a custom account, the user changes `Authentication` to `Plain text` under `Advanced settings - Custom IMAP server`, then enters the server address, user name and password. For self-signed servers, the README instructs users to select TLS and enable `Trust all certificates`. That setting weakens certificate validation and should be treated as an explicit deployment choice, not as an invisible default.

The architecture is therefore account-oriented. The app reads Android SMS, MMS and call-log data, formats records for backup, and sends them to Gmail or an IMAP destination. Restore reads stored records from Gmail, with SMS and call logs eligible to be written back to Android. MMS backup is not equivalent to MMS restore.

Installing SMS Backup+ and completing the first backup

The README does not provide a Gradle installation procedure or a manual APK installation command. It directs users to the Google Play Store and F-Droid, and it also mentions GitHub releases for beta builds. The normal first-use path therefore begins by installing the published Android application, rather than by building the repository from source.

After opening SMS Backup+, the user needs an IMAP account or a Gmail account with IMAP enabled. Tap `Connect`. The app first asks for permission to access contacts when that step is presented, then asks the user to confirm the Gmail account for backups. If no Google account is registered on the device, a browser window opens for web-based authentication. A successful connection changes the `Connect` control to a switched-on state.

The first backup is manual because SMS Backup+ must know whether existing device messages should be uploaded. Choose `Backup` to upload the messages currently stored on the phone, or choose `Skip` if the messages have already been backed up elsewhere. `Skip` does not send the existing messages to Gmail and marks them as backed up. The README warns that messages arriving after the app was last uninstalled and before this initial backup will not be backed up to Gmail.

Android permissions are part of the first run. Before backup starts, SMS Backup+ requests the SMS permission needed to send and view messages. Call log backup is disabled by default and requires separate phone and calendar permissions when enabled. No shell command is documented for these steps, so the tutorial remains within the documented application interface.

Restoring SMS and call logs with a bounded default

Tap `Restore` to retrieve stored messages. The README says that the default restore scope changed in version 1.5.11 to 500 messages, while `Advanced Settings` can change that behavior. A restore can target a phone that already contains messages. SMS Backup+ skips records that are already present, which reduces the chance of duplicating existing SMS.

Android imposes a prerequisite for writing messages. Before restoration, the user must confirm the change of the default SMS app. The app explains that this confirmation is required to obtain the permissions needed to write messages. The phone may therefore need to move away from its current default SMS handler before a restore can complete.

Call logs use a separate backup label by default, and the application can restore those entries as well. When call log backup is enabled, users can select which call types to include and can optionally sync entries to Google Calendar. Those features add extra permissions and account access. They also make the backup configuration more complex, especially when the call log label is changed to `SMS` to combine storage under one label.

The most important limitation is format-specific. The restore path is documented for SMS and call logs, but MMS restore is explicitly unavailable. A successful Gmail backup therefore does not imply that every backed-up item can be reconstructed on a new phone.

Google policy, IMAP alternatives and security trade-offs

The main adoption constraint is the authentication split between Gmail and other IMAP servers. Gmail message backup no longer uses XOAuth2 because of Google's API policy. The app instead requires a password for IMAP access, with an application password being the documented option. This differs from the earlier model in which the app could use OAuth-based authorization for mailbox writes. The README also says that access granted through supported XOAuth2 operations can be revoked at any time.

A genuine alternative is to use a custom IMAP account rather than Gmail. In that approach, the user selects `Plain text`, supplies the server address, user name and password, and the backup labels become folders created on that server. This is not a different backup mechanism inside SMS Backup+. It is the same app using a different account destination and authentication path. It may fit organizations or individuals that already operate an IMAP service and do not want their backups tied to Gmail.

The custom-server path has its own operational tradeoff. Selecting TLS and `Trust all certificates` can make a self-signed server usable, but accepting unknown certificates can hide certificate errors and is not equivalent to ordinary certificate validation. The README does not describe server-side retention, quotas, encryption at rest, backup rotation or recovery testing. Those properties must be checked in the selected Gmail or IMAP service rather than inferred from the Android client.

For security-conscious users, the choice of application password, IMAP server and certificate policy deserves explicit review. The app does not need a Gmail password according to the README, but mailbox backup still requires a credential or equivalent authorization mechanism.

RCS exclusions, third-party triggers and maintenance status

RCS is a hard boundary for this project. The README says it is unsupported and has no plans to add support. Users who rely on RCS should not treat an SMS Backup+ archive as a replacement for RCS export. MMS presents a related but different limitation: backup support exists, while restore does not.

The application can be triggered by another Android application when `3rd party integration` is enabled in Advanced Settings. The documented broadcast intent is `sms.backup.plus.BACKUP`. It works even when `Auto Backup` is disabled, which gives another app a way to request a backup. The repository does not provide a CLI backup command, so this integration is the documented programmatic entry point.

The repository is not archived. Its last push was on 2026-08-11, so the repository metadata does not indicate an abandoned project. However, the listed releases are older: `1.6.0-BETA2` and `1.6.0-BETA1` were released on 2019-10-23, and `1.5.11` was released on 2018-04-23. The README states that the project is available through the Google Play Store and F-Droid, and it invites users to join a beta programme for more frequent updates. Upgrade cost therefore depends on which published build is installed and whether the user's Android version remains compatible with it.

The project is licensed under `Apache-2.0`, with licensing files such as `COPYING` and `NOTICE` present at the repository root. That identifies the project's license terms, but it does not answer operational questions about third-party services or account data.

Practical adoption checks for SMS Backup+

SMS Backup+ is a reasonable fit for a user who wants SMS and call log records stored in Gmail or a custom IMAP account and who accepts the documented restore workflow. The Gmail path is convenient, but it depends on an IMAP-enabled account and, under the documented policy, a password or application password. A custom IMAP path offers destination control, although it transfers responsibility for server availability and certificate configuration to the user.

Before committing to it, test a small restore rather than assuming that the first backup proves recovery. Check whether your Android phone permits the default SMS app change required by the restore flow. If your archive includes MMS, test the actual desired recovery procedure and account for the fact that MMS restore is unsupported. If you need RCS, do not select this project as the archive.

The first adoption decision is account destination: Gmail or an existing IMAP server. The first technical check is authentication, especially whether an application password is acceptable for your account policy. The first recovery check is a controlled restore of SMS and call logs into a phone whose current state you understand. For this project, those checks matter more than the size of the feature list because storage can succeed while restoration remains unavailable for specific message types.

Editorial conclusion

Adopt SMS Backup+ if you need an Android backup stored in Gmail or a custom IMAP account and can work with its Google authentication constraints. Do not adopt it as an RCS archive or if restoring MMS is a requirement. Before relying on it, verify the exact Gmail authentication path, test a small restore, and check whether your Android version and message types are covered by the documented limitations.

Frequently asked questions

Official sources

1. jberkel/sms-backup-plus on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases