Ok, there’s a lot of confusing information out there now, concerning Google’s latest walled garden antics. It’s not directly a problem for Raccoon (Raccoon, with the help of DummyDroid, can fake any desired device), but it might be for people who want to use apps that depend in one way or another on the presence of Gapps, so … meh. I should probably try to figure something out, though personally I’d say: just be glad if Google locks you out of their spyware themselves (normally, you have to put quite a bit of effort into getting rid of it). The current Facebook scandal should be a wake up call and Google is much, much worse!
Anyway, collection of loose thoughts on the issue to follow.
As a custom ROM user (for that point and purpose, every non certified device runs a custom ROM), you can register your device and continue to use Gapps. Supposedly, you can register up to 100 devices, which isn’t much.
You have to register with your GSF ID, not your Android ID or your IMEI (tablets don’t always have an IMEI). This is important to note, since Android ID and GSF ID are often used synonymous, even though they are are completely different things! The Android ID was Google’s first (and failed) attempt to bake a unique identifier directly into the OS. It didn’t work out because devices chose their ID randomly and users could change it (some custom ROMs hardwired it to zero for privacy reasons). The GSF ID is the successor of the Android ID, it is generated server side when you first log an account in on an Android device.
A lesser known fact about the GSF ID is that it can (and does) time out. It’s more of a session cookie than a serial number. This shines a new light on those 100 registrations you are allowed per account! Google probably means that you may register up to 100 devices simultaneously (which is plenty, even if you flash custom ROMs on a daily basis). Once you stop using a GSF ID for a prolonged time (a couple of months as far as I know), the slot get automatically freed again.
It’s a bit weird that you need to register a device by it’s GSF ID in order to log in, because you actually need to already be locked in in order to request a new GSF ID from the server. Technically it works like this: you first ask the account service for an auth token (think of it as a session cookie) by presenting it with your credentials (google account + password). Then you ask the checkin service to issue you a new GSF ID by presenting it with an outrageously elaborate description of your device (mainly based on your build.prop). Finally, you have to claim the GSF ID by echoing it to the checkin service along with your auth cookie.
My best guess currently is, that uploading a build.prop file from an uncertified device gets you a “tainted” GSF ID (probably claimed). Google likely looks at the “ro.fingerprint” key and matches it against a whitelist of certified vendors. My speculation here is that newer versions of Gapps attempt to verify the GSF ID and log you out again if they find it tainted. I believe it to be implemented this way since the alert screen you get obviously is a native activity and the one thing, Google doesn’t want to do is break backwards compatibility.
So, where does that leave us? First of all, don’t worry about running out of registration slots. You’ll likely not hit that limit and that pretty much means, we probably don’t need a bypass hack. If we did, there’s one already: Dummydroid can be used to create a GSF ID for an arbitrary (certified) device. That doesn’t get the GSF ID into your phone, but if you can log that GSF ID in with Raccoon (and download apps), you know what a working setup looks like. All you have to do then is to modify your build.prop to spoof a legal device.
