Xiaomi Mi True Wireless Earphones 2 TWS Review: Good sound limited by bad design and missing features

Xiaomi entered the TWS earphones segment in India earlier this year with the launch of the Mi True Wireless Earphones 2 and the Redmi Earbuds S. Of the two, the Redmi Earbuds S is the company’s budget-friendly offering, which is undoubtedly one of the best pair of TWS earphones in the sub-₹2,000 price bracket. The more premium Mi True Wireless Earphones 2, on the other hand, is a tough sell at ₹4,499. While the earphones do sound better than the Redmi Earbuds S, they have a couple of drawbacks that are difficult to overlook at this price point. I recently got my hands on the Mi True Wireless Earphones 2 and here are my thoughts on Xiaomi’s premium TWS earphones.

Note: Xiaomi India sent us a pair of Mi True Wireless Earphones 2 for review. However, the company did not have any input on the content of this review. This review is written after two weeks of use.

Design

Even though the Mi True Wireless Earphones 2 draws inspiration from Apple’s AirPods, its design isn’t nearly as similar to the AirPods as that of the Realme Buds Air. The charging case isn’t as rounded and has flat edges on the top and bottom. It’s slightly larger in size and offers a more secure grip when opening with one hand. Unlike the Redmi Earbuds S, the case feels more premium, features a function button to help you pair the earphones with a new device, and an LED indicator to show the current battery level. The case has a USB Type-C port on the bottom for charging.

Much like the case, the earbuds feature a slightly angular design that distinguishes them from other AirPods clones available in the market today. The Mi True Wireless Earphones 2 has a wider stem that protrudes at the top, which isn’t as stealthy and I, for one, am not a fan of how much the earphones stick out when in use. Xiaomi claims that the shape of the earphones has been optimized by mapping millions of ears in simulation software, and they seem to have done a good job. The fit is comfortable, the earphones stay in place even while running, and long term use doesn’t cause any fatigue. However, the design of the earphones does have some major drawbacks.

Since the Mi True Wireless Earphones 2 don’t feature silicone tips, they offer no noise isolation. This means that even at high volumes, you’re able to hear almost everything that’s going on around you which doesn’t lend to a pleasant listening experience when you’re out and about. On top of that, when you’re playing music at over 60% volume, there’s significant sound leakage and everyone in a one-meter radius can hear what you’re listening to. This could prove to be annoying for the people around you, making the earphones bothersome to use in public spaces unless you keep the volume low.

In terms of build quality, I have no complaints with Xiaomi’s premium TWS earphones, other than the fact that it doesn’t feature any IP rating. This is disappointing since even Xiaomi’s budget-centric Redmi Earbuds S features an IPX4 rating.

Features

The Mi True Wireless Earbuds 2 isn’t as feature-rich as other TWS earphones in this price range. The pairing process for the earphones is quite simple as you just need to press and hold the function button for 2 seconds. After this, the LED indicator on the case starts blinking and the earphones are ready to be paired with your device. Reconnecting with a previously connected device is as simple as pulling out the earphones from the case and putting them in your ears. The pairing process is even simpler if you’re using a Xiaomi/Redmi device, as it just requires you to open the lid near the device. When you do so, a pop-up will appear on your home screen and you just need to follow the instructions to get connected.

Interestingly, the Mi True Wireless Earphones 2 also let you connect each earbud with a different device. To do so, you’ll need to place one of the earphones in the case and then follow the regular pairing process with the first device. Once the earbud is paired, you can follow the same process for the next earbud to connect to the second device. However, before you use this feature, you’ll need to need to clear the connection history of each earphone. You can clear the connection history by placing the earbuds in the charging case and holding the function button for 10 seconds. The indicator LED will blink red and white to confirm that the connection history has been cleared.

Unlike the Redmi Earbuds S, Xiaomi’s premium TWS earphones feature touch controls for music playback and calls. Both the earbuds have a small touch-sensitive area towards the top of the stem that can be tapped twice to control all of the features. You can answer incoming calls or end an ongoing call by double-tapping on either earbud, tap twice on the right earbud to play/pause music, and double tap on the left earbud to bring up the voice assistant of your choice. If you’re using a single earphone, however, you’ll only be able to play/pause music using the gesture. Since the earbuds feature a proximity sensor, you can also play/pause music by pulling one earbud out. In my experience, all the touch gestures worked as intended but the earphones took a noticeable amount of time to register the input.

For connectivity, the Mi True Wireless Earphones 2 supports Bluetooth 5.0. Unlike the Redmi Earbuds S, Xiaomi’s premium earbuds support three Bluetooth codecs — SBC, AAC, and LHDC — with the latter making a prominent appearance in Xiaomi’s marketing for the earphones. The earphones also offer environmental noise cancellation for voice calls. The functionality offered by the Mi True Wireless Earphones 2 is pretty standard for TWS earphones in this price range, but it doesn’t offer a low-latency gaming mode that’s found on several of its competitors and the Redmi Earbuds S. It also doesn’t include gestures to adjust volume or switch tracks, which could be a deal-breaker for some of you.

Audio Quality

