A bit of research on the GSF ID and the elusive DF-DFERH-01 error

Huh, just discovered a couple of things about the GSF ID.

When downloading apps from the play store, the normal flow is as follows:

Make a details call to get the latest version code for the app in question (optional - you can skip this if you already know it).
Use package name and versioncode to purchase (this is a misnomer, free apps must be purchased as well) the app. This will bind it to your account.
Make a delivery call to get the download parameters.

All three calls are simple HTTP GET and HTTP POST requests, but they require a non-standard X-DFE-Device-Id header with the hex encoded GSF ID. So far, nothing new, but I experimented a bit with the header today:

Leaving it out entirely
Setting it to 0 (the “invalid” value)
Setting it to 1 (a “random” value)

As expected, the details call failed with a HTTP 400 and a DF-DFERH-01 error. Curiously, the purchase call failed with DF-RH-03 when leaving the GSF ID out entirely, RH-01 (no “DF-” prefix!), when setting it to 0 and went through normally with the random value.

Seems like the there’s a validation check behind all endpoints that requires the GSF ID to be present and valid, but not all endpoints make use of it. It makes perfect sense, that details needs it. After all, the hardware profile is bound to it and without that, Play couldn’t do an app compatibility check. What fascinates me though, is the behavior of purchase. In particular, that it requires a GSF ID, but not a valid one (not too surprising, apps are bound to the accounts, not devices) and that I can get a RH-x error with and without a DF- prefix. Looks like “DF” is some kind of a subsystem and DFERH is actually DFE_RH…