How to Enable Google Dialer’s New Floating Bubble Feature

Google Dialer is a modification of the AOSP dialer with a few small extra features. You can search for local phone numbers within the app and receive information on phone numbers that aren’t in your contacts. What’s more, you can also enable a secret feature! The Google Dialer floating bubble can be enabled by editing one of Google Dialer’s XML files in its shared_prefs folder. The floating bubble allows you to turn on speaker phone, mute your microphone, or hang up while you’re in another app. A video demonstration of the floating bubble is below. To follow this guide, you need root access and a root enabled file explorer. I recommend the free MiXplorer, straight from our Apps & Games forum! If you would prefer however, any other popular, root enabled options should work fine.

MiXplorer (Free, XDA Labs) →

This guide only works on rooted devices. To get root, install Magisk or SuperSU. You will also need a root enabled file explorer, as we will be editing a Google Dialer preferences file located in its own /data folder. You should also enable Google Dialer as the default phone application. If you uninstall the stock dialer that comes with your phone, this is necessary or else your phone will soft reboot when making or receiving a call.


Enabling Google Dialer’s Floating Bubble

You’ll need to download Google Dialer if you don’t have it already. You can download the latest on APKMirror. To enable it as the default calling app, go to “Settings” then “Apps” and press the settings cog at the top and tap “Phone”. Change the default phone application to the Google Dialer. It’s called “Phone” too, but the one not marked as default or system will be the one you just installed if you haven’t got any other dialer apps on your phone.

Once done, make sure your device is rooted and you have a root enabled file explorer. You’re ready to begin if so!

Step 1

Open your file explorer and navigate to /data/data/com.google.android.dialer/shared_prefs.

Here you’ll see various xml files which contain some modifiable parts of the application. Usually when you change a setting in an app, the setting gets written in some form within a file in the shared_prefs folder of the application. Google Dialer contains the string we need to edit within called “dialer_phenotype_flags.xml“, so open that up in your text editor.

Step 2

Find the boolean string titled “G_enable_return_to_call_bubble” and change the “false” to “true”. It should look like the below screenshot.

That’s all you need. Now save and force close Google Dialer. Launch it again and next time you make or receive a call and then press the home button you’ll see a phone dialer bubble! There are other features which you can enable or disable in this section too, but none that are guaranteed to work. Note that this feature may break at any time due to an update, so if an update removes the bubble you may need to change the string again. If it doesn’t exist, then it’s likely that Google removed it.


Explanation

What we are doing is fairly simple. Google Dialer reads its various preferences from the files located in /shared_prefs. One of the modifiable preferences present is the Google Dialer bubble that we enabled in this tutorial. This is a feature that Google are either currently testing or a feature that will never go live but was tested in-house. The bubble and its features work perfectly fine with no instability, so we expect to see this feature within the app publicly at some stage in the future. We’ll let you know if we find any other secret features!

How to Customize Lockscreen Shortcuts in Android Oreo Without Root

Android Oreo has finally launched, and much like the navigation bar, we can also customize lockscreen shortcuts! It’s even easier than the navigation bar tutorial, as all you need is adb. With the launch of Android Oreo we are also going to look for many other tweaks that users like yourselves here at XDA can benefit from, so keep an eye on our news feed.

A bit of context is needed here. Lockscreen shortcuts are those small icons in the bottom left and right hand corner that you can access from the keyguard when you wake up the phone. You were previously able to customize them starting with the Android O Developer Previews, but in DP3 they removed this option. Still, it’s possible to manually customize the lockscreen shortcuts because Google only removed the user-facing GUI for it rather than completely taking out the feature.

To get adb, install either “Minimal ADB & Fastboot” or the official binaries by Google and enable USB debugging. To enable USB debugging open settings, go to “About”, tap “Build number” seven times and press the back key. You will now see a “Developer options” menu that you can enter and enable debugging in.

This guide requires Android Oreo which is only out on the Nexus 6P, Nexus 5X, Google Pixel, Google Pixel XL, Nexus Player and Google Pixel C. You can install the factory image now if you don’t have it already!


How to Customize Lockscreen Shortcuts in Android Oreo

