I have an app I've built for a client that uses a custom AccountAuthenticator. It works wonderfully and it does what the client wants.
However, that is only the first app in what will be a collection of apps that will be using the same authentication manager, and this is where I'm not sure how to proceed.
I have no way of knowing which apps will be installed by any given user, or the order they may be installed. I do not what to require the user to provide their credentials for each app; that defeats the purpose of having an authentication manager.
From some initial testing it seems that just including the same code in each app will not work.
Should I do something like what is needed to use any of the google play services? Write a function that tests for the presence of an app that just does authentication stuff, and then send the user off to the market to install the app that does the authentication? Or download the apk from our own servers?
Or is there some other way that would avoid having to push the user out of the app?
I'm trying to implement the same environment than you, several applications using same account, my final approach is (I don't say it's the best way):
Have a "background" authenticator application, all normal apps will check if this app is installed, otherwise launch google play to download it.
This authenticator application will create the account using AccountManager (tutorial here) and it will not have any launcher activity, will only be launch from another applications to create the account.
Having this authenticator application, the implementation of the other ones seems easy (seen here)
Related
I'm trying to create an AccountAuthenticator to be used with multiple of our apps (so one account in the system-settings used by multiple apps). Just like all Google-apps use the same account on the system.
The problem is: How can I set it up that only one app (we don't know which it will be) needs to be installed and when a second app gets installed, it can just re-use an existing account?
I've created my AccountAuthenticator using this tutorial and embedded into a library-project which gets included in all our apps. This works fine when only one app is installed.
As soon as a second app gets installed and the user tries to login, the system shows the intent-chooser dialog where he can pick both of our apps (because they both use the same authenticator-library with the same intent-filter). This should be the problem as well here (but I havn't verified it yet).
With some research you'll stumble across sharedUserId and this tutorial. But this "solution" has the problem, that you need some kind of always-first-installed app with the authenticator in it. Plus, with the new Google Play App Signing a sharedUserId seems impossible because every app will be signed with a different signature.
There might be a way to grant other apps access to the authenticator but there's still the problem that the authenticator-app needs to be installed first (as suggested here).
How can I solve this? How can I share an AccountAuthenticator with multiple apps without installing an app holding it first? How does Google do it? Do they have their authenticator in the Play Services?
Google Play App signing allows you to re-use the same signature across multiple apps, for precisely this sort of problem.
Just choose "Reuse signing key" when you see this screen:
I have been recently looking into the google home hardware and would like to build an assistant app that communicates between the google home hardware and an app on the users device, so far what I have been able to find is that an assistant app can be built that works with a webhook to a backend but not directly to an app on the device which is what I want, is this possible or has this capability not been added as of yet?
Such a feature does not exist, nor is it really likely to exist in the future in the way you describe. Google Home is just one device that supports the Google Assistant, and many of these others have other setup and linking abilities and requirements.
You don't indicate what your use case is, but it sounds like you might want to investigate Account Linking which will let your Action key data (such as commands) against your user's account id. You can then use something like Firebase Database or Firebase Cloud Messaging to update data or trigger an event in your app.
My question is specifically about one line in Android documentation here. https://developers.google.com/android/work/prov-devices#set_up_device_owner_mode_google_account . Particularly item #2 where it says
The DPC is automatically downloaded to the device and launched.
How?
Specifically, what is the trigger that launches the DPC after download while still in the context of the startup wizard? I'm asking because it isn't working for me.
I've got Corporate-Owned Single Use (COSU) application, but I'm getting tripped up on deployment -- specifically the part where the DPC app sets itself as the device-owner. So far, I've loaded the app in Google Play Store as a private application. G-Suite exists in the same domain and Google is registered as the EMM for the account. The COSU app is whitelisted and installs as part of the setup wizard... but it doesn't launch.
To the best of my understanding, it has to launch within the context of factory-reset so that I can reset the device owner to the downloaded app.
Is there a specific Activity or BroadcastIntent I should be looking for? I'm new to Android, so I've been pouring through the TestDPC code, Android docs, and SO posts, but this deployment thing is a pain.
As a secondary query. How would you debug this situation? Its all factory-reset and install by wire, I don't have the opportunity to turn on developer mode and watch logs through Android Studio as it happens. And pushing new builds to Google Play and resetting hardware to download and install has a very long cycle time.
Thanks in Advance
For your DPC to be downloaded and launched after an account is added you need to register as your own EMM along with your DPC, and enroll your G-Suite domain with this EMM.
It might be simpler for you to instead use Google's new Android Management API which doesn't require implementing a DPC or registering as an EMM.
My mobile app on both Android and iOS uses Cordova’s InAppBrowser plugin to allow users’ to authenticate using Google OAuth2. As I understand, Google will be removing that capability in a few months in order to support making it easier for users to sign in using existing session from the system browser.
The issue we have is that our app's sign in process actually needs to not use any existing session credentials. Our app is an employee time clock that may be used on a shared mobile device (e.g., kiosk). Normally employees clock IN and OUT of work using an employee pin, but an administrator may sign into a special administrator mode to do things like set up a new time clock or access privileged functions. We rely on the administrator having to enter fresh credentials each time. We don’t want any existing session to remain around as the device is not considered safe for that. I hope that make sense.
It looks like Google's sign-in SDK for both Android and iOS have a way to disconnect users, which I assume means the session will be locally removed. However, Google sign-in is not central enough to our business that we want to have to integrate and take on the burden of maintaining two native SDK's for it.
Is there any way that Google can whitelist our OAuth key to continue to use the existing in-app auth as our use-case does not fit into Google’s primary objective for this change?
I have around three to four enterprise mobile applications targeted for employees of an organization. We would like to implement something like SSO, where you login with any of the applications, the other applications need not login. Also when you logout in any of the application the same has to be reflected in other applications as well.
I tried googling on this, I'm sure on which is the best approach for implementing the same.
Content Provider:
Using content provider, we have to make one of the applications as master which gives us the data needed to other applications. But here raises a query on what will happen if the master application is uninstalled?
Shared Preferences:
I also noted that applications can access other apps Shared Preferences, by defining userid for applications. But again here we use the concept of master which has the same flaw of application getting uninstalled, or what if the no of applications grows.
Isnt there a common repository there all the applications from the same developer can share, and repository will be available till the last application of the developer is uninstalled. Am I missing something here?
I was also looking for SDKs which does the SSO for mobile apps like Layer7 . Has anyone worked on any such SDKs? Any suggestions?
Thanks.
Another option would be to go with Centrify SDK solution for ios and Android - http://developers.centrify.com, which provides authentication & SSO via its Centrify application on the device similar to "FB login" style. You install Centrify application from any of the app stores (Google Play or Apple Appstore), and then use Centrify SDKs to integrate your apps for authentication via Centrify app. With this solution, you can claim Active Directory support into your enterprise application and add-on bonus is SSO for all of them.
Centrify App, Centrify SDKs are FREE.
Disclaimer: I work for Centrify.