search

jberkel / sms-backup-plus

Backup Android SMS, MMS and call log to Gmail / Gcal / IMAP
https://play.google.com/store/apps/details?id=com.zegoggles.smssync
Apache License 2.0
1.79k stars 497 forks source link

Proposal: rename app #986

Open kurahaupo opened 4 years ago

kurahaupo commented 4 years ago

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 commented 4 years ago
johncartnz commented 4 years ago

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 .

kurahaupo commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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:

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 4 years ago

Other ideas:

Tobias-B-Besemer commented 4 years ago

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