The ability to edit the lockscreen shortcuts existed too in the System UI tuner, exactly like the navigation bar tweaks. In that setting, you not only could change lockscreen shortcuts to a specific application, but you also could choose an activity too. It has since been removed along with other options, with the commit message stating “they aren’t quite there yet”. Thankfully we can still do that here, but with a bit more work than the graceful solution that Google used to offer. To launch adb, hold shift + right click in the folder containing adb and make sure your phone is connected to your PC with debugging enabled. While easy to edit the shortcuts, you will need to use the following commands to edit them.

For the left side:

settings put secure sysui_keyguard_left "COMPONENT/NAME"

For the right side:

settings put secure sysui_keyguard_right "COMPONENT/NAME"

Where “COMPONENT” is the application’s package name and “NAME” is the name of the activity.

As an example, if I wanted to launch the Google Hangouts left pane by swiping from the left side, the command in adb I would input is the following.

settings put secure sysui_keyguard_left "com.google.android.talk/com.google.android.apps.hangouts.phone.BabelHomeActivity"

This works for any application and activity. To find application package names and activities, you can use Activity Launcher on the Play Store to find the name of the activity. You can play around with activities in that application and find the one you want.

Activity Launcher (Free, Google Play) →

Next, if you want to make the shortcut unlock the device you can do that too. Simply use the following commands:

settings put secure sysui_keyguard_left_unlock 0/1
settings put secure sysui_keyguard_right_unlock 0/1

Where 0 keeps the device locked when the shortcut is activated and 1 unlocks the device.


And that’s it! There isn’t much in the way of further customizing these shortcuts, but it’s a nice way to speed up launching some of your favorite apps. Play around, see what you can do and let us know!

How to Customize the Navigation Bar in Android Oreo Without Root

Android Oreo has just launched, and with it come a set of various new features, optimisations and new looks. With improvement comes new APIs, and thus more unofficial goodies that with some tinkering we can access. You can install the system image now, and what’s more you can customize the navigation bar, just like you could on the developer previews! The navigation bar modification existed even in Android Nougat hidden away in plain sight, but was made accessible to users for a while in the first two Android O Developer Previews only for it to be removed along with other tuners with the commit message stating “they aren’t quite there yet”.

Thankfully, it is still possible to edit the navigation bar just like in the developer previews (and later, Nougat)! Only the user facing menu option was removed, but it’s actually still entirely accessible if you know how to call it via adb (or can put up with using a third-party app).

This tutorial is aimed at Android Oreo users, however this method and app also works on Android Nougat. Android Oreo is only available on the Google Pixel, Pixel XL, Pixel C, Nexus 6P, Nexus 5X and Nexus Player for now.


Customize the Navigation Bar in Android Oreo

Custom Navigation Bar (Free+, Google Play) →

We recommend you install Custom Navigation Bar Tuner from the Google Play Store, as it provides a nice GUI front-end for the navigation bar customization tuner that was removed from the developer previews (and offers way more features to boot). If you don’t have root access, you’ll need to download either Minimal ADB & Fastboot or the official Google binaries to enable the required WRITE_SECURE_SETTINGS permission for the application.

To do so, you’ll need to first enable USB Debugging by going to the Developer Options menu. If you don’t see Developer Options, scroll down to “About” and tap “Build number” seven times until the “You are now a developer” toast appears. Back out and above “About” will be the “Developer options” menu. Enter this and enable USB Debugging. Launch adb from your computer by pressing shift + right click in the same folder containing your adb files, then choosing to “open command prompt here” if you’re on Windows. For Mac and Linux users, you’ll need to open terminal then cd to the directory where you downloaded the files. Follow the instructions in the app to grant the appropriate permissions.

Re-arrange the navigation buttons

You can re-arrange the navigation buttons if you prefer them in a different order. Simply enter the menu titled “Navigation bar” and enter experimental tweaks.

Other uses

There is a lot you can do with this application and the use of Tasker! Here are two examples:

The app allows full Tasker integration, so you can program them in any way you like. Try customizing your nav bar out and let us know what uses you are able to come up with!

“Shattered Trust” Paper Shows How Replacement Smartphone Components Can Carry Security Vulnerabilities

