mercredi 22 février 2017

Applications for Google I/O 2017 Tickets Now Live

For all developers interested in attending Google’s famous I/O ‘developer festival’ in 2017, applications to secure tickets have begun today, with the application period closing at 5pm PST on February 27th. The conference will begin in a bit less than three months from now and will run for three days as usual, from May 17th to May 19th.

Similar to past I/Os, applicants will be chosen through a random lottery, the results of which are to be announced on February 28th. Tickets are $375 for active full-time students, professors, faculty, or staff of any high school or higher education institution, and $1,150 for all other interested parties. Continuing Google’s tradition of inclusivity for all interested in technology, I/O extended events outside of the actual conference may also be submitted here. In 2016, more than 600 Google-recognized Extended events occurred alongside the I/O conference in Mountain View. Anyone unable to attend in California can check back at the I/O 2017 website later this year for a list of all Extended events.

I/O 2017 will once again take place outdoors at the beautiful Shoreline Amphitheater in Mountain View, California. Google recommends bringing sunglasses and sunscreen, sage advice for summertime California. Free Google shuttles will be available for all developers staying at Google’s list of recommended hotels, and there will of course be public transportation for those staying elsewhere.

Shoreline Ampitheatre seen at I/O 2016. (Google)

What To Look Forward To

There are an array of exceptionally exciting things all attendees (and anyone else, for that matter) potentially have to look forward to at this year’s I/O sessions. 2016 saw Google announce and discuss a number of exciting developments, ranging from the announcement of Android Nougat and an exploration of Google Assistant, to Android Wear 2.0, Google’s Daydream VR platform, and Allo/Duo. 2016 and early 2017 have sadly seen an underwhelming Android Wear 2.0 release, as well as the withering performance of the Allo messaging platform, not to mention the broad selection of awesome endeavors Google has since shut down (Project Ara, Google’s self-driving branch, and the Titan UAV aspect of Project Loon) or drastically scaled back (Google Fiber and possibly Project Loon) as an apparent result of rather overt profit and growth-seeking. On a more positive note, Google released their much-anticipated (semi) in-house smartphone, the Pixel, to considerable acclaim and unexpectedly high demand. Thankfully, this has translated into a small financial success for Alphabet, likely ensuring that the Pixel will have a future – and a bright one at that – at Google.

Looking ahead, Google can be primarily expected to announce Android O or what’s coming in Android’s future, and will also likely discuss the future of Android Wear, Daydream and virtual reality ventures in general, Google Assistant, and more. There is also arguably a good chance of some form of teaser of the future of Google’s Pixel brand and pursuit of in-house hardware. Far less likely but possibly even more thrilling is a minuscule chance of Google offering developers a first look at its in-house custom silicon development, which Google’s head of Android engineering himself said would likely appear in a future Pixel device.  Given that CEO Sundar Pichai revealed that Google had developed its own application-specific silicon for neural networks at last year’s I/O, there is definitely a better chance than ever before that more details on in-house silicon efforts may be provided. This even still ignores the fact that Google is already heavily involved in optimizing ARM SoCs for Chromebooks, as well as carefully examining nearly all hardware aspects of devices that are to run Chrome OS. Hedging towards being even still less likely are announcements regarding the oft-discussed Android-cum-desktop Andromeda OS that Google has been repeatedly rumored to be developing. All of this is speculation, but we will most definitely get some good treats (and perhaps a taste of a new Android dessert)in May.

All disappointing Google developments from 2016 and 2017 aside, there will no doubt still be a great deal of intrigue and excitement to be found at 2017’s I/O.

Google I/O 2017

from xda-developers

Gmail v7.2 Prepares to Add Support for S/MIME Enhanced Encryption

If there’s one lesson everyone learned thanks to a certain high profile election, it’s the importance of e-mail security.

Gmail is the most widely used e-mail service in the world, and thanks to Google’s stranglehold on smartphones, its Android application is perhaps the most common way people read and send their e-mails. Thus, it is critical that we keep our data safe and secure from would-be thieves, whether it be through the use of a secure lockscreen method, keeping our phones up to date to avoid exploitation, and finally avoiding sending any important information over unsecured networks.

Unfortunately, even if you yourself do your due diligence in keeping your private data safe, you can’t guarantee that other people you correspond with are doing the same. If another person’s e-mail account is hacked, how do you know that the person messaging you is actually them and not a malicious third-party? While you might be able to recognize obvious spam from a hacked account, more malicious, sophisticated attempts might be harder for you to detect. If your friends and family start using S/MIME certificates in their outgoing messages, you will know that it was them who actually sent the e-mail.

Understanding S/MIME. (Credits: Microsoft)

S/MIME is an enhanced level of e-mail encryption that is available on the web-based version of Gmail, and it is indicated by the green padlock symbol on messages. For a while, users of the Android app could only send messages over the default TLS encryption (enabled by default), but in version 7.2 of the Gmail application, it appears that support for sending messages with this enhanced S/MIME encryption may soon be supported.

Although a teardown can provide valuable information regarding upcoming features, it is entirely possible that these features may not make their way into the final product. Do not take these teardowns as proof that a feature will be added, but rather as a hint of what could be coming.

Enhanced Encryption with Gmail

Hidden within the APK file of the latest Gmail update are a bunch of strings that clearly point to the inclusion of S/MIME encryption support.

Enhanced Encryption (S/MIME) Support

