Google made a lot of interesting changes in its Quick Settings and Notifications drawer in Android Lollipop. One of these is the addition of dynamic toggles that don't clutter the drawer for everyone, but only appear once a user activates the corresponding option from Settings. This applies for example to the Hostpot and Invert Colors toggles. The problem is that once these toggles attach to your Quick Settings, there doesn't seem to be a way to make them go away, even when you switch the action back off.
Ever since the beginning, Android OTA updates have worked by patching each file on your system partition individually. With Lollipop, that is all changing, and it has some important implications for those who like to root and mod their devices.
Here's what a pre-Lollipop update script looked like:
As shown, the recovery looks at this, finds each file, checks its signature, then applies a patch to it if it matches. This is the slow way of doing things, but it had a big benefit for rooters and those who like to mod their devices.
A fair number of you have probably used the ridiculously simple (and bizarre) workaround to get Okay Google Everywhere working on your device without waiting for Google, but there's a catch. If you turn on the lock screen functionality, it makes your phone a little less secure.
We've already started receiving a ton of emails from concerned readers about L's app compatibility issues, broken functionality, and the like. Of course, we understand how frustrating this can be, but that's actually the point of the developer release.
One of the primary purposes behind Google releasing L for the Nexus 5 and 7 is so developers can get their apps updated before the stable version rolls out, as the switch from Dalvik to ART requires apps to be updated to add support for the latter.
Feedly has been one of the most popular feed readers in the wake of the Google Reader shutdown, but the service is having a rough morning. A distributed denial of service (DDoS) attack was launched on Feedly late last night and has continued all morning. According to the Feedly blog, the company is working to mitigate the impact and bring Feedly back online, but it's slow going.
Update 1:Feedly says the attack was neutralized as of 3:07PM PT.
In some emergency situations it might not be practical or possible to make a voice call to 911, but starting today, you might have another option. It took a bit of wrangling with wireless carriers, but the FCC's deadline for having the necessary wireless infrastructure in place is today. That doesn't mean everyone will be able to text 911 yet, but the pieces are in place.
The Chromecast is slowly worming its way into every part of the Google ecosystem, but there is at least one aspect you weren't supposed to see yet. There is incomplete screen casting support built into KitKat, but it has been surfacing in very odd ways for the last few months. Rest assured, you are not alone in spotting it. Update7/9/14: It's live now
Update [2/12]: It looks like the glitch is over with. Several people are reporting that downloads are working again and everything has returned to normal.
If you've been having trouble with 403 errors while attempting to download new or updated versions of apps from the Play Store, welcome to the club. Reports have been popping up all over the Internet from people experiencing the same issue. Unlike the infamous Package File Invalid Error, the glitch appears to be persistent, preventing any and all downloads from starting.
Now that a KitKat build for the Galaxy Note 3 has leaked, people have started reporting new things that they're finding. Though most of the major features of Google's latest Android version are present, the "tap and pay" option is conspicuously absent. Further, it appears host card emulation has been disabled altogether. This is curious given the fact that Isis Mobile Wallet, which is partially backed by AT&T and nowhere to be found on the official Android 4.3 builds, is preinstalled on the leaked firmware.
As a follow up to our recent PSA on bootloader quirks with GPE devices, we thought it would be a good idea to shed some light on a bootloader anomaly which affects both Nexus and GPE devices. Recently, there have been changes to the way unlocking happens behind the scenes. These changes can result in a device that infinitely boots into recovery.
Traditionally, when you decide to unlock and flash a custom recovery, the procedure goes something like this:
You type "fastboot oem unlock" from the command line.