OxygenOS is the foundation of the OnePlus 3T’s Great User Experience

OxygenOS has been OnePlus’s default and primary ROM for almost two years now, first released for the OnePlus One as a flashable zip for users to break away from the increasingly-unsupported but excellent CyanogenMod S ROMs their phone originally shipped with.

This software offering took center-stage with the OnePlus 2 back in 2015, a year full of devices we mostly remember for their flaws rather than their virtues. The OnePlus 2 itself almost encompassed all of the issues many people had with 2015 flagships — its Snapdragon 810 held it back, it removed up-and-coming features like NFC for no good reason, and then offered me-too (or me-first) hardware that wasn’t properly utilized, like the Type-C port devoid of USB 3.0 speeds or fast charging. OnePlus had a really good thing with their original “flagship killer”, but they blew it with their sequel, the punchline being the comical label of “2016 flagship killer”. The OnePlus 2 was an exercise in disappointing compromises, yet there was a short period of time through which I used that device exclusively despite having prettier, faster, and less-compromised smartphones within my reach. It was all thanks to OxygenOS, the one redeeming quality that allowed me to enjoy the OnePlus 2.

OxygenOS back then was a lot more bare-bones than it is now, with a slightly different design philosophy. Back at their originally unveiling ahead of the OnePlus 2’s launch, we learned that OnePlus wanted to create a slim and fast experience, not unlike the CyanogenMod 11S ROM their first phone shipped with. The AMAs with the software team further revealed that they were emphasizing staying close to stock, but adding tactful features that could only add to the experience. They somewhat nailed it with their first attempt, and OxygenOS was indeed extremely close to Stock Android, with relatively-fast performance on the OnePlus 2 and some features that preemptively emulated future features from the then-upcoming Marshmallow, while borrowing some custom ROM favorites as well.

The Good

In a way, custom ROMs were part of Oxygen’s DNA — by then, the OnePlus One already built a reputation among enthusiasts for being developer-friendly, and plenty of users loved the fact that they could get whatever feature or customization they wanted going on it. It was no surprise, then, that OxygenOS – a ROM that was also developed by some legacy custom ROM developers that OnePlus hired – would offer a similar feel; it really felt like a lightweight custom ROM in many ways, though with a higher degree of consumer-grade polish (granted, it still had a long way to go, as we’ll detail below).

It was with the OnePlus 3 that OxygenOS really got to shine. No longer was the lightweight ROM overburdened by faulty silicon — now it packed a faster, more-efficient Snapdragon 820 flanked by a copious 6GB of RAM and zippy UFS 2.0 storage. The OnePlus 3’s OxygenOS kept all of what made the original great, then further added to its feature set once more, in tactful and measured ways. I would go as far as saying that my initial impressions with OxygenOS on the OnePlus 3 beat those I’ve had with both any other OEM stock ROM, and even recent OxygenOS releases that haven’t matched the surprise I found while originally reviewing the device. It was a breath of fresh air, and while we see a relatively larger number of OEMs offering Stock Android ROMs today, I think OnePlus nailed it there and then. Some Nougat features, speedy responsiveness, a proper dark theme to make use of the device’s AMOLED panel, and an aesthetically-pleasing UI were all positives I loved from the get-go. Then OnePlus had to change some of that, momentarily.

The Ugly

The OnePlus 3’s Community Builds adopted a new user interface that deviated from the Stock approach of the original OxygenOS, changing colors and generally making it less attractive with worse proportions and animations in system UI elements like the notification panel, recents menu and settings. This wasn’t surprising when one considers that these changes were instrumental in the eventual merger of the OxygenOS and HydrogenOS frameworks.

The company figured out that a unified team working on a unified base with different application layers could help speed up updates, and address one of the more-criticized aspects of previous devices. The Community Builds, then, were growing pains that culminated in the (luckily short-lived) Marshmallow stock ROM for the OnePlus 3T. The concept of having community builds with various testing channels is brilliant and a great community engine, but at the time, said updates had disappointed me.

It felt like change for the sake of change, perhaps a petty compromise between Hydrogen and Oxygen

In my OnePlus 3T review, I noted I wasn’t a big fan of this new approach to software. While it didn’t deviate too much from the original OxygenOS, none of the changes felt clever or meaningful, and none improved upon the simplicity and effortlessness of the original package.

It felt like change for the sake of change, perhaps a petty compromise between HydrogenOS and OxygenOS, given both featured such disparate design philosophies. Enthusiast outcry and fan feedback ensued, and the company reversed the change with the Nougat update, which offers a Pixel-like blue for its default accent color and a more traditional user interface. It was at this point where OxygenOS not only redeemed itself, but also became my favorite flavor of Android– finally surpassing the Pixel XL’s, which I held in the highest regard.

The Bad