<string name="fz_enhanced">Enhanced encryption (S/MIME)</string>
 <string name="fz_signature">Verified email address ^1</string>
 <string name="fz_signature_missing">The digital signature is missing.</string>
 <string name="fz_more_info">More info</string>
 <string name="fz_from_details_title">Digital signature</string>
 <string name="fz_from_details_row1">Issuer:</string>
 <string name="fz_from_details_row2">Validity:</string>
 <string name="fz_from_details_column2" formatted="false">%s - %s</string>
 <string name="fz_dialog_title_initial">Gmail protects your messages during delivery</string>
 <string name="fz_dialog_message_initial">As you add people to this message, this icon will let you know your message is secure. ^1</string>
 <string name="fz_dialog_title_enhanced">Your message will be secure during delivery</string>
 <string name="fz_dialog_message_enhanced">"All recipients use services that support enhanced encryption. With enhanced encryption, your message can't be read until delivered to recipients' inboxes. ^1"</string>
 <string name="fz_dialog_title_standard">Your message will be sent with regular security</string>
 <string name="fz_dialog_message_standard">All recipients use services that support standard encryption. ^1</string>
 <string name="fz_details_header_enhanced">Enhanced encryption supported</string>
 <string name="fz_details_header_standard">Standard encryption supported</string>
 <string name="fz_details_header_message">No recipients</string>
 <string name="fz_details_supported_message">Supported by %s</string>
 <string name="fz_details_header_settings">Encryption and signature</string>
 <string name="fz_details_settings_e_title">Enhanced encryption</string>
 <string name="fz_details_settings_e_subtitle">With digital signature</string>
 <string name="fz_details_settings_s_title">Standard encryption</string>
 <string name="fz_details_settings_s_subtitle">No digital signature</string>
 <string name="fz_cert_error_0">Certificate is invalid</string>
 <string name="fz_cert_error_3">Certificate expired on %s</string>
 <string name="fz_cert_error_4">Certificate was revoked on %s</string>
 <string name="fz_failure_title">This message could not be decrypted.</string>
 <string name="fz_failure_subtitle_user">Please check your settings on desktop Gmail to confirm that your private key has been uploaded.</string>
 <string name="fz_failure_subtitle_admin">Please contact your administrator to confirm that the proper keys have been set up correctly.</string>
 <string name="fz_icon_content_description_standard">Message encrypted.</string>
 <string name="fz_icon_content_description_enhanced">Message enhanced encrypted.</string>

As you can see, Gmail will show when all recipients support S/MIME encryption (or when they don’t). This will be shown by the aforementioned green padlock icon, similar to what is shown on the desktop Gmail. When you first send an enhanced encryption message, you will see a dialog letting you know that S/MIME is being used. If your certificate is invalid, expired, or revoked, you will also be notified of this. For now, private keys will still have to be uploaded by your network administrator on the desktop Gmail app.

A couple of new layout files have also been added in this update, which rule how this feature will be implemented in the app. They are fz_details.xml, fz_failure.xml, fz_details_item.xml, fz_details_divider.xml, and fz_failure_background.xml.

<?xml version="1.0" encoding="utf-8"?>
<ExpandableListView android:id="@id/fz_details_listview" android:paddingTop="8.0dip" android:paddingBottom="8.0dip" android:clipToPadding="false" android:layout_width="fill_parent" android:layout_height="wrap_content" android:listSelector="@android:color/transparent" android:groupIndicator="@null" android:divider="@null"
 xmlns:android="" />
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout android:orientation="horizontal" android:id="@id/fz_failure" android:background="@drawable/fz_failure_background" android:visibility="gone" android:layout_width="fill_parent" android:layout_height="wrap_content" android:layout_marginLeft="@dimen/fz_failure_margin_side" android:layout_marginTop="@dimen/fz_failure_margin_vertical" android:layout_marginRight="@dimen/fz_failure_margin_side" android:layout_marginBottom="@dimen/fz_failure_margin_vertical"
 <ImageView android:src="@drawable/quantum_ic_lock_grey600_24" style="@style/Fz.Failure.Icon" />
 <LinearLayout android:orientation="vertical" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_margin="@dimen/fz_failure_margin">
 <TextView android:text="@string/fz_failure_title" style="@style/Fz.Failure.Text.Title" />
 <TextView android:id="@id/fz_failure_subtitle" style="@style/Fz.Failure.Text.Subtitle" />
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent"
 <include android:id="@id/fz_details_item_divider_top" layout="@layout/fz_details_divider" />
 <include android:id="@id/fz_details_item_main" layout="@layout/ces_details_item" />
 <include android:id="@id/fz_details_item_divider_bottom" layout="@layout/fz_details_divider" />
<?xml version="1.0" encoding="utf-8"?>
<View android:background="@color/divider_color" android:visibility="gone" android:layout_width="fill_parent" android:layout_height="1.0dip"
 xmlns:android="" />
<?xml version="1.0" encoding="utf-8"?>
 <solid android:color="@color/quantum_grey100" />
 <corners android:radius="2.0dip" />

We’ll keep on the lookout for hints at upcoming features in Google app updates as they roll out, so keep an eye out on our portal for more APK teardowns.

from xda-developers

OnePlus 3T Gaming Analysis & Review: The Phone to Beat in 2017

When I reviewed the OnePlus 3T, I lightly touched upon its gaming performance, noting that it was similar to what I found on the OnePlus 3. Since then, a few factors have led me to properly test the gaming performance of this device, with the results of my analysis published below.