The Mi True Wireless Earphones 2 feature 14.2mm dynamic drivers, and Xiaomi claims that the earphones offer a high-end audio experience. However, the earphones don’t quite live up to Xiaomi’s claims. Before I proceed any further, I’d like to clarify that since we all perceive sound differently, you might not agree with some of my observations about the audio quality.

Playlist

• Hometown — French 79
• Teardrop — Massive Attack
• Safety — Gashi (ft. DJ Snake)
• Panda — Meute
• Time Goes By — Kupla
• Seven Nation Army — The White Stripes
• Mad World — Gary Jules (ft. Michael Andrews)
• The Blower’s Daughter — Damien Rice
• Tadow — FKJ
• Rockstar — Post Malone (ft. 21 Savage)
• Young Folks — Peter Bjorn and John
• Wasted Years — Iron Maiden
• Purusha — NVDES
• Parallel Jalebi — Four Tet
• Who We Want to Be — Tom Day

I listened to the same playlist that I used for the Redmi Earbuds S review, and I instantly noticed that the Mi True Wireless Earphones 2 sounded much better than the budget-centric earphones. But that was expected given the price difference between the two. Xiaomi’s premium TWS earphones offered much better vocal clarity and a wider sound stage, which meant that I could easily differentiate between all the different instruments played in Meute’s Panda. Bass, however, wasn’t as punchy as that of the Redmi Earbuds S and the mid/high frequencies often overpowered the lower notes.

The earphones got quite loud at max volume, but the overpowering high frequencies made the listening experience a bit painful during a few songs. While the audio reproduction was quite satisfactory for a pair of earphones in this price range, the lack of noise isolation due to the design left a lot to be desired. Even while listening to music in my room, I could constantly hear my AC droning away amidst the Delhi heat, and that leads me to believe that the earphones will perform worse in noisier environments. And as mentioned earlier, turning up the volume meant that everyone around me could hear what I was listening to, which eventually ended up annoying my brother who was trying to work in peace.

All of the testing was done using the SBC and AAC codecs and I wasn’t able to test the performance using the high-quality LHDC codec. Even though this article points out that Google was bringing LHDC support to all Android 10 devices, I wasn’t able to find LHDC support on any of my devices. Upon further research, I found that codec isn’t quite popular and is only supported by a few Xiaomi and Huawei devices. Tushar from our team confirmed that the Redmi K20 Pro and Redmi Note 9 Pro included support for the codec so, if you have one of these devices, you might be able to improve the audio performance of the Mi True Wireless Earphones 2 even further. Most other users will have to stick with the SBC and AAC codecs.

As far as call quality is concerned, I faced no issues while taking calls with the Mi True Wireless Earphones 2. Its dual-microphone setup ensured that my voice sounded clear on the other end, albeit slightly compressed, and the environmental noise cancellation ensured that the earphones didn’t pick up any unwanted noise from the background. Overall connectivity was also solid and the earphones didn’t disconnect even if I left my phones in a different room.

Battery Life

The Mi True Wireless Earphones 2 pack in a 30mAh battery in each earphone and a 250mAh battery in the charging case. Xiaomi claims that the earphones can be used for up to 4 hours on a single charge but, in my testing, I found that the earphones didn’t last more than 3 hours and 40 minutes at 80% volume. Turning up the volume to 100% while listening to music dropped the battery life to about 3 hours and 20 minutes.

Once the battery is drained out, you can use the case to charge the earphones back up about three times over. This gives us a total playback time of about 11 hours, which is significantly lower than Xiaomi’s 14-hour playback rating. Charging the earphones from 0-100% using the case took about 40 minutes and the case itself took about an hour and a half to get back to full. The battery life is just about average for a pair of earphones in this price range, however, the faster charging speed will let you squeeze out some more playtime in daily use.

Conclusion

If you’re in the market for a pair of TWS earphones in the sub-₹5,000 price range, then the Mi True Wireless Earphones 2 isn’t the best option you can go for. Its noise isolation is poor, which greatly affects the overall audio quality, the battery life is just about average, the LHDC support isn’t useful if you don’t have a supported device, and you can’t really use the earphones at above 60% volume without annoying the people around you. On top of that, the earphones don’t feature a low-latency gaming mode, volume controls, or a track switching gesture.

In comparison, Xiaomi’s budget-friendly Redmi Earbuds S actually presents a better overall deal. Even though they don’t sound as good, they’re less than half the price, offer better noise isolation, feature IPX4 water resistance, and even include a low-latency gaming mode. If you’re not comfortable using earphones that feature a silicone ear tip and would much rather prefer a design similar to the Mi True Wireless Earphones 2, you can also consider the Realme Air Buds which are priced at ₹3,999 and offer similar battery life and audio performance, along with a couple of additional features like wireless charging support, a low-latency gaming mode, and a gesture that lets you skip to the next track.

Buy the Xiaomi Mi True Wireless Earphones 2: Amazon || Mi.com

This article contains affiliate links, which will net XDA a small commission if you purchase a product from clicking a link.

The post Xiaomi Mi True Wireless Earphones 2 TWS Review: Good sound limited by bad design and missing features appeared first on xda-developers.

from xda-developers https://ift.tt/384stNT
via IFTTT

Exclusive: Google plans to relax security update requirements for Android Enterprise Recommended