OxygenOS has also had (and overcame) many hurdles and criticism. Some of its more pointless features stubbornly remain in there, such as the Shelf feature which was permissible on the OnePlus 2, as it was a promise of things to come, yet is still a not worthy contender today. There have been numerous conscious decisions and unconscious mistakes, though, that temporarily opaqued the better parts of the ROM. For example, upon the release of the OnePlus 3, OxygenOS was massively underutilizing the hardware of the device. I was one of the few that called this out and proposed a solution, and OnePlus was quick to act and react to the criticism by modifying its settings and allowing for more apps to remain in the background. Still, it made us all ponder, why would they not allow their 6GB smartphone to actually offer the capabilities they proudly advertised?

Another short-lived complaint was the exclusion of an sRGB mode to balance out the saturated default calibration of OnePlus’ “Optic AMOLED” panel. The company set out to make its display stand out and went as far as giving it its own buzzword, yet it turned out to be extremely color inaccurate and saturated, and it even displayed some banding and contrast issues off the bat. AnandTech and independent reporters were quick to point this out, and OnePlus offered reviewers an OTA with a proposed fix which quickly trickled down to consumer builds. It was, once more, a quick fix, but it still begs the question: why would OnePlus advertise Optic AMOLED as a better viewing experience, when no metrics backed that up? Especially since the changes were mostly calibration, which wasn’t well-received at launch (luckily, sRGB mode ended up being surprisingly color-accurate).

And that’s not all. We also caught OnePlus cheating on benchmarks, through a code block that specifically targeted certain application packages by name, and then adjusted scaling behavior to minimize score variance. This was unacceptable and the company addressed it quickly enough, but at the same time, once more it makes us wonder: why would they? It’s not like it introduced critical gains, it’s not like the OnePlus 3 couldn’t sustain class-leading performance without artificial cheating mechanisms. We suspect that it might have been a result of the merger between the two different software teams, but that wouldn’t excuse the previously-mentioned decisions.

Nor would it excuse a plethora of decisions that raised our concerns over the phone’s security and software integrity, with some of the problems we reported like IMEI leaking being wholly within their knowledge and control. None of this can be dismissed, even if it doesn’t directly impact our forward-facing UX (the point of this article).

I do take solace in the fact that OnePlus has been addressing all of these issues, however, and listening to feedback from its forum-goers and enthusiasts from communities like XDA and reddit, as well as reviewers. We’ve actually influenced OxygenOS and prompted OnePlus to fix issues, remove non-sense or add or refine useful functionality. The company is clearly open to feedback, and while they have messed up their software support on previous devices, they seem to committed enough to the OnePlus 3 and OnePlus 3T. Which brings me to my next and final point.

One of OnePlus’ Crown Jewels

It is actually really impressive, from a customer’s perspective, to see OxygenOS evolve so much with such frequent updates and ongoing feature inclusions. It has seen near-constant improvement, though not always consistent. In this regard, OnePlus has redeemed itself from the atrocious support that its older devices received (and are still suffering). If ignoring the OnePlus X and OnePlus 2 was instrumental in achieving a better user experience on the OnePlus 3, then I am inclined to say it was a smart decision for the future of the company. Truth be told, OxygenOS has improved a lot and has adopted many, many new and useful features while cleaning up its mistakes and embracing a new personality through UI refinements. All of this wasn’t without growing pains, and it’s been a tumultuous ride at times, but when I look at the final package I can’t help but recognize the software is near-perfect for the demographic I belong to, the niche I am part of (and you probably are too), and what I personally expect from my device.

I am not the kind of person that believes Stock Android is an intrinsic good and a positive aspect of whatever phone decides to feature it, either. In fact, I find myself liking OxygenOS, and even TouchWiz for that matter, now that they are further from Stock — it just needs to be done right. The short-lived community builds pre-Nougat hadn’t done it well enough, just like Samsung’s awkward and early half-baked adoption of Material Design hadn’t done it right either. Now, both OxygenOS and TouchWiz have found their own identity and a matching UI that enables both to offer the features they need for the people they target. Not all OEM ROMs have been evolving equally in the past couple of years, and in my opinion, none have done it better than OxygenOS in the end, not even TouchWiz which I also believe has been getting a lot better.

It’s not that it’s close to Stock, but that it’s close-enough in all the right places, and that it changes what could use a better solution. It’s also not that it’s just fast, but that it’s as fast as I expect from this hardware. The features they added are ones I use frequently, such as scrolling screenshots and quick capture editing, and while they aren’t unique (Samsung, in particular, has introduced much of this way before), they are implemented rather seamlessly at no expense to the user. There are still bits and pieces to address (I, for one, would like to see more customization) but considering that this ROM was a quick patch to a rough legal problem, devised just over two years ago, OnePlus has done a very good job with OxygenOS and it makes for an exceptional daily driver.