With 2017 flagships fast approaching, I needed a new baseline to compare and contrast both the new implementations of old chipsets, as we’ll find on the LG G6 and HTC U Ultra, and the upcoming devices running new processors, including the Snapdragon 835 and Exynos 9 series. I’ve written positively about the OnePlus 3T’s real-world performance in the past, explaining some of the under-the-hood changes and tweaks that make the result user experience so smooth and sleek. When it comes to gaming, one would expect the OnePlus 3T to lead Android as it packs the most powerful GPU on a phone, at the highest clockspeed we’ve seen on such GPU, flanked by copious amounts of RAM and running a relatively light-weight ROM. However, a recent original report by XDA further strengthened the idea of the OnePlus 3T as a great phone for mobile gaming, even if that meant making a big mistake in other areas.

When Cheating is Oddly Beneficial

In the interest of keeping the introduction of this review short, I will keep this section brief though I do suggest you check out the full investigation. In short, I found that OnePlus had been cheating on benchmarks through a mechanism introduced into Oxygen OS in the community builds, possibly as a result of the merging of the disparate development teams the company had up until late last year. The OnePlus 3 and OnePlus 3T’s stock ROMs (Oxygen 4.0.1) would detect a specific package, which we found in a manifest through a ROM dump, and then configure the processor scaling and thermal throttling threshold to maximize the chance of a high score on any given benchmark. This is different than previous cheating mechanisms by other OEMs, which essentially amounted to setting a ‘performance’ governor to max out clockspeeds for the duration of the test — OnePlus’ cheating mostly minimized variance by effectively having the processors stay at mid-to-high frequencies regardless of the load at hand, which especially bumped less-intensive tasks that didn’t call for quick and short bursts of performance.

Furthermore, such mechanism wasn’t limited to benchmarks only — some games were also affected and benefit from the performance changes. I’ve confirmed so in my testing, as some games such as Asphalt 8 do display similar behavior to what I found on benchmarks, even while idle or under minimal load. While the changes made to bump benchmark scores are duly considered cheating, the changes made to the phone’s behavior under games does have the benefit of increased framerate, something tangible and useful to the user. As a result, the OnePlus 3T is a better phone as far as gaming is concerned, although problems do arise from such a setup. For one, only games chosen by OnePlus get this added benefit, and this list might become outdated. Moreover, it might result in inconsistent performance, where one game might be underperforming while other similarly-demanding games get the privilege of relaxed throttling and higher clockspeeds on average. Nevertheless, having such boost is a net positive in my view, even if it’s not universal — it’s not like the device suffers from botched frequency scaling that would necessitate specifically targeting games with a performance mode in the first place.

Suggested Reading: OnePlus 3 and 3T Storage Speed Differences Under F2FS

Finally, one last factor specific to the OnePlus 3 and OnePlus 3T is the adoption of F2FS as a filesystem for users running Nougat. We’ve detailed what F2FS is, how it is enabled and what difference it makes in a previous article, but for those short of time, the change to F2FS enables the OnePlus 3T to reach higher read/write speeds on its UFS 2.0 storage chip. In turn, this increases the loading time of applications, and the result is most notable in heavy games with long loading times — it can cut the opening speed of games like Asphalt 8 by as much as 50%, and it ultimately puts it ahead of competitors while loading games or levels within games.

A Quick Word on Methodology and Understanding Results

The data for these articles has been gathered using Gamebench, a real-world performance measuring tool. The samples range from 10 to 30 minutes depending on the game and the variations I saw within testing at my discretion. Every run began at an outside temperature of 28°C | 82.4°F at the location of the chipset, from idle, with minimal background services (every other app disabled). Some games have a framerate cap of 30, while others have a framerate cap of 60 — in the case of Asphalt 8, the game is capped at 30 but the menus run at 60FPS. All games were tested at their maximum possible settings for both resolution (1080 x 1920) and textures/effects, looping the first level (or act) of the game. Finally, do note that loading times often introduce huge drops in framerate manifested in the graphs, which do weigh down the resulting average (though not by much) — when you see a drastic momentary drop to a near halt in these graphs, you are most certainly looking at a loading screen.

Asphalt 8 — [AVG: 30FPS]

This game is probably most famous for its graphics, something that almost every reviewer has noted at some point. You likely saw this game being played on phones within YouTube videos, or read it was listed in a “Top 10 Graphics on Android” article — that said, Asphalt 8 is not quite as impressive – nor demanding – as it used to be. It was a few years back when Gamebench itself crowned the Note 4 the king of Android gaming for its ability to nearly-sustain 60FPS on Asphalt 8. My Note 4, months later, could only top 30 as they later introduced a framerate cap (for a while, it wasn’t even a universal one). Truth be told, Asphalt 8 is still a good looking game, but most devices with a GPU equivalent to an Adreno 420 or better have no trouble hitting that ceiling. The OnePlus 3 is no exception, but it does surprise in other ways.

The device manages to consistently average 30 frames per second with very, very few dips along the road. The graphics quality of Asphalt 8 has indeed increased slightly over the years, and it does feature a significant number of great-looking levels, some with even more demanding environmental effects such as rain. I played the famous first level for a total of 30 minutes, and found the experience to be as pleasant as it can be. It is true that Asphalt 8 is specifically targeted by OnePlus (in fact, it’s the one game I know for OnePlus tests at their lab) for higher framerates, and while the lift of thermal restrictions could easily have turned a more-demanding game into a reminder of why we disliked the Snapdragon 810, I was pleasantly surprised by the thermal consistency and ultimately-decent temperature as well.

