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
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.
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
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!
Adding additional functionality to various hardware and software buttons on our devices is something Android enthusiasts have been doing for a while. Most people know about applications such as Button Mapper from XDA Recognized Developer flar2, and we even spoke about other remapper solutions back when the Galaxy S8 was released. While those solutions handled these actions in a certain way, Google looks to be implementing a listener in Android Oreo for long-pressing the volume keys. This means that potentially, applications in the future might be able to react to volume key long presses even while the screen is off, which could be used to bring an often-requested feature over from custom ROMs – music track control with volume key presses.
We do want to mention that this feature isn’t actually enabled in the user-facing build that we have available to us right now. Support for it is there though, as evidenced by the commit we found, and that means it can be enabled by the OEM for your specific device. As mentioned, traditional remapping applications work by detecting if a KeyEvent has been sent (even with long-presses and double presses), but these are only sent while the screen is on and also typically require the use of an Accessibility Service which can be taxing on the performance.
Your typical button remap solution can be considered to be a workaround to be used to toggle the torch on or off, opening an application, pulling down the notification panel and so on. However, what Google has implemented into Android Oreo takes this a step further with letting system applications themselves set up these volume button long-press listeners. This could allow the user to trigger something within the application itself once the platform detects a volume button has been held down for a few seconds.
The way Google has included support for this in Android Oreo, this will only work for “privileged” (aka pre-installed system) applications out of the box. The OEM just needs to allow the privileged application to have the android.permission.SET_VOLUME_KEY_LONG_PRESS_LISTENER permission in order to set the listener. However, we’ve been able to grant permissions like these with ADB commands so it’s possible that those of us in the know could manually set this for a 3rd-party applications too.