Develop Reference

Multiple Accounts suddenly added in Firebase Authentication

I'm currently developing an app which is only accessible by me for now. I can already connect to Firebase but somehow I noticed that there's alot of unknown email added. I'm expecting it to have around 4 email which I have used for testing. May I know why this happened? And will this affect my app if ever I finished developing it?
Note that I didn't share/upload any info/keys that I'm using.
I was thinking that someone might have used my info/keys mistakenly that is why this happens.

If you uploaded your App to the Play Store such accounts are created by Google while they verify your app. That is normal. You don't need to worry about it.
Also see: My Firebase project has unknown users, has my google cloud service account been compromised?

Firebase: Can decompiling the apk give access to my data and files?

If someone wanted to reverse engineer my android application by getting the apk file and then customising it to do other things that it shouldn't do. Keeping in mind that the apk file will have the google-services.json file that we download from firebase when we create the firebase project to link the android app.
The question is:
Even though there is security rules on the real time database or firebase storage that only allows authenticated users. Then the hacker can reverse engineer the app and makes his own application that has the same google-services.json file and then when compiling the hacker can create an account and login to the app (which makes him authenticated) and then maybe he can delete and write data to the real time database.
Can someone please explain how the security holds then?

In general, you should assume that any code that you ship to a customer could be compromised. You should assume that the device that they're running it on is under their full control, and that they could change the way your code executes on that device. The issue isn't so much that your app gets decompiled, it's that you simply can't control the execution environment in any way (unless of course you manufacture the device and have built in your own hardware security).
The data in google-services.json is not private data. You should assume that the moment you publish an app, everyone will know all the information in that file. Think of that data as unique identifiers that tell your app where to get data. There are no passwords or credentials in that file that allow an attacker to do anything that you have not authorized them to do.
It's up to you to use security rules in conjunction with Firebase Authentication in order to control who can do what to the data hosted in Firebase. It's impossible to stop people from creating random accounts in your app, but it's possible to restrict what they can do.
If you find that your app is subject to some form of abuse, you can shut down the abuser's account, and also contact Firebase support to report abusive behavior.

I asked myself the same situation couple of months back.
As I understand, the moment you generate your project ( Creating it from Firebase console or Android studio) it will ask for a SHA-1 key.
This SHA-1 key is unique and serves as the authorization from your project to connect to the services of Firebase, for example, if a user has your google-services.json it will be hard to them to even log in or authenticate without a SHA-1 key that allows them to use your project.
I was also inspecting the google-services.json and there is the SHA1-1 with the package names.
"android_info": {
"package_name": "com.packagename.debug",
"certificate_hash": "SHA1-KEY"
}
If you need to add a new SHA-1 you will also need to either authenticate using Gmail to go to the Firebase console and add it yourself (in which case is nearly impossible that a hacker can access to your Gmail account) or do the same thing from Android studio and sync the project.
As I said before, this is how I understand this situation, also, little research from securing API keys told that you need to be worried about client-side APIs than public APIS in your app.
The thing is that encrypting client side your APIS exposes the encryption code and can be decoded to, this is why sometimes it will be better to run some sort of a function from Firebase and send the sensible APIS to your project.
Telling it again, I'm answering with how I understand it works from having and inspecting the projects that I have, this is not an official answer so take it with tweezers.

Same account, multiple applications

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.

Android sync adapter with appengine Google user accounts

I am implementing a sync adapter for my app to sync with an appengine backend. On appengine I am using the built in User api for authentication. There is a post HERE that tells how to do it, however the app is listed under the gmail account. Ideally my app would be listed in the accounts. I don't want to ask the user for username and password, just use the existing google account for authentication. Has anyone done this before??
Update:
I've been working on this and it looks like I could implement the AuthenticationService and store the users account name and leave the password as an empty string. In the getAuthToken() methods I should be able to simple return the google auth token. Will post once I get further along...

Perhaps you have misunderstood the Android account system. When you go to Settings -> Accounts & Sync and add a new account what you see then is a list of account types. Often there is a relationship between account types and apps, for example Facebook accounts are used together with Facebook. Normally you would add a new account type if you have a different backend system for handling authentication etc.
If I understand you correctly, you use Google accounts but want it to appear as your own account type. That sounds wrong to me. You'll end up reimplementing the Google account handling, with little value. I believe it is simpler for users if you simply piggyback on what Google provides you with. Your app / service / content provider can be seen when clicking on the account. For example, after installing "Tasks" by "Team Task" (disclaimer: I'm not affiliated with that company) they add "Sync Tasks" to the list of data & sync options.
But if you really want to create your own account type, follow the sample Sample Sync Adapter. Look for the Authenticator code and related resources (e.g., manifest, activity layout, etc.).

This is indeed possible and I have implemented this with success but be warned it is a bit of a headache.
There is an excellent tutorial available called writing-an-android-sync-provider-part-1
... don't forget to check the follow up in part 2
Beyond this there is also an example in the Android SDK samples called SampleSyncAdapter which was invaluable in my development.
With a little hard work and a lot of coffee you should be able to get this working ;)

Using the android Account Manager to keep a username even if the app is deleted

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.