What do you think of Oxygen OS? I want to hear your opinion as well, so sound off below!

Samsung has a long history of duplicating applications and services which are already offered by either AOSP or a proprietary service from Google. Some OEMs have chosen to embrace the fully-featured applications and services that Google offers (like we saw with the HTC 10), but then some OEMs like Samsung have chosen to be as independent from Google as possible. This actually results in a divisive debate within the community.

Some people feel this is filling up their internal storage with too many duplicated applications and services, while others enjoy it because they don’t like being tied down to Google’s ecosystem. We can’t really blame Samsung for doing this though because the more they rely on Google for these services then the more control they’re giving over (which sometimes results in less money they can potentially earn too). Samsung shut down their music service late last year (Samsung Milk Music), which is likely why they chose to go with Google Play Music this year.

So last week, Samsung announced they would be using Google Play Music as the default music player and the default music service on both the Galaxy S8 as well as the Galaxy S8+. Not only are the Galaxy S8 and Galaxy S8+ getting this treatment, but Samsung says it will happen on all Android-based Samsung phones and tablets launched in 2017.  However, there are some limitations and restrictions put in place depending on a couple of variables.

Samsung says this could change depending on which market you are located in, and which carrier you buy your device from. We’re also told that device support will be expanded on in the future too. These customers will have the ability to uploaded as many as 100,000 tracks to their own personal library (up from the regular 50,000). Lastly, those who purchase the Galaxy S8, Galaxy S8+ or the Galaxy Tab S3 can activate a 3-month free trial of Google Play Music (which also includes access to YouTube Red).

Source: Samsung Newsroom

No antivirus software is perfect. That’s why it’s important to a lot of people to have a reliable firewall as well. GlassWire is a great way to monitor and control what apps are connecting to the internet. This firewall is normally priced at $99 but right now it’s 70% off for $29. This will cover up to three PCs for a lifetime subscription.

• Network monitor visualizes current & past network activity by traffic type, app, & geographic location


• Threat monitoring reveals hosts that are known threats, unexpected network system file changes, & much more


• Firewall reveals all your network activity so you can easily see what your computer is doing in the background


• Notifies you when a new app or service accesses the web for the first time


• Reveals network activity that occurred while you were away or logged out from your computer


• Monitors remote servers where you host websites, apps, or games


• Keeps you under your bandwidth usage by alerting you to all possible internet overages


• Incognito mode hides all network activity or lets you clear it

Firewall reveals all your network activity so you can easily see what your computer is doing in the background

Network monitor visualizes current & past network activity by traffic type, app, & geographic location

Get this deal!

Purchases made through XDA Depot benefit XDA. Our sponsors help us pay for the many costs associated with running XDA, including server costs, full time developers, news writers, and much more. While you might see sponsored content (which will always be labeled as such) alongside Portal content, the Portal team is in no way responsible for these posts. Sponsored content, advertising and XDA Depot are managed by a separate team entirely. XDA will never compromise its journalistic integrity by accepting money to write favorably about a company, or alter our opinions or views in any way. Our opinion cannot be bought.

Android O is around the corner, yet according to official statistics, Nougat is still installed on less than 5% of devices. We have good news for the owners of the T-Mobile Galaxy Note 5, though:

T-Mobile confirmed that the Nougat update will be available to flash next week. News of the confirmation have been delivered by T-Mobile’s “Gadget Guy” Des. According to the tweet, the rollout is scheduled for early next week. It’s version 7.0, which is a little outdated nowadays, but it is still a welcome upgrade.

FRIDAY SOFTWARE UPDATE: Approval of Android 7.0 Nougat for #GalaxyNote5 today! @TMobile customers should start to see it early next week! pic.twitter.com/56VRHZoEdA

— Des (@askdes) 22 April 2017

The Galaxy Note5 is still technically the latest S-Pen device currently offered by the Korean OEM. Its successor, the Galaxy Note 7, was discontinued shortly after its premiere due to battery volatility.

This update for the Note5 is a good news both for users and developers working on custom ROMs for this device. A new version of Android means that users should see more TouchWiz Nougat ROMs in the near future.

It’s already been a month since Google released the first Android O Developer Preview (time sure flies by fast!), and as with any new version of Android – there’s a lot to dig into. We’ve published plenty of articles about Android O already, but there’s one feature that I feel hasn’t really received the attention it deserves: the Autofill Framework.

Autofill in Android O

Password managers are a dime a dozen these days (though we’re partial to the open-source KeePass), but it’s only with Android O that Google truly officially supports password managers. With Android O, third-party applications can fill the roll of an autofill service, which communicate with apps through the new Autofill Framework. Apps that use standard View elements will work with the Autofill Framework out of the box, though there are additional steps that developers can take to optimize for autofill to ensure that any of the app’s custom Views can be autofilled.

