I have an android (non-game) app that I want to implement cloud backup for. I've looked at the Backup API but found it limited as the actual backup and restore backend processes are controlled by the phone manufacture and Google. I also want to allow the user to manually backup and restore when they want.
There is the new Google Play Games Saved Game service which offers what I'm looking for but my app is not a game.
Has anyone implemented the Saved Game service for a non-game app and can offer some advice on it's suitability? Otherwise, does anyone know whether Google will allow this approach (using the game service for non-game app)?
Thanks.
It sounds like a better solution would be to use the Google Drive API. Specifically, the ability to store application data. From the developer doc:
The 'Application Data folder' is a special folder that is only
accessible by your application. Its content is hidden from the user,
and from other apps. Despite being hidden from the user, the
Application Data folder is stored on the user's Drive and therefore
uses the user's Drive storage quota. The Application Data folder can
be used to store configuration files, saved games data, or any other
types of files that the user should not tamper with.
See: https://developers.google.com/drive/web/appdata
Related
The docs talk about app-specific files and others like media files. Android is a multi-user environment, right?? It seems that in some instances at least, multiple users on a device all use the same instance of the app (google apps for instance). The Docs talk about "Files meant for your app's use only" i.e. app-preferences. How does android deal with user preferences for an app? Are most apps just single-user? In the case of a tablet for instance, does each user in the family have to install their own instance of an app?
Android is a multi-user environment, right?
Yes.
It seems that in some instances at least, multiple users on a device all use the same instance of the app (google apps for instance)
If you mean the same installed APK (or APK set), then yes.
How does android deal with user preferences for an app?
If you mean SharedPreferences, they are stored on internal storage. Each user gets their own view of internal storage, independent from that of any other registered user on the device. So, if there are 1,337 users, and each have used the app, there will be 1,337 SharedPreferences files, one per user.
In the case of a tablet for instance, does each user in the family have to install their own instance of an app?
No. However, depending on circumstances, some users may not have access to all of the installed apps (e.g., restricted profiles).
We're implementing a loginless system on our web, iOS, and Android app that allows the user to have a persistent identity without requiring any sign-up/sign-in flows whatsoever.
A key part of loginless is relying on iOS and Android to permanently store our app's data in the user's iCloud / Google account so that the data is automatically restored for the user in each of the scenarios:
(i) Quitting and re-opening the app (accomplished with SharedPreferences in Android, UserDefaults in iOS)
(ii) Uninstalling and re-installing the app on the same device (accomplished with key/value backup in Android¹, Keychain + NSUbiquitousKeyValueStore in iOS)
(iii) Setting up a new device based on a backup of an old device (accomplished with key/value backup in Android¹, UserDefaults + Keychain + NSUbiquitousKeyValueStore in iOS)
(iv) Installing the app on a brand new device signed into the same iCloud / Google account that the user previously used the app with (accomplished with NSUbiquitousKeyValueStore in iOS)
The only case we have remaining is figuring out how to accomplish (iv) for Android. Does key/value backup in Android restore the data in this case, even when the brand new device wasn't set up from a backup of an older device?
We've discovered the existence of Cloud Firestore and AccountManager during our research, but it seems like the data in Cloud Firestore is keyed on an device basis so it wouldn't accomplish (iv), and it seems like AccountManager requires asking permission from the user to ask for their accounts via android.permission.GET_ACCOUNTS, plus the whole design of loginless is intended not to ask the user for any personally identifiable information. Are we correct in these conclusions, or could Cloud Firestore be used to accomplish (iv)? Is there anything else we can use to accomplish (iv) in Android?
¹ We decided to use key/value backup instead of auto backup because the frequency of backups is greater than that of auto backups. See more information on the difference in Android's documentation.
Shared preferences should restore from the previous device if the android:allowBackup attribute is set to true. As far as I know this works if you have your phone backed up at Google (Drive).
Regarding the IV point, previous to 2018 you could use the now-depracted Android Drive Api, but currently you can use the Drive API v3 to enable an app to use the customer space in their drive to store application-specific data.
This folder is only accessible by your application
and its contents are hidden from the user and from other Drive apps.
I have seen that Play Store Developers received a mail to inform users about the usage of their personal data and to state why and how app's make use of certain features (like writing to the external storage/SD Card). I have to admit, I am new to Android Development and helping out here.
In our existing Play Store App we plan to release a new feature to take photos and thus access the camera for this purpose.
I now wanted to ask how the following requirement has to be implemented:
"Post a privacy policy in both the designated field in the Play Developer Console and from within the Play distributed app itself."
Is it some kind of Readme file, we have to upload or (like Apple does) have to provide a website with those information for the Play Store?
(see http://www.iubenda.com/blog/privacy-policy-for-android-app/ first abstract), whereas other sources just talk about active URLs. Basically, a URL is not always available in an application (consider the case where a user got no internet connection)
How does it have to be presented in the App? Simple Toast, when accessing the Camera the first time or rather a new menu item "Privacy Policy" for the user and display the information in a website with formatted HTML, which we could also use for the PlayStore?
For the overal requirements see:
https://play.google.com/about/privacy-security/personal-sensitive/
This question does not ONLY cover the Google PlayStore but also the best practises for embedding a such IN an Android Application.
I would look at how other Google apps do this to see their (Google's) preferred way of handling this. Most Google apps have a privacy policy menu item in the navigation drawer for basic privacy information, and show a full-screen popup where you have to tap "I agree" for more sensitive topics like location history, for example. This seems like a good approach to me, but you'll have to consult with a lawyer regarding privacy laws/requirements within your home country.
For our implementation it was only concerning two aspects:
1) Camera Access
2) Storing data
I think the reason for Google to request a license Post was and still is to
Developers more aware of how they use possible resources
Users more aware of the usage of THEIR resources
Camera Access
We came up with the solution to not include the camera on our own, but instead performing "the Android way of delegating actions to other applications" and let someone else perform this for us. with the MediaStore.ACTION_IMAGE_CAPTURE. Bit unlucky it is that we had to write a FileProvider to support Androids new Sandboxing feature, as we come to step 2 "Storing Data"
Storing Data
We don't use the external storage anymore for this, instead we use the app's personal storage, as the data is tightly coupled to the rest of the application anyway. Of course, we had to ensure the app is still working if:
1. The user wants to delete specific files
2. The user deletes the app's data in settings
That's it: No Privacy Policy required anymore, as we don't use anything that would require certain permissions :-)
Sorry if my question is asinine.
I'd like to send the data in SQL table format from one Android device to a second device, so the user in the second device can store and use the received data with my App. What are the best options to do this?
You don't want to go down the path of trying to move one sqlite file on a device into the same location on another (I assume that's where you were going with the Bluetooth tag). Without root access on the destination device, you won't be able to write the file. From an end (power) user perspective, Titanium Backup is a great solution for this, but of course requires root.
If you're looking for "stop on one device, resume on another" functionality for your app, check out Google Play Services Saved Games. It has exactly the functionality you're looking for baked in, and you have to do nothing along the lines of the support infrastructure.
Of course, this is dependent on Google Play Services, so if you're looking to publish on the Amazon App Store (or anything where you're not guaranteed to have the Google stuff available), you may be better off rolling your own web based synchronization infrastructure or subscribing to a service that offers something on par with what Google makes available.
I want to store a small amount of data in a way where it persists between application installs. I obviously can't use SharedPreferences as they are removes upon uninstallation. Is there any way to store data so it survives a reinstall of the app?
The data I want to store is a unique ID, to allow blocking of users of the app if they misbehave. If I cannot store an ID, can I access the Google account(s) email addresses to use them as an indicator?
This blog post makes it clear none of the IDs the OS produces are any good, especially when considering tablets
Android: Identifying app installations
You can store the data in shared preferences and use a backup manager to have them backed up automatically. They should be restored once the app is reinstalled.
There is no real way of blocking the app for certain persons. You could fore all your users to create an account to use the app and block the accounts but they always can recreate an account. You could store something on the SD-Card and check for it but malicious users can find that and delete it. You could try to get the user to authenticate themselves with their google account against your app (andlytics is using an authentication method like that) but the user can factory reset his phone and create a new google account.
You have to choose how important the blocking of the users is and how much you want to annoy your other users because of some users that are not using your app as intended.
yes. you can store some data in the internal memory or the sd card.this can be done by creating(.somename)folder which is invisible to user and create a file.txt to store the data.
If the app is removed, the data is removed. You could put something on the SD card, but there's no reason to believe it would stay there. You might be able to work something through the application licensing mechanism. Details here