Proposal: rename app

[kurahaupo]

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.

[kurahaupo]

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

[johncartnz]

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, [email protected] 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 .

[kurahaupo]

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.

[jberkel]

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 … 🤖

[Tobias-B-Besemer]

• "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]

Other ideas:

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

[Tobias-B-Besemer]

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 ??? ;)