While Android is the overall dominant smartphone operating system according to data from IDC, Apple’s iOS is the OS of choice for most enterprises. It’s easy to see why: Apple updates its iOS devices generally far longer and more consistently than most Android device makers update their smartphones, iPhones are simple to configure and manage, and there are far fewer SKUs to support if a company picks Apple. But there are also reasons for enterprises to pick an Android device, including reduced cost and more flexibility in hardware. To make Android even more enticing for the workplace, Google launched “Android for Work” in early 2015 (later rebranded as “Android Enterprise” in late 2016). Then in early 2018, Google launched the Android Enterprise Recommended (AER) program to certify devices for business use. Google codified a set of requirements that devices must meet to be “Android Enterprise Recommended,” including minimum hardware specifications, support for bulk deployment, availability of unlocked devices, consistency of app behavior running in managed profiles, and delivery of Android security updates within 90 days of release for a minimum of three years.

However, documents uncovered by Android developer @deletescape that were reviewed by XDA-Developers reveal that Google is planning to loosen security update requirements for Android Enterprise Recommended devices. Instead, Google is pushing for vendors to be more transparent about how they handle security updates. According to @deletescape, these documents were shared with vendors within the last 15 days. Thus, while we can’t guarantee that these proposed changes to Android Enterprise Recommended will make their way into the final list of requirements, we can at least confirm that Google has very recently considered these changes.

There are currently 170 different Android devices that are Android Enterprise Recommended. HMD Global, Sony, Motorola, OPPO, and of course, Google, offer devices that are AER. Even OnePlus is considering having its devices certified under the program. Well-known consumer smartphone brands aren’t the only companies selling Android Enterprise Recommended devices, though. Rugged smartphones from companies like Zebra, Honeywell, Sonim, and others are included in the program, and now even carriers can sell AER devices directly to businesses, provided they rapidly approve security maintenance releases.

The device provisioning flow in Android 10. Source: Jason Bayton

The list of requirements needed for entry into AER is not that extensive—many more Android devices could have made the list given the low base hardware requirements. Even AER’s software requirements don’t require many changes from vendors, as outlined by several internal Google documents. One of the documents outlines how vendors have to design icon badges for apps in the work profile, add a dedicated tab for work profile apps in the launcher, separate share targets for apps in the personal and work profile, preload certain Google applications, and manage cross-profile data communication. Another document outlines the UX requirements for the work profile launcher tab, work profile Quick Setting tile, work profile dialogs, launcher education messages, context switching, and other system design elements. These requirements are aimed at promoting a minimum standard of acceptable hardware as well as software UX consistency between Android Enterprise Recommended devices.

Work profile UX changes in Android 11. Left: Personal tab and work tab in Settings > App info. Right: Work app icons grayed out when the work profile is paused. Source: Google.

However, it seems that the requirement for devices to quickly get security patch updates after each monthly Android Security Bulletin (ASB) has proven to be too high a barrier for many vendors.

Google Pushes for Update Transparency for Android Enterprise Recommended

Android developer @deletescape, who recently shared a leaked draft of Google’s Compatibility Definition Document for Android 11, obtained a leaked draft of the new Android Enterprise Recommended requirements for devices running Android 11. Under the “Device Security” section, which we’ve reproduced below, Google is proposing the removal of a number of requirements for the AER program. Under these new proposed rules, AER devices will no longer be guaranteed to receive security patch updates within 90 days of an ASB. Interestingly, one of the rows in the chart suggests that Google actually tightened this requirement from 90 days to 30 days with the move to Android 10, but Google has still not updated the public list of requirements to reflect this change. Nonetheless, under the proposed changes, this requirement will no longer apply for Android Enterprise Recommended devices running Android 11. Furthermore, vendors will also no longer be required to provide 3 years of regular security updates for AER devices. They will, however, still be required to provide “Emergency Security Maintenance Release” (ESMR) updates, which presumably means they only have to roll out updates containing fixes for critical security vulnerabilities.

Android 10 versus Android 11 - Device Security Requirements for Android Enterprise Recommended

Category	Serial Number	MUST / MAY	Attribute and Implementation		Comments
			Q (Android 10)	R (Android 11)
Device Security	1	MAY	Operate an OEM Vulnerability Rewards Program (VRP)	Operate an OEM Vulnerability Rewards Program (VRP)
	2	MAY	StrongBox support	StrongBox support
	3	MAY	Hardware backed Keystore support	Hardware backed Keystore support
	4	MAY	Device ID attestation support	Device ID attestation support
	5	MAY	Key attestation support	Key attestation support
	6		30-day security updates	Requirement removed	Replaced with Security transparency requirement
	7	MUST	3 yr support for Emergency Security Maintenance Release (ESMR)	3 yr support for Emergency Security Maintenance Release (ESMR)	Replaced with Security transparency requirement
	8		File-based encryption – on by default. Uses AOSP implementation.	Requirement removed	This is a GMS requirement enforced for all devices
	9		90-day security updates	Requirement removed	Replaced with Security transparency requirement
	10		3 year security update support (may sub 3rd year ESMR)	Requirement removed	Replaced with Security transparency requirement
	11		Publish latest security patch level	Requirement removed	Replaced with Security transparency requirement

