Adding a new user to Android when you (accidentally) removed the stock keyboard

Not sure how to phrase that, really… It’s sort of a corner-case of corner-cases…

It’s when you’ve slimmed down your bloated stock ROM by removing a bunch of pre-installed crap, and suddenly found yourself unable to complete adding a new user to your tablet because you uninstalled the stock ROM keyboard.

In my case, I removed the Samsung keyboard from my Tab S, opting for Swiftkey and Hacker’s Keyboard instead. All is fair and well in sano-land, but adding a new user found me looking in vain for some way to enter my Google apps credentials when setting up that user.

Hm.

The “fix” I found to work — and your mileage may very well vary — was to use ROM Toolbox Pro in my working account to change Swiftkey to a System App, then try logging in again as the new user (in vain), then logging back in with the functional user, and reverting what I just did, making Swiftkey a user app again. Go figure, on the next try to log in as the new user, Swiftkey appeared to let me set up that user, and all was well in every-land.

As I said, YMMV.

The Simpsons: Tapped Out load screen

Fixing the zoom level in The Simpsons: Tapped Out on Android (needs root)

Thought I’d share this. I have a 1280×720 tablet which runs TSTO with a really nice, wide viewport. That is, I can zoom far out and see a lot of stuff.

On my Note 3 phone, though, which has a 1920×1080 screen, I can hardly zoom out at all. When Arnie flies by in his helicopter, he takes up pretty much all of the screen space (which in itself is extremely annoying).

I guess a lot of us have been trying to use App Settings from the Xposed Framework, setting resolutions, DPIs and font scales, only to see everything remain exactly the same, except for dialog windows which would be ridiculously small.

Perhaps you also tried installing the TabletMetrics plugin for Xposed or did some build.prop hacking, and neither helped.

Today I accidentally stumbled across something interesting. I actually wasn’t even trying to fix the zoom level, I was just fed up with the performance of the latest Easter update, which is even worse than in the previous version. The experience is super laggy when I try to pan across areas in Springfield where I have a lot of buildings and decorations back-to-back.

So I thought I’d try to lower the resolution on my device to hopefully get better performance. I used a terminal emulator for this (you have to be root to change the resolution), but there are probably apps in the store for this — again, you need a rooted device. If you do use the terminal, this is the command (become root first by typing “su” and then enter):

That one will change the resolution to 1080p full HD. The first number is the horizontal resolution, the second one the vertical one. Since this is a phone, they are inverted, as the screen is held in that orientation ;) By the way, that line above isn’t the fix in itself, so read on.

So anyway, I noticed that if I set the resolution to 720×1280, the same as the native resolution of my tablet, the next time I started TSTO, it would download updates. And not just a few, a LOT, like 250 MB. And once it started, the UI elements were smaller and the viewport definitely larger (that is, showing me more of Springfield, and letting me zoom out more).

I then tried lowering the resolution even more, to quarter-HD, or 540×960, and again TSTO would download updates (this time a smaller amount, though), but this time the effect on the gameplay was the reverse. That is, smaller viewport, less visible Springfield.

Puzzled, I then tried going in the other direction, aiming for something in-between full HD (1080p) and half HD (720p). I tried 900×1600 and once more got updates downloaded on launch, and an even bigger viewport than with 720p.

For the heck of it, I switched back to native full HD resolution and launched TSTO again. Again updates to download, and this time it was the massive 666 MB one that I’m used to seeing when installing from scratch.

It started to make sense. It seems the app downloads the textures and objects it deems appropriate for the current device, based on its resolution. So, for a full HD display, you get very high-res graphics, or putting it another way, very large graphics. That’s why we can’t zoom out properly (speaking in terms of pixels, we’re already zoomed out very widely), and also why the performance can be pretty darn sucky.

But when we trigger TSTO to download smaller textures and graphics (my uneducated guess based on the difference in attainable zoom level would be that they’re one fourth the size of the high-res ones), the same zoom level in terms of pixels would be several times wider when using these smaller graphics.

So, what triggers TSTO to do this? Well, I was thinking I’d just try decreasing the resolution incrementally in steps of 18 by 32 (2 * 9:16) on each axis and see which resolutions would trigger new graphics downloads. And here are the results (not sure there aren’t any more switches between 0x0 and 756×1344, but at least with 540×960 it’s the same, so test for yourself if you want to find out ;) ):

So, basically, the sweet spot if you want max zoom is to use the highest resolution that’s the closest to the native resolution of your device. That is, for a 1080p device like mine, go for 954×1696. I can tell you, it’s awesome!

DPI settings, font scaling, none of that matters. It’s all about the actual resolution when you launch TSTO.

Andy Richter Controls the Universe — The DVD Release Cropped to Widescreen