A recent paper entitled “Shattered Trust” by Omer Shwartz, Amir Cohen, Asaf Shabtai and Yossi Oren has emerged. This paper shows how a replacement touchscreen for a Nexus 6P coupled by exploiting the Synaptics S3718 touchscreen driver led to an ability to entirely control the device via kernel execution. With one simple idea and a modified replacement screen, the team behind “Shattered” took over the entire device. This paper serves as a warning to those who purchase cheap, non-OEM components for their devices.

Many of us have probably replaced a screen of a device we’ve owned at some point in our lives. I know many people who have smashed their phone, only to replace the screen and the following week smash it again. Phone screens are fragile, and according to a study from Motorola in 2015, referenced by the paper, about 50% of all smartphone users have at some stage broken their screen.


The importance of OEM replacement parts

It’s important to buy OEM parts, and not just because they’re authentic and guaranteed to work. With OEM parts, you’re receiving the same hardware that would have been built into another phone of the same model and sold in an official store. Buying fake replacement parts runs the risk of failure and thus wasted money. However, there’s another risk that many do not account for, and that is the part being a vector of attack against your device.

As can be seen in the YouTube playlist above, multiple attacks target the device through the replacement screen and execute malicious tasks designed to steal the data of the user or invade their privacy. The device not only can execute touch screen tasks, but can also exploit the touch screen driver, gain elevated privileges and replace links with phishing links, log things the user does etc. This is just a proof of concept, but a very well made proof of concept which demonstrates just how simple it is with one non-OEM replacement component to attack a user without them even knowing.


How it works

The team behind Shattered targeted the driver operating the Synaptics S3718 touchscreen inside the device. This driver is launched as part of the kernel, and with sufficient control over the driver one can gain control over the kernel. They reverse engineered the touchscreen via source code of the driver, physical disassembly of the device and using the Saleae logic analyzer. Once they figured out how the touchscreen interacted on a kernel level with the driver, they then manipulated various vulnerabilities within the driver to gain arbitrary code execution. This method is called ROP chaining and has been used on other devices (such as the Nintendo 3DS) to gain kernel execution. ROP chaining is a common attack vector for devices as it is executing machine instruction sequences that are already in memory from the call stack, hijacking control flow. To put it simply, this is taking over already accessible functions that the driver has access to and manipulating them to move around in the memory allocated, until eventually the exploit can break free from the driver and control the kernel. This is using what’s called a “buffer overflow” to write over protected kernel memory. A buffer overflow is simply writing too much data to a parameter that it “spills out” of the memory allocated to said parameter by overriding the allocated boundaries and overwriting proximate memory locations. This sometimes allows code execution. While this is a short and general explanation, it should give you an idea of how it works.


The results

With this simple driver exploit, the team behind “Shattered” were able to

  • Enable any application to call root access
  • Disable SELinux blocking
  • Disable the buffer check allowing various other system wide exploits
  • Create a hidden exploit (a backdoor) within the kernel.

All of this was begun on an unmodified Google Nexus 6P. The device was factory reset, bootloader was locked and they took complete control over the device. A demonstrated attack method in one of the videos is shown below.

An attack method


Other devices

Those behind “Shattered” decided to then try the Samsung Galaxy S5, LG Nexus 5x and LG
Nexus 5. All were susceptible to the vulnerabilities outlined above. All of these use a Synaptics touchscreen however, so changing touchscreen hardware entirely to demonstrate the scope of devices this can affect, the authors then tried the LG G Pad 7.0. This tablet uses the Atmel T641 touchscreen, yet still was found vulnerable after the same methodology to take control of the kernel and exploit vulnerabilities was applied. This demonstrates the wide range of devices that could be found to be vulnerable.


What can be done?

Firstly, most devices have a “trust zone” of applications they allow to access the kernel. As the driver in question operates the touch screen, this is within the trust zone and thus is never verified to be tampered with or not. The authors suggest the driver be verified as well. The authors of the paper also suggest a hardware-based firewall, monitoring data exchanged between the hardware and the device and blocking any attempts at an attack. They note that its simplicity means it can be implemented a lot quicker than researching cryptographic verification. Check out the page down below, the full paper is located on the page!