As mentioned in the chart, Google is proposing replacing a lot of these requirements with new “transparency” requirements. Indeed, Google is proposing the addition of a new section titled “Security/OS Updates transparency.” The new requirements detail how vendors will be required to publish information such as the end-of-life date for security maintenance releases, the latest security patch that’s available, how frequently the device will receive updates, what fixes are contained in each update, the shipping and planned software updates of the device, and more. Interestingly, Google is also requiring that Android 11 devices undergo certification testing by the ioXt Alliance before they can become Android Enterprise Recommended. The ioXt Alliance is an alliance of companies whose goal is to improve the security of IoT products. Its members include Amazon, Facebook, Google, NXP, and more. Google says that having this certification will add to transparency, presumably since it will give enterprises an independent metric of how secure a particular device is rather than just Google’s assurance.

Security/OS Updates Transparency (New) Requirements for Android Enterprise Recommended

Category	Serial Number	MUST / MAY	Attribute and Implementation		Comments
			Q (Android 10)	R (Android 11)
Security/OS Updates transparency	1	MUST		MUST publish following updates information on OEM website – SMR support end-date (last date when the device will receive SMR) – Latest security patch available – Frequency of updates the device will receive – Fixes contained in security patch, including any OEM-specific fixes	Changing the requirement from SMR support to SMR/patches/updates transparency
	2	MUST		MUST publish following OS information on OEM website – OS that the device is shipped with – Current major OS ver – All major OS version update that the device will receive	Changing the requirement from support to transparency eg: Pixel 3 – Shipped ver – Android 9 – Current Ver – Android 10 – Expected major ver – Android 11
	3	MUST		Submit the device to IoXT certification	IoXT scoring adds to transparency

It’s no secret that vendors have trouble keeping up with rolling out monthly security patch updates. There are many, many reasons why that’s the case: carrier certification delays, waiting for patches from chipset and other vendors, the difficulty of applying patches to heavily modified Android framework builds and out-of-tree Linux kernels, and more. Some Android users have even taken notice of how some vendors fail to meet AER requirements. While Google’s development efforts and license agreements have helped improve how quickly security updates roll out for many devices, they clearly haven’t been able to sustain the current security patch requirements for the Android Enterprise Recommended program. Loosening these requirements in favor of more transparency will both help make the program more accessible to vendors and also give enterprises more confidence in the particular device they choose for their workers.

The proposed relaxation of security patch updates isn’t the only change that could be coming to the Android Enterprise Recommended program for Android 11, of course. Google also plans to increase the minimum hardware requirements from 2GB of RAM to 3GB of RAM, tighten training requirements, and implement a new set of requirements for the work profile UX. Most of these changes won’t impact knowledge workers, though. Android in the enterprise has grown a lot since its early days. If you’re interested in learning more about its history, I recommend reading this excellent article from Jason Bayton.

The post Exclusive: Google plans to relax security update requirements for Android Enterprise Recommended appeared first on xda-developers.

from xda-developers https://ift.tt/3899dyD
via IFTTT

Download the OnePlus Wallpaper Design Contest winners

While OnePlus is busy teasing their upcoming affordable phone that could be called “Nord,” the company has been running a wallpaper contest on the community forums. The “Creative Wallpaper Contest” started in May and the winners have just recently been announced.

The rules of the contest said that the wallpapers should be made with the OnePlus 8 series in mind. The OnePlus 8 and 8 Pro feature single hole-punch display cutouts in the top left and a 2400×1080 resolution and 3168×1440 resolution respectively. Since these wallpapers were made in 3168×1440 resolution to match the high-resolution display of the OnePlus 8 Pro, these wallpapers should look nice on other Android smartphones as well.

OnePlus 8 Forums ||| OnePlus 8 Pro Forums

Five winners were selected in total, with one overall winner getting the top spot. Here are the winners:

1.  @Butch_Sales_ES (Entries)
2. @Daniel Franke (Entries)
3. @m4ngosteen (Entries)
4. @Sylvester.David (Entries)
5. @Gio567full (Entries)

The two wallpapers from the overall winner and the 15 wallpapers from four of the other winners have been shared on the OnePlus Forums in their full-resolution glory. Several of the wallpapers feature the “Never Settle” and OnePlus logo, but not all of them do. There’s a good variety to choose from, some going with photo-realistic elements, others more abstract, and some with an illustration. Check out the preview gallery below to see if there’s anything you like and download the ZIP file below for the full-resolution images.

Download OnePlus Wallpaper Contest winners ZIP

The post Download the OnePlus Wallpaper Design Contest winners appeared first on xda-developers.

from xda-developers https://ift.tt/2Vm0UKE
via IFTTT

Exclusive: 3 of Android 11’s best features won’t be available on every device

Every year, Google releases a new version of the Android operating system. Google released the first Android 11 Developer Preview back in February followed by the second, third, and fourth developer previews over the last few months. Earlier this month, Google unveiled the first Android 11 Beta and talked in-depth about the best features for users to enjoy and for developers to implement. However, we’ve now learned that three of the top features in Android 11 won’t be available on every Android device.