Doesn’t it just feel awesome when you buy a DVD or BluRay in widescreen, hoping to see more of what you’ve already seen, only to find that the thing has been cropped to 16:9, rather than restored from some possible never-before-seen 16:9 original?

Sure does! And that’s what happened to me with Andy Richter Controls the Universe — The Complete Series on DVD. Had I taken the time to read the reviews properly, I’d known.

Seems my old TV rips will have to remain my primary Andy Richter resource. Check out what we’re missing (these snaps are from the pilot episode):

Original TV broadcast in 4:3 format (left) vs. DVD release, cropped to 16:9 (right)

Original TV broadcast in 4:3 format (left) vs. DVD release, cropped to 16:9 (right)

Getting Something Like a Global PATH in Mac OS X

Mac OS X has its virtues. I hate pretty much every OS out there, but among the three that I use daily (Linux, OS X, and Windows), it’s not the one that I hate the most.

It does need its fair bit of fiddling to get to behave, though. Usually, it’s about getting general the UI and HIDs to behave like normal people would expect them to, but this evening I found myself having trouble with something entirely different. The $PATH in Mac OS X.

I was installing the OW LESS editor in Eclipse Indigo, and found that Eclipse couldn’t find my node binary (which is in /usr/local/bin on Mac OS X by default). I just kept getting an “env: node: No such file or directory” error when I tried to compile a .less file into a .css file.

This puzzled me, as it’s most definitely in my path. And not just in my path as set up in ~/.bashrc, but in the system-wide path as defined in /etc/paths. I could do “open /Applications/eclipse/Eclipse.app/” from iTerm and Eclipse would fire up with a proper PATH. It would actually use my path, including local stuff I have in ~/.scripts and ~/.apps.

Using Spotlight to launch it, however, would leave me with an Eclipse stranded on an island with no paths anywhere. In lieu of some way to launch apps using keyboard shortcuts, I always use Spotlight to launch apps — I don’t care for the dock and use it only to force close misbehaving apps.

So I asked Google, and she told me that for GUI apps to get a PATH, they need to get it from ~/.MacOSX/environment.plist. This file doesn’t exist by default, so you have to create it using “defaults write ~/.MacOSX/environment PATH ‘path1:path2:path3:etc'”, i.e. kinda feeding the BASH $PATH into this plist. So, the quick way to feed your path to the plist would be

From a terminal, of course. Well, this is all well, except it doesn’t quite work. You have to do a reboot for it to kick in, for one, but that’s just an annoyance. The real kicker is that — get this — from the terminal, processes (e.g. apps such as Eclipse.app, if opened using the “open” command), get the proper $PATH path. From the dock, apps don’t get that $PATH, they instead get the environment.plist PATH. Which is what I was expecting. Except — apps opened using Spotlight get neither $PATH nor environment.plist.

Apple. It Just Works. Except when It’s Just Broken.

To get apps launched from Spotlight to work, too, we need to go even deeper and create yet another non-existing file, /etc/launch.d. Again, this one needs a path in the same syntax as $PATH, so the fix is straightforward,

Luckily, this doesn’t need a reboot, and we can launch Eclipse via Spotlight immediately and use the resources in our path.

I’ve create a BASH alias to do this for me,

So from now on I can just issue “path-sync” from a terminal whenever I update my PATH and have the system behave as expected. Might forget it, though, so a root crontab entry might be in place, perhaps every day at 10:00?

How to Disable Kwallet Integration in Google Chrome

So, this thing was seriously pissing me off. Every time I opened up Chrome, it’d try to open Kwallet for some annoying integration reasons. Sure, for some it’d probably be nice to use Kwallet for storing Chrome passwords, but for f**k’s sake, let me decide if that’s for me! I’m a LastPass user, not a dang-naggit Kwallet user!

So, anyway, searching for solutions doesn’t help. People mentioning google-chrome command line options like –password-store, hunting for flags or developer settings, some even suggest disabling Kwallet completely. Yeah, like that’s a good solution.

The Kwallet Manager app is of no use either. I can’t figure out what the “manage” part of that name is justified by. Basically, it’ll just list whatever apps are already “always allowed” to access the wallet, with no option to add new apps or change the rules for existing apps.

Well, luckily this is Linux, so a bit of settings file fiddling and some guesswork is usually rewarded. In this case, the solution is dead simple. Simply open up ~/.kde/share/config/kwalletrc in your favorite text editor (like Kate or nano in the konsole), and add these two lines to it:

Voila. Log out and back in, or just fire up a Konsole and do “killall -9 kwalletd”, and Chrome won’t ever bug you again.

Now to fix the annoyance of Chrome always opening up on my secondary display…