Shattered

After Tons of Teasing, Google Trolling and Much Debate, Android O was Indeed Android Oreo

When it comes to the name for the next version of Android, it is generally considered a carefully kept secret. Supposedly, very few people within the company know what it will and only a select few will be told about it ahead of time. This is generally for things like constructing the statue, creating marketing material, the easter egg, etc. However, Google has been shoving Android Oreo in our faces for close to three years now and it still created a huge debate within the community.

Google has been known to troll the Android community time and time again with all sorts of unannounced details. The company could be getting ready to launch a new smartphone and then they’ll use a prototype dummy of a device in some marketing material for an application that gets the community riled up as they debate if they just revealed the new device. Before KitKat was launched, there was a Key Lime Pie teased during a Google I/O developer session in 2013, for example. At Google I/O 2015, Dave Burke even wore an Android Wear watch that displayed Milkshake, Milk, and a few other possible desserts like… Malt Whiskey?

Over time, many of us have become accustomed to their ways and figured out how some of this stuff works. The company does have an internal codename for the next version of Android they’re working on. Back in the KitKat days it was indeed Key Lime Pie. We saw the letters KLP show up in AOPS commits from Google when referring to this next version. The same thing happened with Lollipop as we saw LMP show up in commits and that caused people to speculate 6.0 would be called Lemon Meringue Pie.

This happened again with Android 8.0 when OC, OC-MR1 and even the full word Oatmeal Cookie started showing up in Google’s documentation for Android. Each time this happens there’s a segment of the community who goes out there and claims Google has confirmed the name of the next version of Android. Then the other segment of the community has been through this time and time again and ignores those claims since they know it is virtually never the case.

Things changed this time around though as Oreo is something that has been teased since October 2014. Back when the company was hyping up the announcement of Android 5.0 Lollipop, they uploaded the video you see above. It’s an audition call so to speak and they used that to show off a number of potential names for the 5.0 update. This video shows off Lemon Meringue Pie, Ladyfingers, Lava Cake, Lemon Drop, and even an Oreo.

The bit was that the Oreo wasn’t aware that this was a casting call for L and that he would have to wait 3 more years before coming back. So all the way back in 2014 we have seen Google putting the name of Android 8.0 right in front of our faces. This continued on with Google’s Senior Vice President of platforms and ecosystems (Android, Chrome, Chrome OS and Google Play) teasing Android Oreo countless times on his Twitter account.

Now we’ve had Google employees tease names of the upcoming update in the past, but they have always been wrong. This has happened from David Burke and even Google CEO Sundar Pichai himself. It was all in good fun since again, it was virtually never the names they were actually going to pick anyway. So some people looked at it and said the name was confirmed, while others had seen this before and started to assume any names they teased were essentially options that wouldn’be picked.

That’s where I was in all of this. I had seen employees teasing Android update names time and time again and just learned to ignore them because they simply would not be picked. I’m in the process of eating my own words in this case because that is exactly what happened this year with Android Oreo. XDA’s Daniel Marchena is in the same boat, while other writers within our staff are rejoicing at the fact they were correct – in a sad, irrelevant nerdy way. Google even went as far as to give out little packages of Oreos at Google I/O earlier this year (which Steven Zimmerman was lucky enough to check out) and, to me, that assuredly closed all the possible doors of it happening.

People were even pointing at the Android 8.0 developer preview Octopus easter egg as confirmation that it would be Android Oreo (with the mouth/teeth being the creme filling). So now we’ve come full circle where Google used to never use a name for Android that they had teased to putting everything back on the table again now. We assume this is working just like we saw with 4.4 KitKat where it’s a mutual partnership and that no money has been exchanged for it.

Not only does the new Android statue feature an Oreo, but it has a cape to fit the superhero trend that has been happening in Hollywood. Let’s hope the new update is as powerful as Google is hyping it up to be.


So tell us your thoughts about the name of Android 8.0 Oreo. Is this a name that you had completely written off because of all the teasers? Was it something you had been hoping for from the start? Let us know your thoughts in the comments section below.