When an autofillable View comes into focus, the Autofill Framework will invoke an autofill request. The autofill service responds by sending back certain Autofill Datasets (such as the username, password, address, credit card numbers, etc.) that the user can then select. The autofill service is specified by the user in Settings –> Apps & Notifications –> Default Apps –> Autofill app.

Autofill App in Android O. Credits: Lastpass.

The explanation of the new Autofill Framework above is just a brief summary of what is happening on both the requesting app’s and the autofill service’s end. What’s most important for your understanding here is not the exact details of how autofill works in Android O, but the fact that the password manager apps themselves no longer handle detecting when a View can be autofilled.

Recommended Reading: AgileBits shows off what Android O’s Autofill Framework will look like

Autofill before Android O

Compare that to how autofill worked before Android O. Before password managers had any sort of official method to detect when a View could be autofilled, each application had to implement an Accessibility Service to scan the current View in order to find autofillable fields.

The use of an Accessibility Service, however, can result in considerable lag under certain conditions. The lag associated with your typical password manager’s Accessibility Service, though, is so apparent that popular services such as LastPass even have support pages up regarding the issue. These support pages typically tell you that your only recourse for dealing with excessive lag caused by their Accessibility Service is to either disable the Accessibility Service or switch to using their own custom input method. Either way, you lose any sort of autofill ability.

But why exactly does LastPass’s Accessibility Service, or any other password manager’s Accessibility Service, seem to cause so much lag? The reason is because of how these password managers have to utilize Accessibility Services to detect input fields. An Accessibility Service’s attributes are defined in an XML resource file within the APK, so we can see how the Service works by decompiling the APK file.

Below is the resource file taken from decompiling the LastPass APK:

<?xml version="1.0" encoding="utf-8"?>
<accessibility-service android:description="@string/accessibility_service_description" 
android:accessibilityEventTypes="typeViewFocused|typeWindowContentChanged" 
android:accessibilityFeedbackType="feedbackGeneric" 
android:notificationTimeout="200" 
android:accessibilityFlags="flagReportViewIds" 
android:canRetrieveWindowContent="true" 
android:canRequestEnhancedWebAccessibility="true"
xmlns:android="http://schemas.android.com/apk/res/android" />

From this, we can glean the following information: LastPass’s Accessibility Service requests two Event types to monitor – TYPE_VIEW_FOCUSED and TYPE_WINDOW_CONTENT_CHANGED. It does this because it needs to know when an app/webpage’s content changes or comes into focus, and then it retrieves the current window content to look for any password input fields. But since the service constantly does this on two extremely frequently firing Accessibility Events, it results in lag. For a more in-depth discussion of how Accessibility Services can cause lag, I refer to you my previous article on the matter.

Recommended Reading: “Working as Intended” – An Exploration into Android’s Accessibility Lag

Android O Kills Two Birds with One Stone

Prior to Android O, there’s not really much developers of password managers could do to mitigate this lag. That’s because password managers had no way of knowing when an autofillable input field was on the screen without enabling an Accessibility Service to constantly monitor for them. But thanks to the new Autofill Framework in Android O, these password managers can now retire their Accessibility Services. Instead, the apps that need data entry themselves will request the Autofill Framework to call the autofill service that will then send the data. Thanks to this new framework, not only will password entry become much easier for users since they no longer have to rely on an additional input method, but the lag associated with enabling password managers’ Accessibility Services will be a thing of the past.

I know that for some of you, this fact may not be ground-breaking, but I thought that since the discussion around the Accessibility Service was so mute this topic might have been worth rekindling. Just some food for thought this weekend!

What do you think of Android O’s new Autofill Framework? Let us know in the comments below!

Cutting corners in a cut-throat market

Any press is good press, or so they say. That’s a phrase often used when a company finds itself in a precarious situation — but as Samsung learned first hand, in a hyperactive segment like this ever changing mobile space, the smallest misstep can turn out to have grave ramifications.

Huawei is learning this first hand with the negative press surrounding its recently-launched P10 and P10 Plus series of devices. They are no stranger to negative press surrounding the quality of their hardware. First came the Nexus 6P build quality debacle with shattering visors and bending devices, and recently the Honor 6X screen and build quality issues notched another one in their belt. One would think they would be walking a finer line when it comes to their smartphones, but the latest news surrounding them says otherwise.

As Aamir wrote about in an earlier article, Huawei is in the midst of a controversy due to how it handles its flagships’ components. They have already admitted to sourcing components from various sources, but further investigation is showing that these components feature vastly different technologies and capabilities from RAM speeds to the type of internal memory that is used. Utilizing components from various sources is a very common practice among OEM’s. Samsung does this with its cameras in its flagships known to alternate between its own ISOCELL sensor and a Sony one. Apple does this with its SOC’s alternating between Samsung and TSMC for manufacturing (which has brought its share of negative press) and it is widely known that HTC sources its displays from multiple partners too. 