Throughout this session, the device hit a peak of 41°C | 105.8°F near the housing of the processor — this is hardly a problem, and while the device starts feeling warm at that point, it doesn’t quite reach the 44°C | 111.2°F to 46°C | 114.8°F I experienced with the OnePlus 2, a far worse offender. The sides of the OnePlus 3T did feel slightly hotter than I anticipated, but surprisingly, the overall heat was intangible when I repeated this test with a case, at no loss in performance.

As shown above, the game utilizes a lot of filters, effects and bloom to mask its bland textures and some boxy models; Asphalt 8 is impressive in motion, but looks shoddy and muddy in still frames.The most extensive frame dips never put it under 24 frames per second while in game, and these often came as a result of extreme collisions. GPU utilization never quite reached 90 percent, either, but it ranged from 50 to 85 while the CPU took a back place, hovering between 10 and 35. This will become more telling as we examine the results obtained by other devices.

Overall, though, Asphalt 8 plays beautifully on the OnePlus 3T, though that’s not exactly a spectacular endorsement given that this game has no trouble running properly on less-powerful devices (even if not for such long periods of time).

Dead Trigger 2 — [AVG: 55FPS]

This is also a very popular and great-looking game, and a sequel to yet another graphics powerhouse. Built on top of the Unity Engine, Dead Trigger 2 offers a myriad of effects, sharp textures, spectacular lighting for a mobile game, and good looking character and weapon models. While the game itself might be bland, its graphics are definitely quite taxing on smartphones, and while it does offer enhanced graphics for specific devices, the ultra settings on the OnePlus 3T were taxing enough to actually see some frequent dips I didn’t find on other titles.

Looping 30 minutes of the first fetch mission after the tutorial, I got to experience some patterns that are telling of when the game runs best, and where the OnePlus 3T fails most. Interestingly enough, the beginning of the level was the most unsavory in every one of the 15-some continuous runs, with the framerate dipping as low as 40 very consistently. I presume this is due to the unnatural amount of bloom and the many reflections on the puddles; going inside the first buildings sees a much better framerate almost immediately. In general, the entire interior area of the level sees great framerate, with dips only happening whenever the many zombies accumulate in areas with various environmental effects.

One area in particular was by far the worst of every run, a long hallway with intense lighting effects and half a dozen enemies. I found that on other phones, merely looking at intense light sources would show a noticeable decrease in frames per second, but the OnePlus 3T generally handled Dead Trigger 2 very well under most conditions. The framerate average sits comfortably at 55, higher than the average of 45 to 50 I find on Snapdragon 820 devices. The short length of each level also means frequent loading screens, which further drag down that average.

However, while playing the game it’s quite clear the phone is unable to sustain a solid 60 frames per second. It’s not a terrible thing, and a framerate cap of 30 would certainly give the illusion of perfect performance. Temperatures didn’t rise past 41°C | 105.8°F, and the phone felt perceptibly hotter than when playing other games on this list. For close to thirty minutes of sustained gameplay, and considering the graphics quality the game offers, the OnePlus 3T ends up performing admirably here.

GTA: San Andreas [AVG: 30FPS]

Grand Theft Auto games have been getting ported to Android for the past few years up until San Andreas; with no likely port of GTA IV anytime soon, this remains one of the best-looking and certainly most expansive sandbox games on Android. The game is chock-full of content and activity, with tons of traffic (set to highest for the purpose of this test),  angry pedestrians, and action to be had should you run over the wrong crowd. While the game doesn’t look nearly as good as others down this list, the amount of things going on at any given moment and scope certainly contribute to its tax on the processor. It wasn’t until the Exynos 7420 on the Note5 – an exceptional phone for the price – that I could reliably achieve the framerate cap when testing for extended periods of time (by comparison, the OnePlus 2 completely failed this test).

The OnePlus 3T does a remarkable job with a sustained average of 30 frames per second. There were some choke-points, namely when activity grew too extreme at a three-stars wanted level. Heavy car collisions that ‘dominoed’ into multiple vehicles would consistently knock the game out of its framerate cap, and the same went for chained explosions (yet not individual explosions, only those that interacted with the gameworld). Busy areas with long, far-away view distances and many NPCs could also strain the framerate almost as much as the action upon arriving to the area. These framerate drops were always short lived, though, as seen in the graph above. In the end, gameplay was quite smooth and as good as I’ve ever had it on a modern smartphone. However, some caveats to note are that it is ultimately capped at 30 frames per second, and at maximum resolution it is still “only” running at 1080p.

Nuance aside, the game didn’t heat the device past 40.5°C | 104.9°F. Looking at the GPU and CPU load graphs, we find that the game does call the CPU more than other games we tested for this article, with the major spike near the 2:30 mark correlating with a large chained explosion which made itself known in the framerate as well. This is a good port overall, though not without bugs — almost every device I’ve played it on in 2016 and 2017 have issues with polygons spazzing out accross the screen, and I had a few early crashes before I managed a smooth-sailing run.

Warhammer 40K: Freeblade — [AVG: 59FPS]