To understand how that’s possible, we have to briefly explain how the Android OS is distributed from Google to smartphone device makers. Android is an open-source operating system licensed under Apache 2.0, meaning that anyone, from indie developers to big companies, is free to modify and distribute the OS on their own devices. Most of the new OS features that Google unveiled for Android 11 will be part of the Android Open Source Project (AOSP) that smartphone device makers base their own software on, but the Apache 2.0 license, as I mentioned before, lets anyone modify the software as they see fit. In order to maintain consistency in APIs and platform behavior between Android devices, Google bundles the distribution of Google Mobile Services (which includes applications and frameworks like the Google Play Store and Google Play Services) with license agreements mandating that devices adhere to the rules under Google’s “Android Compatibility Program” (among other requirements). The Android Compatibility Program consists of multiple automated test suites and a set of rules enumerated in the Android Compatibility Definition Document (CDD).

In the CDD, Google lists software and hardware features that device makers “MUST” implement, are only “STRONGLY RECOMMENDED” to implement, or “SHOULD NOT” implement. If a feature is listed as “MUST” implement, then the device maker has to add that feature or they can’t ship Google apps on their devices. If a feature is listed as “SHOULD NOT” implement, then the device maker can’t add that feature or they can’t bundle Google apps. Finally, if a feature is listed as “STRONGLY RECOMMENDED,” then it’s up to the device maker whether or not they want to implement the feature. The CDD is a constantly changing document, even before its publication every year following the public release of a new Android version. Google frequently updates the document to remove features, change the language to be clearer, and relax requirements based on feedback from its partners. However, once Google makes a CDD public for a particular Android version, those requirements will be set in stone for Google-certified devices running that Android OS version.

The Android 11 CDD won’t become public until later this year, likely in early September. However, developer @deletescape shared a pre-release copy of a document that details changes coming to the CDD, giving us an early look at how Google is shaping Android 11 across the ecosystem. The vast majority of the over 60 changes to the CDD aren’t very interesting to users—they describe how device makers have to implement certain APIs, declare certain features, and implement certain kernel features. However, 3 of the changes to the CDD caught our attention because they relate to some of the most interesting features in Android 11. Here’s what we uncovered.

Device Controls

Device Controls is a feature in Android 11 that allows for smart home automation controls to be shown in the power menu. You can turn off your lights, open your garage door, start your vacuum cleaner, change your home’s temperature, and do much more without opening up a dozen different smart home apps. Google added APIs that developers of smart home apps can use to surface controls in the power menu. We think this is a neat feature that finally brings your smartphone into the smart home. Unfortunately, there’s no requirement for OEMs to actually implement it. If an OEM thinks the feature is lame or they want to go a different route (such as only allowing smart home controls from devices in their own ecosystem), then they can simply disable support for Device Controls.

When Google first added Device Controls to the CDD on February 25th, 2020, they mandated its inclusion by adding a “MUST” requirement in Section 2.2.3 – Handheld Software Requirements. However, on May 20th, 2020, Google updated the text to remove the proposed “MUST”. The new Section 3.8.16 – Device Controls outlines how the feature has to be implemented but does not actually require that it be implemented in the first place! We hope OEMs won’t disable this nifty feature, but there’s no way for us to know if they have disabled it until they’re ready to unveil their own flavors of Android built on top of Android 11, which won’t happen until several months from now.

Proposed Section 3.8.16 (New) - Device Controls (Updated 5/20/2020)

3.8.16 Device Controls

Android includes ControlsProviderService and Control APIs to allow developers to publish device controls for quick status and action for users.

3.8.16.1 Device Controls User Affordance

If devices implement Device Controls, then they:

• [C-1-1] MUST report the android.software.controls.feature flag to be TRUE
• [C-1-2] MUST provide a user affordance with the ability to add, edit, select and operate the user’s favorites from the controls registered by the 3rd-party apps through the android.service.controls.ControlsProviderService and the android.service.controls.Control APIs.
• [C-1-3] MUST provide access to this user affordance within three interactions from the Launcher
• [C-1-4] MUST accurately render in this user affordance the name and icon of each 3rd-party app that provides controls via the android.service.controls.ControlsProviderService API as well as any specified icon, status text , device type, name, structure, zone, custom color, and subtitle provided by the android.service.controls.Control API

Conversely, If device implementations do not implement such controls, then they

• [C-2-1] MUST report Null for the ControlsProviderService and the Control APIs.

Conversations in Notifications

Conversations in Android 11. Source: Google

One of Android’s biggest advantages compared to iOS is how the former handles notifications. That gap in usability will get even wider in Android 11 with the introduction of “Conversations.” In Android 11, notifications from messaging apps are grouped together and are shown in a separate section in the notification panel above most other notifications. This lets you quickly see and respond to messages without having to scroll through all your other pending notifications. Unfortunately, this nifty change to notifications may not be available on all devices. Google is giving OEMs the option to choose whether they want to “group and display conversation notifications ahead of non-conversation notifications.” OEMs frequently customize the notification panel, and so it’s no surprise that Google is giving OEMs a choice here. Still, it’s unfortunate that Google isn’t choosing to enforce more consistency in notifications in Android 11.

Proposed changes to Section 3.8.3.1 - Presentation of Notifications (Updated 4/08/2020)