Batteries, displays, cameras, internal storage, and RAM can all be sourced from various partners. This helps supply chain constraints and it can also help with quality assurance… generally, it is perfectly fine. What is not fine is when these components offer vastly differing experiences depending on your luck of the draw, which is what Huawei is offering right now. While many users may never notice a difference between LPDDR3 and LPDDR4 or UFS 2.1 and eMMC 5.1; there is a quantifiable difference, and when you are paying flagship prices every customer deserves the same or at the very least a similar experience. By giving users a random combination of RAM and storage types, their customers aren’t buying a flagship, but a lottery ticket for a chance to earn the full product Huawei advertised.

Unlike other cases of component variety with a smartphone line, a large part of Huawei’s advertising relied entirely on the flagship components a user might have. Huawei, like many other Chinese manufacturers, puts a clear and heavy emphasis on marketing their devices’ power and performance. It’s no surprise, then, that they’d pick the faster RAM and UFS2.1 storage as talking points for their ad campaigns and promotional materials. In fact UFS2.1 was advertised for all markets of the Mate 9 as recently as last week; however, today only a few market pages actually show that specification. Obviously, though, it becomes a problem when a significant portion of P10 customers may not get the UFS 2.1 storage, or the LPDDR4 RAM, or both. People paid for a flagship under the notion that they’d get a flagship, with flagship components throughout. When people pay for a Samsung device, ISOCELL and Sony sensors offer comparable performance with differences that, to my knowledge, haven’t shown significant and quantifiable deltas — there is a mostly-lateral difference between the two. There is a clear hierarchy between LPDDR4 and LPDDR3 RAM, however, and the same goes for UFS 2.1 and eMMC 5.1 storage.

A worrying aspect to much of this is what it means for what Huawei is as a company, and what it’s trying to do. Giving credit where it is due, Huawei devices have come a long way. The Mate 9 and Honor 8 Pro are fantastic phones offering a solid build, vastly-improved software, and an overall appealing package. Huawei is trying hard to break into the large and somewhat stagnant US market and while on the surface they have nearly all the components to succeed, the lack of good decision making from Huawei serves to undermine all that they have accomplished. It’s not just their phones that have this issue either.

The Huawei Watch was and still is one of the best Android Wear devices you can buy today; it has a stellar screen, fantastic look, excellent battery life, and more. But instead of capitalizing on its success, Huawei has made one of the most boring and uninteresting devices to date – the Huawei Watch 2.

Similarly, the Honor 5X was a solid piece of hardware crippled by its software, which can be easily remedied. But instead building on that solid foundation they release its successor – the Honor 6X – which ships with an out of date OS version, crippled build quality, and packs one of the least durable displays on the market. The P10, which we have been speaking about, also ships with no oleophobic coating which is not only a standout in the market (particularly its segment), but is also just dumb. The recent string of decisions from Huawei are troubling seeing as their success in the US market, which can greatly help them in the long run, depends largely on enthusiasts, positive media coverage and word of mouth at this time; and despite my largely positive experiences with the Honor 8 Pro and Mate 9 I am hesitant to recommend them friends and family. The North American market does not appreciate corner cutting, and Huawei is truly not breaking away from the stereotype that troubles Chinese manufacturers in the US so much.

While Huawei’s decision making in these past few months leaves a lot to be desired, there is still time for them to correct their course and get back to improving their offerings. They need to be cautious though, they do not have the clout of a company like Samsung which can fairly easily rebound from total meltdown. There were some who thought Samsung would never come out from what happened with the Note 7, but soon after the S8 announcement they are boasting some of the best preorder numbers yet. Huawei makes a compelling phone with software that is quickly catching up to the competition, they just need to make sure they don’t shoot themselves in the foot by poor decision making because in an ultra-competitive market, someone is always nipping at their heels.

What do you think about the P10’s hardware lottery? Let us know in the comments.

Some of the “smallest” improvements found in the Galaxy S8 and Galaxy S8+ reside in the camera department. That is not entirely a bad thing, because the Galaxy S7 and S7 Edge did set the bar really high for their camera performance.

The front camera on the Galaxy S8 and S8+ did receive a hardware upgrade. The S8 features an 8MP sensor with f/1.7 aperture, with the new highlight feature being its autofocus capabilities. This is the first Samsung device that features proper autofocus on the front, which should help with selfies.

Interestingly, the Samsung Galaxy S8 and S8+’s front camera has another trick up its sleeve:

JerryRigEverything noticed in his teardown video that the front camera on the Galaxy S8 features a stabilization mechanism. The camera module and its internal movements suggest it was actually designed to make use of Optical Image Stabilization. The front camera on the retail and review units do not seem to have have OIS capabilities enabled though, so Samsung may have just been toying with the idea.

What are your thoughts on the disabled-OIS on the Samsung Galaxy S8 and S8+’s front camera? Let us know in the comments below!

Source: YouTube: JerryRigEverything

If you’re just getting started with learning Ruby, Java, Javascript or Google Go Lang, this is a great place to start. Before purchasing one of the more in-depth bundles from the XDA Depot, check out this one for free. This collection of beginners coding courses is valued at $737. If you get it through the XDA Depot, you pay nothing. Here is what you’ll find in this bundle.

• Ruby Programming Basics


• Learn Google Go Lang


• Javascript and jQuery Basics for Beginners


• Java Programming for Mobile Developers


• Become a Full Stack Web Developer in 14 days

There is over 27 hours of content to explore here. Ruby is one of the most popular web programming languages there are. Java will get you started with creating mobile apps. The Full Stack course will teach you how to create a bunch of different kinds of web applications.

Learn Google Go Lang
Diversify Your Coding Skill Set with This Open Source Language Developed (And Used) by Google

Javascript and jQuery Basics for Beginners
Dive into The Powerful jQuery Library to Quickly & Easily Write JavaScript Code

Get this course!

Purchases made through XDA Depot benefit XDA. Our sponsors help us pay for the many costs associated with running XDA, including server costs, full time developers, news writers, and much more. While you might see sponsored content (which will always be labeled as such) alongside Portal content, the Portal team is in no way responsible for these posts. Sponsored content, advertising and XDA Depot are managed by a separate team entirely. XDA will never compromise its journalistic integrity by accepting money to write favorably about a company, or alter our opinions or views in any way. Our opinion cannot be bought.

Not many think about ZTE when they think of a smartphone company that is doing well these days, but they have had a good year so far. ZTE is still facing fierce competition from the likes of Huawei and Xiaomi, but profits show they are bouncing back some. The company recently released their financial report which showed an increase in profits of almost 30%. The company attributes this thanks to increased sales of both carrier network solutions as well as smartphones.

Many of you already know about ZTE’s smartphones, but the company also has Pre5G products deployed at over 40 networks in 30 countries. So now the Chinese multinational telecommunications company is switching things up with some of their executives. The person who was previously in charge of ZTE’s entire mobile business was Yin Yimin. However, last month the company named Mr. Yimin as a new chairman so now he’s stepping down from the previous role he had.

To take his place, ZTE has announced they will bring over the person who has been in charge of ZTE’s United States division. Cheng Lixin has been president of the company’s North America mobile devices business since 2010. Mr. Lixin will now take the place of Mr. Yimin and will now be the president of ZTE’s entire mobile devices division. ZTE came to this decision since the United States market is the strongest for the company, so they feel it makes sense for him to take the lead.

This change in leadership comes after ZTE pled guilty to a sanctions case with the United States just last month. The investigation has been going on for 5 years and ZTE thought it was best to end it quick when they had the chance. The company has agreed to pay hundreds of millions in fines as well as move around some of their senior management staff.

Source: Reuters

In July of last year, Google announced two new APIs for their Google Cloud Platform customers that had to do with speech recognition. These were made available in beta form to a limited number of developers and the Cloud Natural Language API and the Cloud Speech API. Along with being limited to a certain number of developers, the functionality of these APIs were also quite limited as Google was still working to enhance and optimize their capabilities.

The Cloud Speech API is Google’s own Automatic Speech Recognition (ASR) service and it actually powers the speech recognition capabilities for a number of Google’s products (such as Google Search, Google Now, Google Assistant). Google took that technology and adapted it to fit the needs of Google Cloud customers and this was how the Cloud Speech API was born. Earlier this week, Google not only made this technology generally available to developers, but they also announced a big update for it as well.

This update includes a couple of enhancements to previous features and added support for some new file types. Some developers had complained that transcribing long-form audio wasn’t very accurate, so Google says this update will improve things on that end. The service is also faster in certain cases with developers seeing it being 3 times as fast as before for batch scenarios. The last highlight of this update is the added support for WAV, Opus and Speex file formats.

Since the launch of the Google Cloud Speech API, the company has seen a couple of popular use cases for the service. Naturally, Google has seen a number of developers adopting the service to add voice search, voice commands and Interactive Voice Response (IVR) to their product. But they’re also seeing it being used for speech analytics and this has proven useful for businesses who are looking for real-time insights from their call centers.

Source: Google Cloud Platfrom Blog