It wasn’t long ago when we started testing Warhammer 40K: Freeblade for the gaming sections for reviews, but it has quickly turned into one of my favorite games to test. It’s visually stunning for a mobile game, though it does make use of a fair few tricks to achieve its graphics fidelity. While environments are well-textured and the game looks quite sharp, there is a very low polygon count on everything but character and NPC models. This is what the game puts front and center, too, and it’s no coincidence that both your personal mech and the main enemies take large portions of the screen, with camerawork during fights emphasizing the modelling and texturing of these well-crafted designs.

After going through the first track of the campaign – a rather homogeneous environment located in an urban setting, perfect for testing endurance over time – I received a rather consistent framerate as shown in the graph. The dips of around 5 frames per second most frequently came during the explosive arrival of new enemy hordes and vehicles, with quick stabilization even during the firefights. The smoothest portions of gameplay were actually the one-on-one fights against other mechs, which involve low-intensity quick-time events while locking the player into an impressive fight that showcases every detail, as shown below.

There’s not much else to say: the game allows for quite a few graphics settings which I maxed, including lifting the framerate cap from 30 to 60. The resulting framerate average is exceptional, although it wasn’t maintained perfectly throughout the session as you can see. That said, I personally perceive the dips in gameplay only when the difference is of 20 frames per second or higher in a short time interval, with jumps from 60 to 30 or lower being particularly jarring. Nothing in my sample suggests the OnePlus 3T has issues with this game, though, and the outside temperature was quite lower than on other titles at just 40°C | 104°F flat after 10-minute sessions.

Riptide GP2 — [AVG: 51FPS]

Last but not least, we have Riptide GP2, a game you might also have seen in video reviews or listicles. The watersport cousin of Asphalt 8 does indeed feature excellent graphics with a healthy amount of granularity under “Advanced Settings”, featuring tons of effects and reflections, with substantially less use of cheap tricks to mask its imperfections. The game’s physics also do a convincing job at simulating waves and the waterbike’s behavior, making for satisfactory gameplay. Detailed models, crisp textures and very complex environments with detail, long distances and many moving objects make this game a graphics crown jewel and a good performance benchmark.

Unfortunately, this is where the OnePlus 3T performed the worst in, although it still managed to output a respectable 51 frames per second average in the end. This is nearly a pixel-perfect average of what I perceived in game, as looping the first level had me fluctuating between 40 and 60 frames per second extremely consistently; every lap had framerate dips at the same specific segments, which didn’t offer particularly different visuals than the rest of each level. However, I speculate that what really bogged down performance was the draw distance and the amount of objects on the screen, as after turns revealing large straight sections of the track, fluidity took a hit every time. This is compounded by the amount of large structures with many moving elements found in some of these segments, and by the end of my 30 minute session I had the timing and location of these heavy areas memorized to a T.

I didn’t see much of a drop in performance over time, although the specific laggy areas – particularly at the beginning (or end) of a lap – did start dipping below 40 after 15 minutes of gameplay or so. That said, and as shown in the graph, the framerate is still somewhat consistent. Outside temperature of the device managed to reach 41°C | 105.8°F, making it one of the more uncomfortable games, though not by much.

Dash Charge — Play While Charging

Another small advantage worth mentioning is Dash Charge, OnePlus’ new charging protocol. Not only is Dash Charge fast, being able to fully charge a device in less than an hour and a half, but it’s also different to other charging standards as it does not throttle if you use the phone while charging it. This is specially useful in some real-life scenarios such as airports or even driving (getting more juice out of your GPS-guided commute), but it also applies to games as well. In an in-depth analysis of Dash Charge, we found that playing Asphalt 8 while plugged in, at maximum brightness for 20 minutes, still charged the battery from 14% to 51%. Many OnePlus 3 or 3T owners can vouch for the efficacy of Dash Charge, and while it’s not the best perk in the world, it does help with long gaming sessions, or even regular gaming sessions, as the phone will perform as usual, heat up at similar rates (the charger itself does the heavy lifting, reaching up to 50°C | 122°F), and still giving you very similar charging speeds as if you weren’t playing the game at all. That said, I’d still be cautious, just in case.


I am very excited to see what OEMs can offer in 2017, and the OnePlus 3T will be the standard to which I’ll hold every new device this year. While the 1080p screen on the OnePlus 3T might give it an “unfair edge” against other devices with 1440p displays, many 3D games nowadays offer resolution scaling settings, and some OEM ROMs also allow you to change the resolution of the device. If they don’t, a simple adb command does the trick. For this reason, when testing 2017 flagships, we’ll analyze performance at both 1080p and, if the game allows it, 1440p as well.

Going back to the OnePlus 3T, the device is a gaming powerhouse indeed. There are some features it offers above competitors that do help mobile gaming in particular, such as the faster loading times introduced by F2FS and the unthrottled charging speeds brought by Dash Charge. It’s also true, though, that OnePlus introduced more aggressive processor behavior in certain games — my hope is that they reintroduce the feature with a user interface, like Samsung does, so that users can add their own games to the list of games it targets, or disable the feature altogether should the user not want or need it.

Despite these caveats, it’s ultimately a powerful performer that near-maxes out all of these games. It might not be the specific champion in all instances, but it offers a profile I can easily contrast against 2017 flagships. Overall, it’s a nice device for gaming that will likely stand the test of time better than its predecessors. I do hope, however, that the prowess on display here and in upcoming devices prompts game makers to further up the ante and deliver even better graphics, as I do think that progress has been stale with few new releases truly impressing those hungry for great visuals on mobile. With smartphones getting more and more powerful with every cycle, it should only be a matter of time before some game studios decide to take full advantage of the improvements in graphics performance and the Vulkan API.