If device implementations allow third party apps to notify users of notable events, they:
…
Android R introduces support for conversation notification, which is a notification that uses NotificationManager.MessageStyle and provides a published People Shortcut ID.

Device implementations are:

• [H-SR] STRONGLY RECOMMENDED to group and display conversation notifications ahead of non conversation notifications with the exception of ongoing foreground service notifications and importance:high notifications.

If conversation notifications are grouped into a separate section, device implementations

• [H-1-8] MUST display conversation notifications ahead of non conversation notifications with the exception of ongoing foreground service notifications and importance:high notifications.

Device implementations are:

• [H-SR] STRONGLY RECOMMENDED to provide access to the following actions from conversation notifications: display this conversation as a bubble if the app provides the required data for bubbles

The AOSP implementation meets these requirements with the default System UI, Settings, and Launcher.

IdentityCredential – Mobile Driver’s Licenses

Finally, one of the features that I’m most excited about is the IdentityCredential API. As we detailed last year, the IdentityCredential API is designed to allow applications to store identity documents, such as mobile driver’s licenses, on the device. Several countries (and some U.S. States) around the world already allow their citizens to store their driver’s licenses in a mobile app. However, Google is working to make this more secure by having the data stored offline in a secure environment.

A sample image of a digital driver’s license accessed through the LA Wallet app. Source: Envoc

The source code for Android 11 includes the IdentityCredential API (which developers will call to store identity documents in the phone’s secure environment) and the IdentityCredential HAL (which interfaces with the phone’s secure environment), but OEMs are not required to implement them. When Google first proposed the inclusion of IdentityCredential in the CDD on January 10, 2020, they listed it as a requirement. However, they relaxed this requirement on March 18, 2020, and now only strongly recommend that OEMs support this feature. We’re not surprised that Google relaxed this requirement—adding a change that impacts the trusted execution environment will require effort from OEMs to implement. It’s possible that OEMs simply need more time to get ready for this change. For users, though, that means there’s no guarantee your particular Android 11 smartphone will support securely storing a mobile driver’s license in the phone’s secure environment.

We should note that there’s no technical limitation preventing the widespread adoption of the IdentityCredential system among Android 11 devices. One of the requirements for implementing the IdentityCredential system is that the device has a Trusted Execution Environment (TEE) or a dedicated secure processor in which a “trusted application” interacts with the stored identity documents. Since Android 7.0 Nougat, Google has required all modern Android devices to support an “isolated execution environment” (per Section 2.2.5 – Security Model in the CDD). Devices with ARM processors typically feature ARM’s TrustZone TEE, and Google provides the Trusty OS that runs on TrustZone. The presence of a TEE is enough to support the IdentityCredential system, though it would be more secure if the credentials are stored in an embedded secure CPU (such as in the Secure Processing Unit of some Qualcomm Snapdragon processors) or a discrete secure CPU (such as in Google’s Titan M or Samsung’s new security chips). Notably, devices with discrete secure CPUs may also be able to support the “Direct Access mode” feature of the IdentityCredential system, which will allow the user to pull up their identity document even when there isn’t enough power left in the device to boot up the main OS.

Proposed Section 9.11.3 (New) - Identity Credential (Updated 3/18/2020)

The Identity Credential System allows app developers to store and retrieve user identity documents.
Device implementations:

• [C-SR] are STRONGLY RECOMMENDED to implement the Identity Credential System.

If device implementations implement the Identity Credential System they:

• [C-0-1] MUST return non-null for the IdentityCredentialStore#getInstance() method.
• [C-0-2] MUST implement the `android.security.identity.*` APIs with code communicating with a trusted application running in either a Trusted Execution Environment (TEE) or on a dedicated secure processor. The trusted application must be implemented such that the Trusted Computing Base for the Identity Credential System does not include the Android Operating System.

Google is also working on an IdentityCredential Jetpack library to make it easier for developers to add support for securely storing identity documents on Android, but the real challenge will be getting governments to authorize apps using this API to securely store government IDs. According to Engadget, South Korea just rolled out support for storing driver licenses in a mobile app, so we’re starting to see an uptick in acceptance for this technology. I, for one, am excited to see where this goes because it’ll mean one less thing to carry with me when I go outside.

---

The document that we obtained listed changes to the CDD by the date those changes were made. The latest changes were made on June 10, 2020, which means that the document that we have is fairly up-to-date. It’s possible that Google could renege on these changes and make them all requirements again before the public release of Android 11, but we doubt Google will all of a sudden make the CDD more stringent. These changes were likely relaxed due to feedback from OEMs who are the ones that will have to go back and implement these features if they weren’t already planned on doing so. That takes time, effort, and money, which would just delay the release of Android 11 for non-Google devices even further. Still, if Google does make these features required once more, we’ll post an update on the XDA Portal.

The post Exclusive: 3 of Android 11’s best features won’t be available on every device appeared first on xda-developers.

from xda-developers https://ift.tt/3dAOJ2U
via IFTTT

Here are the countries using Google and Apple’s COVID-19 Contact Tracing API