According to a new report by The Wall Street Journal, Google is working on a built-in ad blocker solution for desktop and mobile versions of its Chrome web browser. The ad blocker will be turned on by default and will block out those specific types of ads which are responsible for ruining the browsing experience, the report says.

Not all ads will be blocked, though: Google’s own ads will still be displayed. The ad blocker will reportedly filter out pop-up ads, countdown timers, auto-playing audio and video ads and other objectional ad experiences which are defined to be unacceptable as per the standards of Coalition for Better Ads. According to the report, Google will require site owners to follow a specific set of standards to ensure their ads doesn’t get block by the Chrome’s built-in ad blocker. In short, say bye to those annoying, buzzing adds taking over your phone for a few seconds.

The move is said to be an attempt to combat the annoying ads and bad advertising practices. By implementing a native ad blocker, Google is also seeking to lower down the increasing usage of ad blockers.

A built-in ad blocker will make far more sense for the mobile version of Chrome than its desktop counterpart. On the desktop version, you can install a third-party ad blocker to effectively block all ads, but there is presently no such way to do so on Chrome for mobile, not without modifications most people don’t have access to at least.

The WSJ says the feature is currently being developed, and Google could announce the new feature “within weeks.” At the same time, the report also notes that such feature may never come to fruition and that Google could decide to scrap the plan altogether, just like it has done with many other projects in the past.

Either way, a built-in ad blocker in Chrome sounds like a great idea and even if doesn’t help get rid of all the ads, it can, at least, improve the browsing experience to a great extent for end users by blocking out only the nasty ones. By making this a default feature, ad companies would be compelled to weed out bad ads and actors. It’s also a smart move for Google, as it’d mean the ad-creator controls the ad-blocker… for better or worse.

What do you think of this kind of ad-blocking strategy? Is it a genius idea, or is it bound to fail? Sound off in the comments below!

Source: The Wall Street Journal

Those of you who are running the first Android O Developer Preview may have toyed around with its hidden navigation bar customizer located in the SystemUI Tuner. This nav bar customizer has actually been around in AOSP for months, but it was thought that the only way to access it on Android Nougat was through a modification of the System UI APK, which, of course, would require root access. It wasn’t until just this week that we discovered that Android Nougat’s hidden nav bar customizer could actually be accessed without needing root access, a custom ROM, or a System UI mod. With this feature, we can change the nav bar icons, swap the keys around, or add additional buttons.

That’s right – it’s possible to modify your navigation bar on a completely stock, unrooted ROM with a locked bootloader. Functionality people thought was limited to Android O is actually accessible to anyone running Android Nougat on Nexus, Pixel, OnePlus, and some Sony, HTC, and Motorola phones. If your device is running software that is close to Google’s software (sorry Samsung and Huawei/Honor users), then chances are your device has the hidden AOSP nav bar customizer that we can use. In this tutorial, I will show you how you can use the nav bar customizer to change the button icons to whatever you want or re-arrange them in whatever order you want.

Google Pixel Nav Bar on the Nexus 6

Reversed Nav Bar on Nexus 6

Modifying the Nav Bar – Setup

There are two ways to modify our nav bar. One is with an app, and the other is through ADB shell commands (which is how the app works). We will be showing you both for completeness, but note that as of right now, you can’t modify the stock nav bar icons through the app until the developer updates his app to include this feature.

The first thing we need to do is to make sure that it’s even possible to modify the nav bar on your device. If your device is one of the ones listed as compatible in the Custom Navigation Bar thread, then chances are it will be. We can verify by running through the brief tutorial that accompanies this app.

Install the app from the Google Play Store (and also sign up for beta testing so we can use its experimental feature to re-arrange the nav bar later on). Next, open up the app and proceed through the introductory screens. Custom Navigation Bar will ask you to grant it a certain permission called WRITE_SECURE_SETTINGS in order to proceed with using the app. There are two ways you can do this, as stated in the application.

1. If you have a rooted device, open up Terminal Emulator on your phone and grant it root access by typing su. Then, enter this command: pm grant xyz.paphonb.systemuituner android.permission.WRITE_SECURE_SETTINGS


2. If your device is not rooted, then you will need to grant the permission through ADB. Open up a command prompt/terminal on your machine, and then enter the following command: adb shell pm grant xyz.paphonb.systemuituner android.permission.WRITE_SECURE_SETTINGS

Once you’ve granted the app this permission through either of the two methods above, then the app will proceed with a compatibility test. If your nav bar doesn’t change, then you’re unfortunately out of luck. If your nav bar changes to display a right arrow button, then congrats your device is supported! We can now move on to modifying our nav bar.

Re-arranging the Nav Bar Buttons

App Method

Now that you’ve set up the app, it’s very, very easy to re-arrange the nav bar buttons. You have to be on the beta testing version of the Custom Navigation Bar app to be able to do this, so go back and make sure you’re on the beta channel before proceeding.