Check out XDA’s OnePlus 3T Forums! >>>


from xda-developers

How to Automatically Disable the High Volume Warning without Root

Those of you who live in one of the member nations of the European Union have probably come across the warning when trying to raise the volume of your headphone as shown in the feature image above.

According to regulations set by the European Committee for Electrotechnical Standarisation (CENELEC), all electronic devices capable of media playback sold after February 2013 must have a default output volume level of a maximum 85 dB. Users can choose to override the warning to increase the volume to a maximum of 100 dB, but in doing so the warning must re-appear after 20 hours of music playback.

While we aren’t going to get into a debate about the efficacy of this regulation in promoting good health, users who frequently choose to bypass this warning often wonder if this process can be automated. There are many cases where it is rather annoying having to manually agree to override the volume limit, such as when you start music playback remotely on a Bluetooth device, so we wanted to set about figuring out a way to automatically bypass this warning.

Solutions to bypass the “safe volume limit” already exist if you search our forums, but so far all of the solutions have required you to install an Xposed Module. This necessarily limits who can use it, as the Xposed Framework requires you to have root access (which means an unlocked bootloader on most phones) as well as being on pre-Nougat versions of Android. But after digging into AOSP and various system settings, I’ve discovered a way to bypass the high volume/safe audio limit on all devices without requiring root.

By following this guide, you accept any risks involved with listening to media at high volume levels.

Safe Audio Warning Bypass Tutorial

If you’ve read my previous article on enabling Immersive Mode without root access, then you may have started playing around with some of the settings you can find hidden on your phone. If you haven’t, I highly recommend you do, as I’ve found that almost every device has a ton of goodies just waiting to be discovered. This trick is no different as we’ll be using a system property to bypass the safe audio warning.

Specifically, we will be modifying the System.Global property audio_safe_volume_state both on boot and periodically so Android will always think you have consented to bypass the warning. This property is defined in AOSP, which we’re reproducing below. There are several states this property can take, ranging from 0-3. 30 seconds after boot or after every 20 hours of continuous music playback, the state is set to ‘0’ or ‘not configured.’ It is then set to ‘1’ for ‘disabled’ or ‘3’ for ‘enabled’ depending on your Mobile Country Code. If you live in the E.U., this property is set to ‘3’ by default but is changed to ‘2’ for ‘inactive’ whenever the user manually bypasses the volume warning. We will be changing the value of this property to the ‘inactive’ state (changing it to ‘disabled’ never worked for me, in case you’re wondering).

Safe Media Volume Implementation in AOSP

    // Safe media volume management.
    // MUSIC stream volume level is limited when headphones are connected according to safety
    // regulation. When the user attempts to raise the volume above the limit, a warning is
    // displayed and the user has to acknowlegde before the volume is actually changed.
    // The volume index corresponding to the limit is stored in config_safe_media_volume_index
    // property. Platforms with a different limit must set this property accordingly in their
    // overlay.
    // mSafeMediaVolumeState indicates whether the media volume is limited over headphones.
    // It is SAFE_MEDIA_VOLUME_NOT_CONFIGURED at boot time until a network service is connected
    // or the configure time is elapsed. It is then set to SAFE_MEDIA_VOLUME_ACTIVE or
    // SAFE_MEDIA_VOLUME_DISABLED according to country option. If not SAFE_MEDIA_VOLUME_DISABLED, it
    // can be set to SAFE_MEDIA_VOLUME_INACTIVE by calling AudioService.disableSafeMediaVolume()
    // (when user opts out).
    private final int SAFE_MEDIA_VOLUME_NOT_CONFIGURED = 0;
    private final int SAFE_MEDIA_VOLUME_DISABLED = 1;
    private final int SAFE_MEDIA_VOLUME_INACTIVE = 2;
    private final int SAFE_MEDIA_VOLUME_ACTIVE = 3;
    private Integer mSafeMediaVolumeState;
    private int mMcc = 0;
    // mSafeMediaVolumeIndex is the cached value of config_safe_media_volume_index property
    private int mSafeMediaVolumeIndex;
    // mSafeMediaVolumeDevices lists the devices for which safe media volume is enforced,
    private final int mSafeMediaVolumeDevices = AudioSystem.DEVICE_OUT_WIRED_HEADSET |
    // mMusicActiveMs is the cumulative time of music activity since safe volume was disabled.
    // When this time reaches UNSAFE_VOLUME_MUSIC_ACTIVE_MS_MAX, the safe media volume is re-enabled
    // automatically. mMusicActiveMs is rounded to a multiple of MUSIC_ACTIVE_POLL_PERIOD_MS.
    private int mMusicActiveMs;
    private static final int UNSAFE_VOLUME_MUSIC_ACTIVE_MS_MAX = (20 * 3600 * 1000); // 20 hours
    private static final int MUSIC_ACTIVE_POLL_PERIOD_MS = 60000;  // 1 minute polling interval
    private static final int SAFE_VOLUME_CONFIGURE_TIMEOUT_MS = 30000;  // 30s after boot completed

You’ll first need to install Tasker and AutoTools so we can automate this trick. Technically, any other automation app apart from Tasker can be used, but I’m only familiar with Tasker so you’ll have to make adjustments on your own if you prefer using a different app. AutoTools, though, is critical to this trick as this plug-in will allow us to control Secure Settings on our device.