The novel coronavirus, also known as SARS-CoV-2, has wreaked havoc across the world. Many countries shut down large parts of the economy in order to contain the spread of the virus. As countries reopen their economies, many health experts fear a “second wave”, ie. resurgence, of COVID-19. To prevent a second wave, public health experts are advocating that nations adopt contact tracing, ie. tracing all the people who have recently come into contact with a person who has tested positive for COVID-19 and then undertaking steps to isolate those individuals. Contact tracing is difficult to implement correctly without violating an individual’s privacy. The threat to personal privacy was severe enough for Google and Apple to collaborate on an API that developers of public health agencies can use to implement app-based contact tracing solutions. This contact tracing API, which Google and Apple call the Exposure Notification API, is designed to respect user privacy and security.

Once a user downloads an app that uses the Exposure Notification API and opts in to contact tracing, their device starts generating “proximity identifiers” that are changed every 15 minutes (on average). Via Bluetooth Low Energy, these “proximity identifiers” are periodically shared with nearby devices whose users have also opted into contact tracing. The proximity identifier is then processed on-device and does not reveal information about a user’s location or other personally identifiable information. Once a user confirms a positive diagnosis of COVID-19, they can share their diagnosis with the app they installed, which will then inform other users who have come into close contact with them in the last 14 days. For more information on how the Exposure Notification API works, we recommend reading our initial coverage.

Google first rolled out the Exposure Notification API for Android devices on May 20, 2020, as part of an update to Google Play Services, but its use is restricted to apps that have been developed by official public health agencies (for obvious reasons). However, neither Google nor Apple has made details public about the list of apps that have been whitelisted for using this API, so unless you’re constantly keeping up with the news, it’s hard to know which countries have adopted the API. We’ve previously covered some of the countries that have adopted the Exposure Notification API when we talked about the various open-source contact tracing projects that are out there. In this article, we have compiled a list of official contact tracing apps from designated health agencies from various countries that are using Google and Apple’s Exposure Notification API. Our list contains COVID-19 contact tracing apps that have been released or are currently in development.

XDA’s Mishaal Rahman discovered Google’s hidden whitelist of application package names for the API. Subsequently, these package names were traced back to apps, their listing, and the countries they belong to. The information is compiled below in a table for easy reference. We have also added Google Play Store and Apple App Store links, if the app has been publicly released, as well as the source code and the official website link, wherever available. We will update this list as more countries/regions adopt the API.

Sr. No.	Nation – Region	Application Name	Android Package Name	Status of Development	Useful Links
1.	Australia*	COVIDTrace	au.gov.dta.covidtrace	In-Development	–
2.	Austria	Stopp Corona	at.roteskreuz.stopcorona	Released	Google Play Store Apple App Store Source Code Website
3.	Canada**	–	–	In-Development	–
4.	Denmark	Smittestop	com.netcompany.smittestop_exposure_notification	Released	Google Play Store Apple App Store Website
5.	Germany	Corona-Warn-App	de.rki.coronawarnapp	Released	Google Play Store Apple App Store Source Code Website
6.	Ireland	Covid Tracker	com.covidtracker.hse	In-Development	Website
7.	Italy	Immuni	it.ministerodellasalute.immuni	Released	Google Play Store Apple App Store Source Code Website
8.	Japan	COVID-19 Radar	jp.go.mhlw.covid19radar	In-Development	Source Code Website
9.	Kenya	–	ke.go.health_togethertrace	In-Development	–
10.	Latvia	Apturi Covid Latvia	lv.spkc.gov.apturicovid	Released	Google Play Store Apple App Store Website
11.	Mexico	–	mx.gob.www	In-Development	–
12.	Netherlands***	–	nl.rijksoverheid.en	In-Development	–
13.	Philippines	StaySafe PH	ph.staysafe.mobileapp	Released	Google Play Store Apple App Store Website
14.	Poland	ProteGO Safe	pl.gov.mc.protegosafe	Released	Google Play Store Apple App Store Source Code Website
15.	Saudi Arabia	Tabaud	sa.gov.nic.tabaud	Released	Apple App Store Website
16.	Switzerland	SwissCovid	ch.admin.bag.dp3t	Released	Google Play Store Apple App Store Source Code Website
17.	United Kingdom****	NHS COVID-19	–	Switching to Exposure Notifications API	Google Play Store Apple App Store Source Code Website
18.	Uruguay	Coronavirus UY	uy.gub.salud.plancovid19uy	Released	Google Play Store Apple App Store Source Code Website
19.	USA – Alabama*****	–	–	In-Development	–
20.	USA – North Dakota*****	–	–	In-Development	–
21.	USA – South Carolina*****	–	–	In-Development	–
22.	USA – Virginia*****	–	gov.vdh.exposurenotification	In-Development	–

*Australia’s existing app uses the BlueTrace protocol but the government is testing an implementation using Apple and Google’s API.

**On June 18, 2020, Canada announced its app will use technology from Apple and Google.

***According to a report from the House of Representatives of the Netherlands, an open-source app using Exposure Notification API is planned.

****On June 18, 2020, the UK announced they are switching their app to use Apple and Google’s API.

*****On May 20, 2020, the U.S. states of Alabama, North Dakota, and South Carolina announced their intentions to develop apps using Apple and Google’s API. Care19, the existing contact tracing app for North and South Dakota, will be rebranded as Care19 Diary while a new app called Care19 Exposure will be released. North Dakota Governor Doug Burgum confirmed his state will use this new app while South Dakota has not committed. Meanwhile, Virginia has not yet confirmed which API they will use for their contact tracing app.

