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!

Early reports indicate that Samsung’s new flagship devices are off to a pretty great start, with the lineup breaking the previous pre-orders records set by the Galaxy S7 and Galaxy S7 Edge. However, not all things are bright and beautiful: the Galaxy S8 and S8+ have attracted a quite a bit of criticism for its red-tinted display on some units.

The issue of reddish display first came to know when the Galaxy S8 and Galaxy S8+ went on sale in South Korea, with many owners posting images of red-tinted display of their Galaxy S8 units on social media sites. It was believed the culprit had to do with Samsung’s attempt to strengthen red color on their OLED panels. Samsung reportedly developed deep red OLED displays for Galaxy S8 devices in order to avoid the issue of too much green due to the uneven distribution of subpixels in a pentile matrix. Initially, Samsung denied such issue was due to a hardware fault and advised users to adjust the color balance on their devices from within the display settings. But as more consumers raised their voices on the issue, Samsung announced on Thursday that a new software update would be rolled out next week to readjust the color balance on affected units.

Now according to a new report from the US-based review publication, Consumer Reports, the problem of the reddish display on the Galaxy S8 is not something that one should worry about.

To check the veracity of the reddish tint issue, Consumer Reports tested eight Galaxy S8 devices and found that out of eight devices, four Galaxy S8 had slightly reddish tint. The publication also notes that the issue is not immediately noticeable unless the user is comparing the two devices side-by-side.

“Our display evaluators noted that displays of four of our test models appeared slightly more red than the other four. It’s unclear how much consumers might object to the red tint, especially if they weren’t looking at two phones side-by-side.”

Additionally, Consumer Reports also said Samsung would release the software update as early as next week to address the color balance problem.

So while the issue is still there in some units, the good news is that it’s just a result of a software calibration problem, or at least it can reportedly be addressed through software, and should be fixed with the upcoming software update.

Source: BusinessKorea

What do you think? Is Samsung underplaying the significance of the displays’ red tint, or is it really not a real issue? Sound off in the comments!

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.

A use of old technology in a new way is transforming the potential capabilities of IoT.

Myriad Group, a mobile software company that originated in Switzerland in the 1990’s, have created Pressto, a connected bundle built on Myriad’s IoT platform, ThingStream.io.

The device uses the Unstructured Supplementary Service Data (USSD) protocol to send 182 character messages to the Pressto server across cellular networks. Pressto bundles a connected button, GSM connectivity, and management platform in a single package which allows you to focus on building the application that the button press triggers. The press of a button transfers a small payload of information to your application which includes GPS coordinates along with time/date and simple button status information.

What is USSD?

USSD is a protocol used by Global system for Mobile Communications (GSM) cellular telephones to communicate with the service provider’s computers. It can be used to provide independent calling services such as a callback service (to reduce phone charges while roaming), enhance mobile marketing capabilities or interactive data services, people know it most commonly as a means to query a phone’s available credit.

I spoke to Neil Hamilton, VP Business of development at Myriad Group to find out more.

USSD is commonly used for mobile money transfers in developing markets such as Africa, India and Latin America where many people do not possess bank accounts. This application has allowed for payment of utility bills or money transfers. Hamilton explained that:

“If we start thinking about IoT use cases where a device needs to transmit small data payloads (not videos or big files, but kilobytes per day) then we could use the USSD network to do that…  We kind of enable a GSM equivalent of a LP-WAN because USSD doesn’t need as much processing power. It also uses far less battery power and therefore devices can be much cheaper when compared to if I’m trying to roll out on LTE where I need more expensive components model to communicate via LTE.”

Myriad Group have established global roaming network access with 600 plus carriers and through the use of supplied embedded sim cards their users can transmit data and submit signals from almost anywhere in the world.

“Then effectively we provide a small code library to whoever is making their devices. And that enables the translation of the data. If it’s a sensor with a motion control we make sure we convert that into a format that we can be transported over USSD. Don’t forget there’s no internet involved. So we kind of spoof an internet language over USSD, our gateway converts that back into internet language and it goes downstream to an application.”

What kind of use cases suit USSD?

The USSD as a conduit for transferring data works particularly well in small, fast moving, remote scenarios such as logistics and tracking, as Hamilton explains:

“Cargo companies work with different end-to-end carriers and they don’t know where cargo is going. if you want to get a heartbeat on a container from almost anywhere, it’s difficult to do. We purchase wholesale connectivity and enable GSM to compete with LPWAN services, business the carriers are missing out on.  We don’t want to say ubiquitous service at any time but it’s definitely one where things are remote or moving.”

Agricultural and environmental services companies can be faced the challenge of trying to monitor hectares of farming land or agtech solutions when they’re often near roads that get busy at certain times of day or cell base stations get really and they can’t always have ubiquitous connectivity.

See also: How to turn hardware into IoT by simplifying connectivity?

Hamilton notes that the more they discuss USSD as a data conduit for industrial applications, the more use cases emerge. Today, a number of sensor manufacturers are exploring sensing-as-a- service model. If you’re a high-value sensor manufacturer you typically sell to a distributor who sells to someone who makes something and so on.

“If you start to sell your device completely connected, then it will work anywhere. And then someone could log onto a corresponding app from the sensor manufacturer to then point the data to whatever application you want to deliver it to. It means there are potential opportunities opening up right out on the edge for people to change their markets.”

The Pressto button was originally designed for proof of concept purposes to demonstrate use cases, but it has attracted a surprising amount of interest according to Hamilton but they’ve got more in development:

“We’ve got a very interesting workflow platform coming for how to manage connected devices and that’s where we’re heading now, building up the platform side to offer some more value added and useful services for industrial companies that want to connect up their things.”

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!