As explained in my article on toggling Immersive Mode, we need to grant the WRITE_SECURE_SETTINGS permission to AutoTools. This is because the command for controlling the safe audio volume state is defined under the Settings.Global class, though the exact syntax for the command is hidden in AOSP (just like it was for Immersive Mode). If you’ve already granted the WRITE_SECURE_SETTINGS permission to AutoTools after having read my previous tutorial on Immersive Mode, then you can skip the next section. If not, then you’ll have to set it up.

Granting Secure Settings Permission to AutoTools

Under Android’s permission management system, applications define the permissions they want to be granted in the Manifest file. Users can then grant or deny permissions on installation (pre-Marshmallow) or on demand (Marshmallow+). However, there are certain permissions that applications cannot be granted even if they request it in the Manifest, such as WRITE_SECURE_SETTINGS. This is because granting any application a permission as powerful as this would give that app a ton of control over your device.

But there is one workaround that we can use to grant the WRITE_SECURE_SETTINGS permission to any app we want. By using ADB’s package manager (pm) tool, we can grant any permission to any application we want (provided that application requests that permission in the Manifest file).

The first thing you’ll need to do is install the ADB binary onto your computer followed by the right driver for your device. Then, enable USB Debugging in Developer Options (go to Settings –> About Phone and tap on Build number 7 times if you haven’t already) and connect your phone to your computer. Finally, send the following command once you’ve opened up a terminal:

adb shell pm grant com.joaomgcd.autotools android.permission.WRITE_SECURE_SETTINGS

Now AutoTools will have the ability to change any Global, Secure, or System setting on your device. There are various ways you can play around with these settings, and the list of available settings in each category completely depends on your device and software build, but that discussion is for another time. In any case, we’ll move on show you how to use AutoTools to control the safe volume state.

Disabling Safe Audio Warning on Boot

Here’s the description of the profile for those of you who are familiar with Tasker. If you aren’t familiar with Tasker, read on for step-by-step instructions.

Disable Safe Audio on Boot

Profile: Disable Safe Audio On Boot (6)
        Event: Monitor Start
Enter: Anon (7)
        A1: Wait [ MS:0 Seconds:30 Minutes:0 Hours:0 Days:0 ] 
        A2: AutoTools Secure Settings [ Configuration:Setting Type: Global
Name: audio_safe_volume_state
Input Type: Int
Value: 2 Timeout (Seconds):60 ]

Open up Tasker so we can create a new profile. At the bottom right hand corner tap on the + icon to create a new profile. Add an new Event context and go to Tasker –> Monitor Start. We are using this Event context which triggers when Tasker starts up rather than the Event context which activates when the phone boots because the former is far more reliable than the latter.

In any case, press the back button as we will now create a Task associated with this profile. Name the Task anything as it doesn’t matter. Once you enter the Task creation screen, press on the + icon in the bottom middle of the screen to create a new Action. For the first action, go to Task –> Wait and have it wait for 30 seconds. This accounts for the “30 second after boot” rule used in Android to set the safe volume state.

Next, create a new Action and go to Plugin –> AutoTools –> Secure Settings. Press the pencil to open the configuration screen for AutoTools. Go to Custom Setting. For the Setting Type enter Global. For the Name enter audio_safe_volume_state. For the Input Type make it int. For the Value make it 2. Check to make sure you put everything correctly, the configuration should match the middle screenshot below. The command must be sent exactly as I’ve written or it will not have any affect.

Once you’re done, back out to the main menu of Tasker as we’ll need to create another profile. The one we just created accounts for when the safe volume state is set 30 seconds after boot, but for those of you who almost never reboot your device we’ll make another profile to periodically set this value.

Disable Safe Audio Warning Periodically

Here’s the description of the profile for those of you who are familiar with Tasker. If you aren’t familiar with Tasker, read on for step-by-step instructions.

Disable Safe Audio Periodically

Profile: Disable Safe Audio Periodically (21)
        Time: 11:59PM
Enter: Anon (122)
        A1: AutoTools Secure Settings [ Configuration:Setting Type: Global
Name: audio_safe_volume_state
Input Type: Int
Value: 2 Timeout (Seconds):60 ]

Create a new profile, this time with a Time context. Unfortunately I’m not aware of any method to get the current cumulative time of media playback without root, so we’ll instead just periodically set the safe volume state to inactive once every 24 hours (… it’s not like you guys actually listen to 20 hours of music within a 24 hour period, right?). Anyways, Tasker’s interface for setting a periodic Task is kind of terrible, but the gist of it is that you want to set the “From” and the “To” time to the same time. This way, Tasker will treat it like you want the Task to only trigger once at a set time (I made it 1 minute before midnight).

As for the Task, just copy what you did for Action #2 in the previous profile. There’s no new or different Action in this case, as all we’re doing is changing the value of this Global system property once every 24 hours.

Now that you’ve set up both of these profiles, you’re done! Reboot your phone and you should now no longer see the “safe volume” warning when you plug in your headphones.

Download and Import to Tasker

As always, we’re providing the scripts’ XML file that you can download and import. Simply download the files from the link below and save it anywhere on your internal storage. Open up Tasker and disable Beginner Mode in Preferences. Then, go back to the main screen and long-press on the “Profile” tab up top. You should see a pop-up with one of the options being “Import.” Tap on that and browse to where you saved the .prf.xml files and select that file to import. Repeat for the second profile.

