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!

HMD Global is Rumored to Release a “Customized” Nokia 8 in the US and China

Similar to HTC, a lot of people in the smartphone (and even cellular phones before that) have a soft spot for Nokia. They had some popular devices before smartphones came into existence and many were happy with the Lumia devices thanks to the impressive camera performance and good hardware-price ratios. So when HMD Global began licensing the Nokia name and releasing smartphones, it naturally got a lot of people excited. The company slowly started building up a portfolio and recently launched their flagship, the Nokia 8.

After the launch though, there were still some questions left that needed to be answered. The biggest one we saw was about where the company had plans to launch the device. The Nokia 6 received a release in the United States, so many had hoped the flagship would as well. However, a preview article about the device from CNET said HMD Global didn’t have any plans to bring this device to countries like the United States or Australia.

While it may be true that the company isn’t working to bring this specific version of the device to the United States, a new rumor brings up a different point. Sources close to Nokia Power User claim that HMD Global is working on building a customized version of the Nokia 8 for the United States and China markets. The report cites sources “with knowledge of HMD’s plans,” but doesn’t have any additional details regarding pricing, release date or specs of the US variant. Given the countries the variant supposedly targets, this variant might require CDMA band certification for US carriers, for example.

They did look at the way HMD Global handled the Chinese release of the Nokia 6 as a possible way the company could approach new markets. HMD Global released the Nokia 6 in China 6 months later and gave it a bump in RAM. So it’s rumored that they will be doing the same for the Chinese variant of the Nokia 8 as well (especially since China seems to be an important market for them). This doesn’t mean the US release of the Nokia 8 will get the same treatment though, so we’ll have to wait and see what the company has in store.


Source: Nokia Power User

Android Oreo Greatly Reduced Lock Screen Unlocking Latency

What people may perceive we can call “jank” or lag on an Android device can be explained in various ways. While most people focus on the smoothness and speed of a device when describing real-world performance, large delays and latency issues when performing animations can also produce visual annoyances and jarring breaks in responsiveness that contribute to our perception of a device’s lack of fluidity. The lock screen latency we (might) perceive when we unlock an Android device, for example, can make unlocking your phone quite jarring — but it should be going away with Android Oreo.

According to a new commit in AOSP, recent changes have caused this issue for a couple of different reasons. The commit author says that when we go from the lock screen to an application, Android now has to create a full starting window containing the snapshot. Before those recent changes were implemented, the Android OS was just showing a surface.

Also, when going from the lock screen to the home screen, Android can’t use the saved surface anymore (because it currently doesn’t support snapshotting translucent activities). The commit also mentions that in the long run, they want the home screen to be more involved into transitions. This means the operating system will have to wait for the first frame draw anyway. Googler Jorim Jaggi added additional latency in this transition 3 years ago, stating that he didn’t understand how to read systraces with binders involved at the time, though he rightly blamed that there was no available binder tracing then.

Now, though, they’ve been able to completely fix the latencies that all of the above introduced. By removing the wasteful 100ms latency, and they’ve made unlocking 30ms to 70ms better than before. The commit does warn that this requires “a lot more discipline” in SystemUI; the callback to dismiss Keyguard  (portion that handles lockscreen unlocking) takes around 30ms, but by moving all non-essential binder calls they’ve managed to bring it down to just 5ms, allowing the window animation and Keyguard animation to start at about the same time.

Bixby Voice is Now Available in Over 200 Countries

Samsung’s virtual assistant hasn’t had the smoothest launch since the Galaxy S8 and S8+ were made available to the public. In fact, we first heard that Bixby Voice wouldn’t be available outside of Korea before the device was even released. Reports then pointed to a June release date for the United States but it wasn’t until July until the feature was officially launched. After a rocky launch though, it now looks like Samsung has been able to bring the feature to more than 200 countries worldwide.

Availability hasn’t been the only criticism that Samsung’s new virtual assistant has received. Granted, a delayed release date along with fierce competition has been a big reason why some people lost interest in the platform. Some people just feel Bixby is incomplete and duplicates a lot of other virtual assistant features that have been widely available on Android for years. Although some do like how deeply Bixby has been integrated into Samsung’s first-party applications.

After all of this work and effort, Samsung has been able to tackle one major issue the feature has had – availability. This week the company announced Bixby Voice capabilities are now available in more than 200 countries and territories worldwide. To use the feature right now though, you will need to own a Samsung Galaxy S8 or the Galaxy S8+. Samsung does say it’s working on expanding the availability of Bixby, and like other Samsung services we can expect it to arrive to lower-end devices in some (perhaps diluted) form.

Not only are they working on bringing the feature to even more countries, but they also mention additional languages, devices, features and third-party applications. It will be interesting to see if they can (or want to) release Bixby for older and non-flagship devices as that could really expand its reach. It also makes sense to hear that they want to integrate these voice commands into more 3rd-party applications too, so they are likely trying to work with some of the more popular applications on the market.


Source: Samsung Newsroom

Android Oreo Source Code Uploaded to AOSP by Google

It’s been a big week for the Android community as Google has officially announced the name of its brand new update. Android 8.0 Oreo is something that many people didn’t think they would hear even though a lot of people hoped they would. The system images for Android Oreo are already available so you can download them for your supported Nexus or Pixel device right now and manually flash it to your device. We’ve also noticed that Google has uploaded the Android Oreo source code last night to AOSP as well.

Many of us Android enthusiasts know exactly what that means too. Custom ROMs based on Android Oreo source code will be on the way, at least for those devices that already officially support it such as the Google Nexus or Pixel devices. There are a number of custom ROMs for a plethora of devices out there that are built upon Google’s AOSP code base. When a new update comes out and the source code is released, we generally see some vanilla AOSP builds created for some of our more popular devices here on XDA, though they’re usually quite buggy at first.

We will then see some of the more popular custom ROMs available (such as LineageOS, SlimROMs, Paranoid Android, etc.) merge this code into theirs. However, the amount of time this takes will vary from custom ROM to custom ROM. Some projects have bigger teams than others and this generally results in slower releases for those Android Oreo based custom ROMs. There are also some teams which want to put the new builds through extensive bug testing too and that adds some time onto it as well.

So please, do not hassle or harass your favorite custom ROM maintainers for an ETA on when the new build will come out. They will get to it when they can in some cases it isn’t something we should expect in the first place. These hard working community developers don’t get paid for their work and most have a job, family and other responsibilities they need to take care of first before they can put time toward a custom ROM.

Developers can check out the source code drop at Google’s AOSP repository under the branches Android-8.0.0_r1, Android-8.0.0_r2, Android-8.0.0_r3, and Android-8.0.0_r4. We’ve been digging through the source code since it was dropped and will update our readers on anything interesting that we find. Check out XDA Labs to keep up with all of the latest news!