I am developing an SDK which multiple applications will use. This SDK should login to the user's account and will provide the application with server interaction works. My problem is that I want to share this user's account between these applications. So there should be a mechanism in which applications will first look up the account if it exists, they will use it, if not, they will create it. But I am having technical challenges.
I looked up android's custom accounts so that the account credentials could be stored there. But I am not sure if it is possible there. First, is it possible to see if an account under a certain type exists? Second, is it possible for an application to use an account which another application created? For example, google games is doing exactly this functionality. Any game can login with user's google game account. But I need to do this without installing a third-party service on user's device.
Generally, if you have anything helpful to solve this situation, it is much appreciated.
If you looking for a solution on the device you can use a content provider to share data between the two apps.
After digging deep in the explained situation, I got my answer
First, yes it is possible to see if there exist an account under an specific name. This name can be different from the application's URI.
Second, it is possible to use an account which another application has been created.
So in the SDK, I can first lookup a contracted account name which there will be an stored token. If it exists, the SDK will store it in the shared preferences. If it does not exist, the SDK will create the token using the user's credentials. This way, other applications can use this account and if the application which created the account has been uninstalled, the next application which runs, will recreate the token in accounts from its shared preferences.
Related
I'm working on an app for a customer that already have a couple of apps. Request is to find a way to have an ID/string that could be generated (using a GUID) and shared between that set of apps. A sort of "CustomerDeviceID".
i.e. When user installs the first app from that publisher an ID is generated and stored in some way. Then, when user installs the second or third app, that ID could be retrieved and used. Obviously that process should NOT be driven by the user (no pickers, no permissions, no intents).
Android provides ANDROID_ID to do that but it is generated using keystore, so apps should also be signed using the same keystore (customer apps aren't!).
On iOS we are using shared keychain, but I can't find a way to do that on Android... any ideas? Thanks in advance
Im developing an android application for the first time (no prior experience whit coding....). Mainly the app is going to be used at work as a tool for service technicians. The app is almost ready for field testing, but there is one thing i need the app to do before that. I need the app to force the user to log in every time its opened. This is because some of the info on the app is confidential, and only people that currently works for the company is allowed to have this info. Whit firebase i can then block the users that leave the company, or users that are not verified. Currently the users sign in whit google and they stay signed in until they clear the app data or delete it.
I have looked far and wide for the answer to this, but i have only come across different use of timers.
If anyone has a better solution to this "safety" issue, im open to anything.
If you are using Google Sign-In for authentication, there is no out of the box support for forcing your user to authenticate with Google every time they use your app.
This makes sense, because the user is still authed with Google on your phone. A login system only authenticates the user; it doesn't inherently protect data stored on the device. As long as Google has a valid access token, the user won't have to type a username and password again (and simply clicking "login with Google" again doesn't really provide extra protection here).
If your primary concern is blocking access to users who have left the company, you should be covered if you are using Google Apps for your company. If you disable the user's account, their access tokens should become invalid. Google Apps admins can also manually revoke access to specific apps for specific users.
If you don't use Google Apps (e.g. your users are using #gmail.com accounts or accounts from a domain outside fo your control), you might want to consider implementing a list of users allowed to access the application, and verify the current user has access by checking that list via an API call on launch.
If the goal is really protecting the confidential information in the application, you might want to take an approach similar to Android Pay in which you require your user to set and enter a PIN number to access the application. As an added benefit, you can then use that PIN to encrypt any confidential data you are storing locally.
I will suggest you take a look into shared preferences and every time when the user is back into the app you send them to the login activity.
in my company, we have two apps that access an authentication (from our own webservice) token from the android account manager. Because this is a SSO, we decided to extract the login (activity and AbstractAccountAuthenticator) into a library, that both apps are binding to.
In order to keep the account in the android system, if one of our apps gets uninstalled (assuming the user installed both of our apps), we gave the accountType a unified name ex. my.company.auth (both apps however have the package name my.company.a and my.company.b respectively).
The problem lies when both of our apps gets uninstalled: the entry in the account settings in android is still there.
Does anyone know why or what I am doing wrong?
Does it have to do with the accountType, that has a different 'package name' then the apps?
Thank you very much in advance
You need to separate your custom account type component and provide a separate apk file.
When user tries to use any of your app, you need to check if custom account type app exsits on the device or not.
If your account type app doesn't exist, direct user to playstore for downloading your custom account type app so that user can create account for your custom account type and continue to use your app.
In this way, since user created account is not tied to one app and custom account type is separate app, uninstalling any of your app won't delete account created for your custom account type.
Is it possible to build app whit integrated dropbox acc, and use this account for all clients? I want to upload images to dropbox, and all client apps can download it, or upload to this acc from my app?
I have read all dropbox sdk tutorial from there site, but steal not sure if this is possible.
Not really. DropBox uses OAuth for authorization to allow users to login with their own accounts. Even assuming you figured out how to log in on their behalf with your own credentials you would be handing out your credentials to anyone who wants them, allowing someone to change the password on the account, etc.
Alternatively I suppose you could generate tokens and hand those out instead, however you'd have to setup some sort of web service for this, and you'd still have problems with people being able to do stuff to your account that no doubt you don't want them to do. E.g. I could create an app that just instantly deletes everything that anyone uploads, or I could create an app that fills up your quota with files filled with zeroes.
This is not what DropBox intends you to use the API for (and in fact it may be against the ToS, you should probably read to make sure if you're going down this route despite my discouragement). You should use a more appropriate storage method.
A month ago I asked this question. Even with a Bounty nobody came up with a better answer then using the Imei of the device to identify the user and then sync the phone with the server.
Now I stumbled across the Android AccountManager classes. Would it be possible to use this classes to store a username and a password that could be accessed after a delete/reeinstall cycle of my application?
If yes how would I do this? And would that require the user to enter its keystore credentials every time the application runs and the keystore isn't opened already?
I don't think so. In my experiments accounts are deleted if the package containing the authenticator that creates them is deleted.
I am fairly new to Android, but I think your goal can be accomplished by using two Managers together.
First, you use the AccountManager to perform the necessary association of credentials and network resources.
Second, you use the BackupManager to save your application specific AccountManager records to the cloud. If your app is ever deleted, by virtue of Google Market tracking your app should be restored to the device, and through your app's implementation of BackupManager all the prior AccountManager records as well.