Download the ‘Disable Safe Audio Warning on Boot’ Profile Download the ‘Disable Safe Audio Warning Periodically’ Profile

We hope you find this tip useful. Let us know in the comments below if this works for you!

from xda-developers

Qualcomm Announces the Snapdragon X20 Modem

When most people talk about Qualcomm’s Snapdragon SoCs, they’re almost always focusing on the company’s CPUs and GPUs that are put into the chips.

What a lot of people don’t think about is all of the extra components that actually make it a system-on-a-chip. This includes a modem, a DPS, display controllers, security layers, optical fingerprint technology and more. Hence, many people only discuss the components that contribute to the raw performance of their device, but fail to realize that the SoC is far more than just its CPU and GPU.

One of the areas where Qualcomm excels is in their modems. Not only do they provide incredible speed, but they also tend to use less battery than competitor solutions do. Just last October we saw Qualcomm announce the X16 and X50 modems, so be sure to check that article out in case you missed it. The Snapdragon X16 modem is what the upcoming Snapdragon 835 SoC will be using, and it will provide Gigabit LTE speeds to people for the first time in their lives.

But while the S835 has yet to be launched in any commercially available devices, Qualcomm has already announced the next iteration of their modem with the Snapdragon X20. This is the first product announced that will support Category 18 download speeds, which go up to 1.2 Gbps. It’s fair to say this type of speed will eat through most people’s monthly allotment of data, but at least we will have the capability to do so in future devices.

An increase in bandwidth speeds isn’t the only thing the Snapdragon X20 brings to the tablet though. Qualcomm is advertising that the Snapdragon X20 modem now supports more combinations of LTE carriers, 4×4 MIMO configurations, and a higher number of total LTE spatial streams. This enables the modem to provide expanded flexibility for more cellular networks around the world who choose to deploy Gigabit LTE. The new modem also supports License Assisted Access (LAA) technology, which is what Qualcomm and others have been hoping to get deployed since it enables faster speeds.

We don’t know which products will be the first to market with this new modem, but Qualcomm says they’re expecting it to be available in the first half of 2018.

Source: Qualcomm

from xda-developers

Honor V9 Announced In China With 5.7″ QHD Screen, Kirin 960, and 12MP Dual-cameras

Huawei’s side-brand Honor has launched a new smartphone in China, the Honor V9. Honor is known for offering great bang-for-buck in its devices and the Honor V9 is not an exception: their latest flagship packs pretty impressive specifications while still maintaining a competitive price point. The device comes in multiple storage variants with price starting at ¥ 2,599 ($377) for the base variant.

Specification wise, the Honor V9 sports a 5.7-inch QHD LCD screen covered in 2.5D glass. In the camera department, the device features two 12MP f/2.2 cameras on the back with an implementation similar to what we have seen in the Honor 8; the device utilizes one monochromatic sensor and one RGB sensor which according to company allows for improved low-light performance. As for selfies, the device has an 8MP f/2.0 front camera.

Under the hood, the device has the same powerful HiSilicon Kirin 960 octa-core SoC which powers the Huawei Mate 9, with four Cortex A73 cores clocked at 2.4 GHz frequency and four Cortex A53 efficiency cores running at 1.8 GHz frequency. On the software side, the Honor V9 comes preloaded with Android 7.0 Nougat-based EMUI 5.0 out of the box.

Lastly, the device comes with a 4,000mAh battery, a rear-mounted fingerprint sensor, Bluetooth 4.2, NFC, IR blaster, USB-C port and, luckily, 3.5 mm headphone jack.

As for the pricing, the Honor V9 costs ¥ 2,599 ($349) for the 4GB RAM + 64 GB version, ¥ 2,999 ($435) for the 6GB RAM + 64GB model and ¥ 3,499 ($510) for the 6GB RAM + 128 GB model.

The Honor V9 will be available in four color options to choose from: Midnight black, Flame Red, Platinum Gold and Aurora Blue with sales officially starting from February 28 in China. Unfortunately, the company didn’t reveal when, if ever, the device will make its way to other markets.

Source: Gizmochina

from xda-developers

XDA Recommends Hushed: Lifetime Subscription for your Private Secondary Phone Number

In XDA Depot we have a lifetime subscription for the Hushed Anonymous Phone Number service that gives you a second phone number to use for whatever you want. This is a great way to secure your privacy with online dating, craigslist stuff, online shopping and anything that might ask your for your phone number. Let’s see what you get.

The Hushed lifetime subscription is currently 82% off at only $25. This will get you 500 minutes of talk time and 300 texts a year.

The app is available for both Android and iOS and it works great. A very simple layout without any obnoxious bells and whistles that you often get in apps like this.

You can choose from tons of numbers from either the US or Canada.

  • Use included plan towards a combination of 3000 SMS or 500 phone minutes per year (North America 365 Plan)
  • Make calls & send texts from a private phone number without monthly fees
  • Choose from 100’s of area codes across the US & Canada
  • Manage your communication from a single app
  • Access one lifetime number per account
  • Customize your voicemail
  • Set up call forwarding settings
  • Utilize Wi-Fi or data while you chat so you don’t incur service charges

Developers that buy digital goods through the XDA Depot are helping support the XDA-developers website and keep the community alive.

Get this deal


from xda-developers