If you’re on the beta version, you’ll see a section called experimental tweaks in the main Settings section. Tap on that and you’ll see options that allow you to replace the existing back, home, and recent keys. You can easily re-arrange your keys here by having the back button change to the overview (recent) button and having the overview (recent) button change to the back button. Or change them in whatever way you want, there’s no real limitations here. After swapping your keys, you can also play around with the layout options in the navigation bar settings menu.

ADB Method

And here’s how to do the same using ADB commands, if you would prefer that. The command that we will be modifying is the Secure setting preference called sysui_nav_bar. This preference is a string that contains the nav bar layout. The default structure of the preference is as follows

space,back;home;recent,space

Where space represents an empty space that separates the nav bar keys from one another, and back, home, and recent represent the 3 default buttons in the nav bar. If we want to swap the back and the recent key, for instance, we would need to modify the string as follows

space,recent;home;back,space

Now, in order to actually modify this string, we need to use the ADB shell command with this syntax

adb shell settings put secure sysui_nav_bar "STRING"

Hence, the command we would send to swap the recent and back keys would look like this

adb shell settings put secure sysui_nav_bar "space,recent;home;back,space"

As you might guess, this is fairly flexible. We can move the keys around however we want by modifying the string value of the preference. We can, for instance, make our flipped nav bar keys left-justified or right-justified by changing where the two spaces are placed:

Left-justified:

adb shell settings put secure sysui_nav_bar "recent;home;back,space,space"

Right-justified:

adb shell settings put secure sysui_nav_bar "space,space,recent;home;back"

But we can also change the nav bar buttons to be something entirely different than the standard back, home, or recent keys, such as sending one of the many KeyEvents. We’ll take advantage of this fact in the next section, where we show you how to change the icons on the nav bar buttons.

Custom Nav Bar Icons

Now, the following section may not seem like a huge deal due to the fact that there are numerous applications on the Play Store that promise to change your navigation bar without root. And they do work – however, many users report that these apps are buggy in certain apps like Chrome, when playing full screen video, or some games. Furthermore, many of these apps require you to enable an Accessibility Service to monitor apps to know when to re-color the nav bar, which may reduce performance. Finally, if you rely on these apps for too long, then you may be suddenly surprised to see them stop working when Android O rolls out because the next Android version is killing the ability of these apps to draw on top of System UI elements.

The method that we are using is based on Google’s implementation of the nav bar tuner, so it has none of these issues. However, there is one issue currently that we want to be upfront about: if you choose to follow this method to modify your home button, then the long-press home button action will no longer work meaning you can’t quickly access Google Assistant from the home button anymore. If you’re okay with that, then here’s how to change the icons on the nav bar.

The first thing you will need to do is download the icons that you want to replace your default nav bar keys’ icons with. I’ll be providing download links for you to grab the Google Pixel nav bar icons, but it’s up to you to find your own icons if you want anything else. You’ll need the icons in the PNG format, and as for the size, you can determine the size of the icons you need by looking up your device’s display density metrics on Material.io and correlating that with an icon size reference chart.

Credits for the extracting these Google Pixel nav bar icons goes to XDA Senior Member dariomrk. Download this archive if you have a 1920x1080p display and this one if you have a 2560x1440p display. Extract the contents of either zip file into a folder called “NavIcons” on the root directory of your storage.

Once you have the icons in the appropriate place, enter the following ADB shell command (warning, it’s a long one):

adb shell settings put secure sysui_nav_bar "space,key(4:file:///storage/emulated/0/NavIcons/back.png);key(3:file:///storage/emulated/0/NavIcons/home.png);key(187:file:///storage/emulated/0/NavIcons/recents.png),space"

What this command does is replace back, home, and recent keys with KeyEvents that do the same function. In particular, back is replaced with KEYCODE_BACK, home is replaced with KEYCODE_HOME, and recent is replaced with KEYCODE_APP_SWITCH. These key codes perform the exact same function, but because we are using KeyEvents, we can specify what icon we want to use for them. In this case, we are pointing towards the back.png, home.png, and recents.png that we saved in /NavIcons.

However, by replacing the stock keys with KeyEvents, we lose the long-press home ability because currently there is no way to recognize long-press events of simulated key inputs.

I realize that right now, this method might not seem ideal or easy to implement, but at the time of this writing the Custom Navigation Bar app has not been updated to support adding your own icons. For now, my method (which is exactly how that app works, and when the app does get updated, it will face the same limitation) is how you can get whatever custom icons you want on your nav bar.

That’s it for this tutorial. In future tutorials I will show off potential practical uses of changing your nav bar, especially in a contextual manner using an automation app such as Tasker. Follow the tutorials category on XDA to keep up to date with all the latest tips and tricks that we publish.