Just so there’s no confusion: The same issue that has been preventing APK downloaders from logging in to Play lately also affects DummyDroid. I didn’t have the time to port the fix over from Raccoon, yet.
The unfortunate thing about DummyDroid is that it’s codebase is about as horrible as it’s usability. So it’s probably the right time now to finally start with that long since overdue rewrite of the application.
What you can do in the meantime:
- Start Raccoon
- From the menubar, select Help|Unlock features
- Complete the checkout process.
Yes, pummeling me with your wallet actually is the way to get me to work for you.
As probably everyone has noticed by now, pretty much all APK downloaders (not just Raccoon) have been started to fail lately. I don’t want to go into the technical details, but the reason for this is a recent change by Google to how apps have to log in to Play.
Figuring out how the “secret handshake” must be done now took me about one rather stressful week. Android, under the hood, simply isn’t pretty or easy to debug.
I’d like to thank everyone who decided to fund research and development of the Raccoon by buying a premium key. I’d also like to encourage everyone, who hasn’t done so far (the majority of users) to reconsider and upgrade as well.
Let me make one thing perfectly clear: Android is a moving target. This isn’t the first time, Google breaks Raccoon. It won’t be the last time either. However, my ability to fix things in a timely manner is limited by what is economically feasible. Making and distributing a software, such as Raccoon, is anything but trivial and it can only be done with the financial backup of paying customers. Even if you only need the basic features, buying premium is money well spent.
PS: Yes, I know, Paypal isn’t an option for everyone. In fact, I was working on adding credit card payment and bank wire transfer when Google decided to break things.
Still in the middle of figuring out how exactly Google wants things to be done now. Seems like the issue is bigger than I originally thought. (Re)Discovered a curious tidbit, though, which I’ll have to look into, once I have everything up and running again. In FDFE urls, the following two url parameters are supported:
I think, the idea here is that if you are, let’s say a japanese user on vacation in some other part of the world, you should still be able to download apps only available in Japan.
Well, anyway, that just came up while digging around. Not important now. I just don’t want to forget it (again).
I’m getting a lot of email at the moment about Raccoon suddenly being unable to log into Play, so instead of answering them individually, I’ll just address the issue here.
What happened? Well, in a nutshell, the same thing that always happens once or twice a year: Google got it in their head that something must be done differently from now on and everyone is screwed. More concretely, they changed the way in which clients must request their Auth token (put simply: a cookie that is used instead of username and password). Clients already having a token (being authenticated) are not (yet) affected. That is, if you set up Raccoon before around a week or so, everything is peachy (for the moment). Just don’t change your password/account settings, or you won’t be able to log in again.
So far, I have spent the better half on the weekend on the issue (thanks Google, did you really have to pull this off during the pentecostal holiday?), a fairly good idea what’s broken and a also halfway working solution. I still have to do additional research (hope, everyone else is having a fine holiday) and then spend a day or so on making a clean implementation.
In the meantime, here’s what you can do:
- From the menubar, select Help|Unlock features
- Complete the checkout process
- Wait for Raccoon 4.1.1 to be released
Wait! Whoah! What? Why spent money on something that’s broken?!
Look at it this way: you are not spending money on something that is broken, you are spending money on getting it fixed (over the holidays – did I already mention Pentecost, by the way?) Think of it as Kickstarter, with the difference being that I have been doing this for about 4 years now and have always delivered so far!
Back in the v3 days, I used to have this idiot discussion about handling passwords every other week. Some weisenheimer would notice that Raccoon only prompts for a password during setup. Then, dug through the config file, just to find the password stored there in plain text. Five minutes later, an angry email would hit my inbox, explaining to me that passwords are sensitive information and therefore must be encrypted before storing them on disk. Read more ›
I’m torn on implementing this feature. Raccoon v3 had it, it was pretty popular with power users. It was suppose to be reintroduced in Raccoon v4.1 (Google’s latest protocol changes forced an early release), but I don’t really want to do it.
The problem with the commandline is it being a quick and dirty way to implement features for power users: fairly isolated code and almost no UI bloat. Takes a fraction of the time you’d have to spend on creating a dialog window and you always end up regret doing it afterwards because eventually regular users will want to use the feature, too and then you have to explain to them how to use the commandline. You initially save time on coding, then waste it all again on email support.
The next problem with adding a commandline mode is that Raccoon v3 kept everything in the filesystem, so running multiple instances of the software wasn’t an issue. With v4, however, it is, since all meta data is now kept in an embedded SQL database, which can only be opened by one process at a time.
The choice here is either running the database as a background daemon for multiplexing access or risking that GUI and a CLI instances will block each other. Neither is particularly appealing! Both will be a cause of later regret.
The solution I currently fancy is to temporarily implement a command line switch for updating apps that will be deprecated from the beginning and have “here be dragons” as its sole description. Then eventually have Raccoon run as a servlet as well as a desktop application (see TradeTrax for an example).
Just had a rather long email exchange concerning a particularly elusive app and it ended with a facepalm moment (as in: why didn’t I think of that?). Read more ›
Dratz! I wanted to release Raccoon v4.1 this week. But unfortunately it looks like Google changed the data format, used to communicate search results between server and client (again). In consequence, Raccoon will, for some queries, get confused and not show a list of apps, but only four buttons that seem to still be loading data. I’m afraid, that’s a showstopper.
What happened? As far as I can tell so far, Play got “smarter”. In the past, a search request would simply return a single list of apps that matched the search term(s). This is still the case for “general” queries, but when Play determines that you are looking for a specific app, you get four lists instead (hence Raccoon shows four buttons). The first one consists of just one entry: the app you were (likely) looking for. The second list contains apps, Google would like you to try as well, the third contains apps similar to the one you were looking for and the fourth is just “everything else that seems to match”.
As far as usability goes, this is a major improvement. Play is overflowing with apps from developers trying to get discovered by riding the backwash of popular apps. And it certainly looks like Google is now finally making an effort to bring down the hammer on the knock-offs. The downside, of course, is that third party APK downloaders and older versions of the official Play app will stop working properly. As far as Raccoon goes, this is only a temporary issue. I look into these things, I fix them. And just so there’s no confusion: this is why you actually want to pay for premium features, even if you don’t need them. Your money allows me to keep the software, you are using, functional.
Oh yes, workaround for the issue (till v4.1 arrives): you have to generalize your search queries. If, for example, you are looking for “Firefox”, Play will (rightfully) assume that you want to download Mozilla’s web browser. Try searching for “web browser” instead and you’ll get a list of all available browsers, including “Firefox”.
With Android O, we are well into the second half of the alphabet (no pun intended) and the Android packagemanager still requires apps to be signed. Why exactly?! Read more ›
There are tons of reasons, why Raccoon might not find an app (or produce any search results to begin with). Today, I learned of a new one: user tried to mimic a Gingerbread device (I’m not happy with little “details” like this one being kept back till the 10. email!).
I’m not quite sure what to say here, except the following:
- Raccoon allows you to experiment. That’s the whole premise. However, if you choose to do something outlandish and it doesn’t work, don’t come running to me. At least not without telling me precisely what you did! You are not the only one sending me support mails and I simply don’t have the time (or the nerve) to drag it out of you in hour long email conversations!
- Google changed the wire protocol somewhere between Android 2.x and 4.x. Given that Gingerbread is a dying breed, Raccoon only supports the newer format. If you use DummyDroid to obtain a GSF ID for an ancient phone, you simply won’t see any search results. Play then switches to compatibility mode and sends data, Raccoon can’t make heads or tail out of.
- An Android app can specify the minimum and the maximum OS version, it will run on. Only the first one is required, though and since Android tries to stay backwards compatible at all costs (usually the cost of all sanity), most app developers keep it open ended. That is, if an app was written in the Gingerbread days, it can very likely be downloaded with a Nougat profile as well.
Considering the last two points, I won’t add Android v2.x support to Raccoon. That train has left!