---

Thanks to PNF Software for providing us a license to use JEB Decompiler, a professional-grade reverse engineering tool for Android applications.

The post Here are the countries using Google and Apple’s COVID-19 Contact Tracing API appeared first on xda-developers.

from xda-developers https://ift.tt/2YC0UrS
via IFTTT

OnePlus Nord could come with dual hole-punch selfie cameras

The upcoming mid-range smartphone from OnePlus has been on the horizon for several month. Initially identified as the OnePlus 8 Lite and later rumored to be the OnePlus Z, the phone may actually be called OnePlus Nord. A series of leaks and rumors have already revealed the tentative design and the specifications of the Nord. But a new report now suggests the OnePlus Nord could actually feature dual hole-punch cameras instead of the previously rumored single camera.

A OnePlus insider has divulged this information to Android Central, confirming the configuration of this camera setup. As per the report, the OnePlus Nord will feature a 32MP primary camera complemented by a secondary 8MP wide-angle camera. Notably, the OnePlus 8 and the Pro feature 16MP Sony sensors and not only will the Nord be OnePlus’ first device to feature a dual selfie camera, but it will also be the first one to use a 32MP primary sensor on the front.

Realme, another smartphone China’s BBK Electronics, recently launched the X3 SuperZoom with a 32MP + 8MP selfie cameras, comprising a Sony IMX616 as the primary sensor. It is probable that OnePlus uses the same setup for the Nord.

I can confirm the post by @AndroidCentral. The device doesn’t have a single punch hole as leaked earlier by @OnLeaks but features a dual punch hole in the top left corner.
The device by @OnLeaks was an early prototype but was canceled after all.

Via. https://t.co/cRrnBOJfdm pic.twitter.com/tWX9azY3PQ

— Max J. (@MaxJmb) June 26, 2020

Reliable tipster Max J. corroborated this report by Android Central while also claiming that OnePlus canceled the purported OnePlus 8 Lite that was leaked by another leaker known by their alias OnLeaks. At the time, OnLeaks had said that the phone was supposed to launch alongside the OnePlus 8 series but was delayed due to COVID-19.

According to my sources, that model was initially planned to be unveiled along with the #OnePlus8 series during yesterday’s event but has been postponed (at least to upcoming summer) due to #CoronaVirus situation…

— Steve H.McFly (@OnLeaks) April 16, 2020

If Max J. is to be believed, the OnePlus Nord could have a design different from the one previously rumored. Gladly we shouldn’t have to wait for long until we know since the phone is expected to launch on July 10th as per another report by Android Central.

Meanwhile, we hope there aren’t many changes to the OnePlus Nord specifications revealed in a leaked survey earlier this month. According to the survey, the mid-ranger will be powered by a Snapdragon 765G mobile platform and feature a 6.56-inch AMOLED display with a 90Hz refresh rate. The phone is likely to come with a 4,300mAh battery along with 30W. The same survey, however, also hints a 16MPsiingle hole-punch camera on the front and that makes us be unsure in its authenticity.

We hope to learn more about the OnePlus Nord and as we do, also share those details with you. What do you expect from the upcoming mid-range smartphone? Let us know in the comments below.

Disclaimer: Featured image is a concept render by the author based on the rumors; not an actual phone.

The post OnePlus Nord could come with dual hole-punch selfie cameras appeared first on xda-developers.

from xda-developers https://ift.tt/2NyV8RO
via IFTTT

Get Lifetime Online Protection with this Highly Rated VPN and NAT Firewall for $49.99

There are many different VPN providers to choose from nowadays. Some are cheap and lackluster, while others charge a ridiculous amount each month. If you would like to find a solution that delivers the protection you need at a price that won’t set your wallet on fire, try Ivacy VPN. This highly-rated service offers fast connections, strong security, and a strict no logging policy. You can currently pick up a lifetime subscription for just $49.99 via the XDA Developers Depot, with NAT Firewall protection thrown in.

Whether you want to shake trackers off your tail, bypass local restrictions, or secure your connection, Ivacy VPN has you covered. Rated at 5 stars by BestVPNProvider, this service disguises your IP address and location to make you truly anonymous online. 

With 450 servers in more than 100 locations around the world, Ivacy VPN helps you avoid those “not available in your region” messages when browsing for content. This VPN also supports P2P sharing, with unlimited bandwidth. It works on phones, tablets, computers, games consoles, and streaming boxes, with a dedicated add-on for Kodi users.

Ivacy VPN has a strict no-logging policy, while AES-256 encryption helps ensure your connections remain private — even on public Wi-Fi. The included NAT Firewall helps you avoid other threats, including hackers and malware. One Ivacy VPN subscription also covers up to five devices at the same time.

This lifetime bundle is worth $1,254, but you can get your subscription now for just $49.99.

 

Ivacy VPN: Lifetime Subscription + NAT Firewall – $49.99

See Deal

Prices subject to change 

The post Get Lifetime Online Protection with this Highly Rated VPN and NAT Firewall for $49.99 appeared first on xda-developers.

from xda-developers https://ift.tt/2CJzIPI
via IFTTT