starred/sms-backup-plus-jberkel

Fork 0

mirror of https://github.com/jberkel/sms-backup-plus.git synced 2026-04-25 17:05:59 +03:00

[GH-ISSUE #986] Proposal: rename app #782

New issue

Open

opened 2026-02-26 01:31:53 +03:00 by kerem · 7 comments

kerem commented

2026-02-26 01:31:53 +03:00

Owner

Originally created by @kurahaupo on GitHub (Oct 7, 2019).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/986

I propose that this app be renamed (or forked to a new name) that focuses on the idea of providing a unified view of messaging activity within Gmail.

I think this would help with two things:

reduce people asking for "save locally" as a feature;
improve the chances that Google would recognize this as "a Gmail app", and thus approve it to use the "sensitive" scope API calls.

If it's a matter of forking, then I'd suggest splitting off the "phone call timeline" into a separate App. Or even taking the OpenIntents approach of making several small modular cooperating apps so that each one requires only 1 or 2 permissions.

Please make suggestions for names in the comments.

Originally created by @kurahaupo on GitHub (Oct 7, 2019). Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/986 I propose that this app be renamed (or forked to a new name) that focuses on the idea of providing a unified view of messaging activity within Gmail. I think this would help with two things: 1. reduce people asking for "save locally" as a feature; 2. improve the chances that Google would recognize this as "a Gmail app", and thus approve it to use the "sensitive" scope API calls. If it's a matter of forking, then I'd suggest splitting off the "phone call timeline" into a separate App. Or even taking the OpenIntents approach of making several small modular cooperating apps so that each one requires only 1 or 2 permissions. Please make suggestions for names in the comments.

kerem added the

meta

label

2026-02-26 01:31:53 +03:00

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@kurahaupo commented on GitHub (Oct 7, 2019):

Gmail SMS Reader
Gmail SMS Merge
Gmail Everything
Gmail Merger
Read SMS in Gmail

@kurahaupo commented on GitHub (Oct 7, 2019): * Gmail SMS Reader * Gmail SMS Merge * Gmail Everything * Gmail Merger * Read SMS in Gmail

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@johncartnz commented on GitHub (Oct 7, 2019):

Would the intent of the proposal be to retain the "restore" function?

If yes, then:

Gmail SMS Backup
Gmail MMS Backup
Gmail Phone Log Backup

(The three complementary apps)

On Mon, 7 Oct 2019, 15:52 Martin Kealey, notifications@github.com wrote:

Gmail SMS Reader

Gmail SMS Merge

Gmail Everything

Gmail Merger

Read SMS in Gmail

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jberkel/sms-backup-plus/issues/986?email_source=notifications&email_token=AM3MKJ2SNLQXVHL675XUX7TQNKP63A5CNFSM4I564B22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAO4MJA#issuecomment-538822180,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AM3MKJ3M4BV2V642LEF5SALQNKP63ANCNFSM4I564B2Q
.

@johncartnz commented on GitHub (Oct 7, 2019): Would the intent of the proposal be to retain the "restore" function? If yes, then: Gmail SMS Backup Gmail MMS Backup Gmail Phone Log Backup (The three complementary apps) On Mon, 7 Oct 2019, 15:52 Martin Kealey, <notifications@github.com> wrote: > > - Gmail SMS Reader > - Gmail SMS Merge > - Gmail Everything > - Gmail Merger > - Read SMS in Gmail > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/jberkel/sms-backup-plus/issues/986?email_source=notifications&email_token=AM3MKJ2SNLQXVHL675XUX7TQNKP63A5CNFSM4I564B22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAO4MJA#issuecomment-538822180>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AM3MKJ3M4BV2V642LEF5SALQNKP63ANCNFSM4I564B2Q> > . >

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@kurahaupo commented on GitHub (Oct 11, 2019):

Just one caveat: my discussions with folk in Google can be summarized as

Providing a storage service for backups isn't what Gmail is for
and therefore
Why don't you just provide your own server for people to save their backups onto?

This strongly suggests that keeping the word "backup" in its name would be a significant obstacle to approval.

In effect, I am proposing a marketing exercise targeting those few people within Google who assess whether an app gets approval to access Gmail. Whether the name appeals to anyone else is comparatively secondary. (The name could be changed again once it's approved.)

So I would aim for a name that conveys this is an app that enables reading SMS and email in a unified view. If further explanation is necessary: it functions as an add-on to Gmail, and therefore needs the same access as Gmail.

I would also suggest replacing "backup" with (say) "synchronize" in the UI and even in the source code.

There may even be a case for splitting off the "restore" functionality into a separate mini-app, which could if necessary still use IMAP - people are more accepting of a few hoops if they ever get to the point of needing to restore.

@kurahaupo commented on GitHub (Oct 11, 2019): Just one caveat: my discussions with folk in Google can be summarized as * _Providing a storage service for backups isn't what Gmail is for_ and therefore * _Why don't you just provide your own server for people to save their backups onto?_ This strongly suggests that keeping the word "backup" in its name would be a significant obstacle to approval. In effect, I am proposing a marketing exercise targeting those few people within Google who assess whether an app gets approval to access Gmail. Whether the name appeals to anyone else is comparatively secondary. (The name could be changed again once it's approved.) So I would aim for a name that conveys _this is an app that enables reading SMS and email in a unified view_. If further explanation is necessary: _it functions as an add-on to Gmail, and therefore needs the same access as Gmail_. I would also suggest replacing "backup" with (say) "synchronize" in the UI and even in the source code. There may even be a case for splitting off the "restore" functionality into a separate mini-app, which could if necessary still use IMAP - people are more accepting of a few hoops if they ever get to the point of _needing_ to restore.

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@jberkel commented on GitHub (Oct 23, 2019):

In effect, I am proposing a marketing exercise targeting those few people within Google who assess whether an app gets approval to access Gmail.

if it's not a AI making these decisions. You never know with Google … 🤖

@jberkel commented on GitHub (Oct 23, 2019): > In effect, I am proposing a marketing exercise targeting those few people within Google who assess whether an app gets approval to access Gmail. if it's not a AI making these decisions. You never know with Google … 🤖

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@Tobias-B-Besemer commented on GitHub (Dec 25, 2019):

"SMS Gmail Sync"
"Sync SMS to Gmail"
"SMS to Gmail"
"SMS 2 Gmail"
"SMS-Addon for Gmail"
"SMS-Addon 4 Gmail"
...

Or, if you wont be bound to Gmail one and forever and maybe want to have a look if it works e.g. with Outlook.com, too:

"SMS Mail Sync"
"Sync SMS to Mail"
"SMS to Mail"
"SMS 2 Mail"
"SMS-Addon for Mail"
"SMS-Addon 4 Mail"
...

I read that the fee for the check will be $15,000 - $75,000... I guess to much for this project and no one will spend so much money that this project can make the check...
But this info was from October 2018... Is it still up-to-date ???
https://www.androidpolice.com/2018/10/08/google-updates-gmail-api-policies-developers-will-require-app-reviews-security-assessments/

@Tobias-B-Besemer commented on GitHub (Dec 25, 2019): - "SMS Gmail Sync" - "Sync SMS to Gmail" - "SMS to Gmail" - "SMS 2 Gmail" - "SMS-Addon for Gmail" - "SMS-Addon 4 Gmail" - ... Or, if you wont be bound to Gmail one and forever and maybe want to have a look if it works e.g. with Outlook.com, too: - "SMS Mail Sync" - "Sync SMS to Mail" - "SMS to Mail" - "SMS 2 Mail" - "SMS-Addon for Mail" - "SMS-Addon 4 Mail" - ... I read that the fee for the check will be $15,000 - $75,000... I guess to much for this project and no one will spend so much money that this project can make the check... But this info was from October 2018... Is it still up-to-date ??? https://www.androidpolice.com/2018/10/08/google-updates-gmail-api-policies-developers-will-require-app-reviews-security-assessments/

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@Tobias-B-Besemer commented on GitHub (Dec 25, 2019):

Other ideas:

"Android Data to Mail"
"Android Phone Data to Mail"
"Android Phone Data Sync"
"Android Communication Data Sync"
...

@Tobias-B-Besemer commented on GitHub (Dec 25, 2019): Other ideas: - "Android Data to Mail" - "Android Phone Data to Mail" - "Android Phone Data Sync" - "Android Communication Data Sync" - ...

kerem commented

2026-02-26 01:31:53 +03:00

Author

Owner

@Tobias-B-Besemer commented on GitHub (Dec 25, 2019):

One more other idea:
Create a non-commercial organisation that can accept donations. Corporates can dispose donations from tax.
Now fork the app, remove the UI and build a lib with.
Every project and comoany should be free to use this lib in there apps! No matter if it is a backup, a sync, a office, or whatever app...
Now would be the question who have to make the security check ??? Each app, or would it be enough, if everyone who is interested in using the lib spend a bit to the organisation developing it, and a "Demo App", just having a UI, can show the complete possibilities of the lib, but nothing else, will make the check ??? ;)

@Tobias-B-Besemer commented on GitHub (Dec 25, 2019): One more other idea: Create a non-commercial organisation that can accept donations. Corporates can dispose donations from tax. Now fork the app, remove the UI and build a lib with. Every project and comoany should be free to use this lib in there apps! No matter if it is a backup, a sync, a office, or whatever app... Now would be the question who have to make the security check ??? Each app, or would it be enough, if everyone who is interested in using the lib spend a bit to the organisation developing it, and a "Demo App", just having a UI, can show the complete possibilities of the lib, but nothing else, will make the check ??? ;)