Security within the Android platform has become very important to Google lately. This isn't to say that Google didn't care about vulnerabilities for Android in the past, though. It just became clear that when Google started rolling out monthly security updates to the Nexus devices back in November of 2015, they were getting very serious with it.
Google even recently shared a couple of methods that enables them to catch malicious applications that were able to bypass their own scanning definitions. So the company has just created a new landing page that focuses on Android security for people who are developing on this platform. This is part of the Android Developers website and it offers a number of tools and tips for developers who want to keep their applications clean and user friendly.
The first thing we see on this landing page is a collection of Android security-related articles that appear on the many, many other established Google blogs. For example, the latest post on this new Android security landing page is from the Google Security Blog, and it takes a look back at 2016 and highlights the ways they were able to help developers fix security vulnerabilities in 100,000 applications. This is all thanks to Google's Google Play App Security Improvement (ASI) program and it has resulted in over 90,000 developers updating over 275,000 applications.
This new Android security landing page also has a security essentials checklist which has links to training articles on the Android Developers website. These training articles include tips for how to store data safely, how to enforce secure communications, suggesting that developers only use the required permissions and more. So if you're an Android application developer, or just someone who is interested in the effort Google puts into Android security, then be sure to check out the new landing page that's been set up.
The Galaxy Note 7 was recalled on September 2, only two weeks after its initial release. By October 11, the phone had been discontinued globally following reports of continued failures in the replacement models Samsung shipped shortly after.
As of today, 96% of around 3 million Galaxy Note 7 units that were sold and activated have been returned, following a large recall campaign carried out by Samsung, retailers and mobile carriers.
Today, Samsung finally disclosed the results of its intensive investigations on the battery defects that lead to thermal failure of multiple Galaxy Note 7 devices across the globe. The company assigned over 700 engineers to analyze thousands of devices and over thirty thousand batteries. Samsung claims it thoroughly examined every aspect of the device internally to determine the cause of the incident, including: hardware and software related processes, assembly, quality assurance, testing and logistics. On top the internal investigation, the company hired three different firms to provide an objective assessment of the issue at hand, starting with the first recall.
Research & Testing
The most important step was replicating the incident, and for this Samsung built a large-scale charge and discharge testing facility, with hundreds of automated charging and discharging processes for hundreds of Galaxy Note 7 devices. The company used this facility to test likely factors that could have led to the battery incidents. They managed to rule out various probable causes including the effect of fast charging and regular charging through both Samsung's Adaptive Fast Charging technology and Wireless Charging. Testing was also carried out without the device's back to find out whether the back plate's pressure or thermal constraints (introduced by the phone's waterproofing) had a significant impact in the incidence rates. They also tested the Iris Scanner and the USB Type C port, which was subjected to high voltages way past specification. Finally, the company made sure software didn't impact the incidence rates by testing pre-loaded and third-party applications during the test.
Samsung's testing facility shown in the background.
Past this discrete testing environment, Samsung also did a full investigation of component quality assurance, and tracked the handling of all parts throughout the manufacturing process. All of these procedures demonstrated no abnormalities, and the charge and discharge tests both showed similar rates of incidence, indicating that the battery cell itself was at fault. Below is a summation of the conclusions that Samsung arrived to after their own internal investigation and the research done by firms UL, Exponent and TUV Rheinland. The company didn't specify the battery manufacturer's names during the presentation, only referring to them as Company A and Company B, the latter's batteries having been employed in recalled devices.
Battery Analysis Results
The battery provided by company A and by battery B had different strenuous factors that damaged the separator or electrodes, or lead to cell faulting.
In battery A, the design of the cell pouch did not allow enough room for the battery internals, in turn bending the negative electrodes and putting strain in the battery separator. The incidence consistently occurred in the upper-right corner of the "jelly roll", The main cause was thus the deflection of negative electrodes, including incorrect positioning of the negative electrode teeth.
Field tests and disassembling procedures suggested that the issues with batteries from company A came from a combination of assembly and manufacturing issues, as well as issues with the battery design itself. The density of the battery also increased the chances of severe failure, but additional research was needed to pinpoint the cause of the deformed corners putting stress in the negative electrodes. A thinner separator could also have led to poorer protection and reduced tolerance to manufacturing defects. Some batteries also had missing tape on the insulator tab. What's certain is that a combination of deformation at the upper corners, a thin separator and the mechanical stresses due to natural cycling make for a major failure mechanism.
The batteries from company B were actually tested before they were distributed in a recall, and they were assessed to be safe by Exponent and other analysts. While it didn't showcase the same apparent issues as battery A (shown in the picture to the right), particularly the ones that were quickly determined to have been a factor leading to thermal failure, the batteries from company B also had their own manufacturing defects found after they had been shipped.
While company B's batteries didn't have device-level compatibility issues that contributed to its failure, but many compounding factors relating to production quality and battery designed came together and led to the Note 7's failure. First, production quality issues included missing insulation tape which increased the incidence rates of battery short circuit. Second, a bigger protrusion of welding points in the tab lead to a higher chance of separator puncture. Finally, general misalignment of insulation tape also increased the risk of failure.
For the second set the battery design itself allowed for more room for the jelly roll, but a thinner separator still led to poorer protection and reduced tolerance to manufacturing defects as seen with batteries from company A. Without the apparent flaw in the corners, the combination of missing insulation tape, sharp edged protrusions and a thin separator led to a higher probability of short circuit between the cathode tab and the anode, which resulted in the heating and fire. Exponent found that the most likely root cause for the thermal failure was determined to be internal cell faulting between the positive electrode tab welding defects (tall enough to bridge the gap) and the copper foil of the negative electrode.
Fool me twice…?
It's clear that Samsung went through a lot of trouble to find the root cause of what's likely to go down in history as the biggest, most expensive consumer product recall. While there are many questions that remain unanswered, Samsung did a decent job at disclosing the issues at hand, knowing the constraints that come with extensive supply chains, partnerships, and the like. Overall, Samsung pulled off one last act of transparency that begins redeeming their poor handling of the situation early into the fiasco. The speakers from UL, Exponent and TUV Rheinland arrived to the same conclusions and it does seem that the Note 7 itself was not the main cause of the thermal failure, as this was allegedly ruled out by Samsung's internal testing.
"The incidents with phone explosions, that can happen with any OEM. It could happen with us on our next product, so it should not be something that we use as an opportunity — we should use this as a reminder."
As Carl Pei told XDA in an interview, this is something OEMs need to keep in mind for future quality assurance of their devices, as while Samsung is big enough to weather such storm, a recall on this scale could be devastating to any smaller company. Moreover, this puts into perspective the volatility that manufacturing defects in the order of 80 microns can introduce to a consumer product. Samsung is keen on making sure this scenario never repeats itself, and they are putting forth a broad range of internal quality assurance and safety processes to enhance product safety. Multi-layer safety measures, 8-point battery safety check, and forming a Battery Advisory Group are just some of the items on Samsung's list of prevention measures. It seems that the South Korean giant is determined to gain back consumer trust, so we can't say we expect an issue of this magnitude to come about in 2017.
The Galaxy S8 is very close, so it's only a matter of time before we see whether Samsung can shrug off the bad fame (and unending memes) that the Note 7 brought about.
Does this bring closure to the Note 7 fiasco in your eyes? Let us know what you think!
from xda-developers http://ift.tt/2jePV35 via IFTTT
Back in October of 2015, developers started compiling the first builds of Chromium optimized for Snapdragon devices. Popularly known as "CAF Chromium" builds (named after the Code Aurora Forums where the source code originated), these open source derivatives of Chromium quickly began proliferating the net. Soon, there were dozens of CAF Chromium based builds available on various sources (including some on our very own XDA Labs app market).
Each variation of the project, made by individual developers cherry picking features to their liking, offered much to users. Night mode, built-in ad-blocking, power saving mode, and more features could be found in many of these builds. Some variants even featured support for syncing your Google account, but this was typically rare (and likely to become impossible in the near future). Overall, many users probably can't tell much of a difference between each CAF Chromium variants – especially when it comes to performance. Despite benchmarks claiming significant differences, most users will probably adamantly tell you that "theirs" is the fastest.
And then there's the issue with trust. Although the original CAF Chromium is open source, many of these variants are not. Users likely have little reason to distrust the maintainers of some of the more popular variants, but there have been issues in the past with some CAF variants. Furthermore, people continue to be wary of what data a browser can collect after the Dolphin browser revelations.
But more practically speaking, the biggest issue with CAF Chromium variants is staying updated with the latest versions of Chromium. Google regularly updates its browser to fix security issues, but one developer regularly maintaining their own fork can be time consuming. A team of developers, on the other hand, can much more readily provide frequent updates to a browser. Luckily, the open source Chromium is exactly that.
Living on the Bleeding Edge with Chromium
To get a sense of just how far ahead Chromium is compared to Chrome channels, let's look at what version each browser is currently at.
Chromium for Android: v58.0.2990.0
Chrome Canary: v57.0.2987.4
Chrome Dev: v57.0.2984.3
Chrome Beta: v56.0.2924.68
Chrome Stable: v55.0.2883.91
As you can see, Chromium is even further ahead than the most experimental branch of Google Chrome, Canary. This doesn't mean that Chromium itself is unsuitable for daily use – far from it. Chromium for Android runs the latest build of Chromium straight from source, which means it may feature bugs in any individual build, or it may not. Those of you who have experience running custom nightly ROM builds might know what I'm talking about. But those of you who prefer to stay on only the latest stable build are probably wary of installing something so experimental.
In terms of features, Chromium doesn't offers all the bells and whistles of most of the closed source, CAF Chromium derivatives I mentioned in the beginning of this article. There's no built-in ad-blocking, no night mode, or power saving mode. This is just pure Chromium built straight from source with any experimental features that are currently being worked upon in the open source project. If you're the kind of person who likes to dig around and play with new features in chrome://flags or you just like to run the latest experimental build to experience all of the under-the-hood improvements made by the Chromium team, then this browser is for you.
If you aren't the kind of person who wants to run a script to build Chromium for Android from source each day (most of us probably aren't), luckily there are actually sources where you can easily download the latest version. An open source application called Chromium Auto Updater is one such method to easily stay up to date, but there are other applications (as well as a simple Tasker project I will provide that does the same function).
Staying up to Date with Chromium
Every night, the Chromium build bot compiles Chromium with any submitted code changes into what is called a Snapshot build. The binaries of these snapshot builds can be found on Google's Storage servers. After passing a series of automated tests, these snapshots may eventually become stable builds of Chromium. Currently, the Chromium team does not offer any stable builds of Chromium for Android. You can only download snapshot builds for Chromium, but doing so hasn't really been accessible to the average user – which is to be expected given its experimental status.
François Beaufort created a webpage (now maintained by the Chromium team) to allow you to quickly download the latest Chromium build for any OS in a single click, however, this requires you to manually visit the page to stay up to date. Another webpage offers an RSS feed and an API (as well as a boat load of information related to the project) which allow you to readily down the latest version automatically – provided you know how to properly parse this kind of data. If we want to automatically download the latest build, we can do so using the aforementioned open source app, Chromium Auto Updater.
The way this application works is quite simple. It periodically polls the Chromium snapshot build page for new versions, and if it finds a new version it will notify you that a new build is available to download. If you have root access on your device, you can have the latest build update automatically in the background (for those curious, the application uses the package manager shell command to install the update). Otherwise, clicking the notification will open the intent to update the app via the standard package manager interface.
Although Chromium Auto Updater isn't the only application of its kind, I prefer it over the two other alternatives. For starters, getChromium does not have the option to automatically install the latest build for users with root access, plus it doesn't currently install on Nougat devices. The other Chromium updater app that you can find in the Play Store does not seem to be open source (or at least, I can't find its source code). Thus, I've stuck with using Chromium Auto Updater to stay up to date with the latest builds of Chromium.
Finally, as a sort of DIY alternative (and because I love Tasker), I created my own auto-updating Chromium project. I will share the descriptions of the two profiles that comprise the project below as well as the project file you can download and import. I thought it would be a fun project to replicate these open source apps, and if you are itching to improve your Tasker skills I would recommend you try re-creating my project below. Given the descriptions, it should be fairly simple!
Update Chromium
Profile: Update Chromium (141) Day: Sun, Tue, Thu or Sat Time: 11:59PM Enter: Update Chromium (133) A1: HTTP Get [ Server:Port:http://ift.tt/2iSh6SI Path: Attributes: Cookies: User Agent: Timeout:10 Mime Type: Output File: Trust Any Certificate:Off ] A2: If [ %HTTPD neq %Version ] A3: Variable Set [ Name:%Version To:%HTTPD Recurse Variables:Off Do Maths:Off Append:Off ] A4: Notify [ Title:Downloading Chromium... Text:Fetching latest version from Google. Icon:hd_av_download Number:0 Permanent:Off Priority:3 ] A5: HTTP Get [ Server:Port:http://ift.tt/1cw9s5B Path:/chromium-browser-snapshots/Android/%HTTPD/chrome-android.zip Attributes: Cookies: User Agent: Timeout:10 Mime Type:application/zip Output File:Tasker/chrome-android.zip Trust Any Certificate:Off ] A6: Notify Cancel [ Title:Downloading Chromium... Warn Not Exist:Off ] A7: UnZip [ File:Tasker/chrome-android.zip Delete Zip:On ] A8: Notify [ Title:Chromium Update Available! Text:Tap to install. Icon:hd_location_web_site Number:0 Permanent:Off Priority:5 ] A9: End If
In order to import it, first save the file to your internal storage. Open up Tasker, and disable "Beginner Mode" in preferences. Then, return to the main screen and long press on the "home" icon in the bottom left hand corner. You will see a pop-up that says "import." Choose that option, then browse to where you saved the .prj.xml file and click to import it. Voila! You should now see the "Chromium" project as another bottom tab in Tasker. You can, and should, customize the timings when the auto-updater should check for new Chromium builds to suit your preferences. Enjoy the project!
from xda-developers http://ift.tt/2iSdvUZ via IFTTT
At XDA, when we aren't covering news that we think is important for the day or publishing an in-depth analysis piece, we like to plug the gap with interesting projects, rumors, and tips. Just yesterday, I posted a tip that reminded users of a useful Chrome flag that has undergone improvements. Today, I bring you another useful Chrome flag: lock the screen orientation when playing a fullscreen video.
Lock screen orientation when playing a video fullscreen.
Android Lock the screen orientation of the device to match video orientation when a video goes fullscreen. Only on phones.
Available in the Dev and Canary channels of the Google Chrome browser for Android, this flag will lock the screen orientation of the device to match the video's orientation whenever you make the video go fullscreen. This should be useful for those times you are watching a video while laying in bed and you tend to accidentally flip the video (probably happens to a lot of us out there). Here is a before and after video demonstrating the flag in action:
As you can see, once enabled the video is automatically set to the proper rotation based on the video's most prominent orientation. Furthermore, I am prevented from changing the rotation of the video when I physically rotate my device (although you can't see me flip my phone in the video). No longer will you need to fumble with changing your quick settings or using Tasker to automate changing the rotation lock in certain apps. Now, Google Chrome will handle that for you – provided you're viewing a fullscreen video, of course.
In order to enable this flag, simply paste the following URL into the address bar. Remember that this feature is considered experimental and it is entirely possible it won't make it to the stable release of Chrome. I haven't encountered any major issues with this flag enabled, though, so I'm optimistic it will roll out to all Chrome channels eventually.
For most of Android's history, applications have been installed as local packages on the device itself. We typically acquire the installation files we need by downloading an APK file, which is an archive containing all of an application's resources and assets. While there are many benefits to installing a native application this way, there are also many benefits to developing an application that is web based. Web applications can be accessed on multiple platforms, can be easily modified, and can be readily deployed among other benefits.
Google has taken web apps one step further and created Progressive Web Apps (PWA), which are more integrated with mobile devices. Progressive Web Apps have access to send push notifications and most importantly are "installed" to the home screen of a device. These web apps can be created from most websites by clicking the "Add to Home Screen" option in Chrome's menu, however, how functional the Progressive Web App actually is depends on website support.
One of the major downsides of PWA are that they are not treated as actual applications on the device. As these web apps are accessed via home screen shortcuts, many users who like to theme their home screens are probably put off by this fact. I can speak from experience. Fortunately, during the 2016 Chrome Dev Summit last November, the Chrome team demonstrated that Progressive Web Apps could actually be turned into APKs that would install on your device.
The developer team did not state when exactly support for "WebAPKs" would go live, but apparently it is already live – it's just nobody really noticed. To be fair, the only way to enable support for this feature is to enable a new Chrome flag:
If you paste the above link into your address bar (while on either the Dev or Canary channels of Chrome for Android), then you will be taken to a Chrome flag which states the following:
Enable improved add to Home screen.
Android Packages "Progressive Web Apps" so that they can integrate more deeply with Android. A Chrome server is used to package sites. In Chrome Canary and Chrome Dev, this requires "Untrusted sources" to be enabled in Android security settings.
As is clearly stated, Progressive Web Apps can now be packaged into actual installable Android packages! This uses a back end Chrome server to package the website into an APK (though it is unclear if it is Google running this server, which presume is the case). Once you enable the flag and restart Chrome, any PWA you "Install to Home Screen" will instead download an APK file to install on your device. Not every website supports this, of course, but you can take a look at the websites that fully support this new feature right here.
Fun with Progressive Web Apps
We've taken two different PWAs for a spin to see how the feature fares – Financial Times and Telegram. Financial Times is a simple news website which is the perfect case of a time when the mobile website might be a better choice than a separate application.
As you can see, the PWA is treated like an actual application by Android. It prompts you to be installed and it resides within the app drawer like any other app. Furthermore, removing the PWA works just like uninstalling any other app.
Note the difference in the information bar in these two screenshots showing the recent apps screen. The first screenshot is what happens when you "install" a PWA without this new flag enabled, while the second screenshots shows a true installation of the PWA with the flag enabled. Financial Times exists as an application on my phone which can be dismissed separately from other Chrome tabs.
Next up is the Telegram web app. This PWA uses Telegram's web interface to serve you messages. To be honest, Telegram is probably one of the best designed and functioning applications that exists on Android, so I personally don't see the need for this PWA. However, I wanted to test the functionality of an instant messenger that was installed as a PWA so I decided to give it a spin.
While Telegram does indeed install and display all of my messages appropriately, there was one major caveat: notifications. It appears that notifications are not functioning properly right now. When I sent Mario Serrafero a message over Telegram, he did receive a notification (as shown in the bottom left screenshot) but it did not contain any useful information. Opening the "Site Settings" option brought us to the site specific settings for the Telegram web app which showed that Notifications were enabled, so we aren't sure why notifications do not work.
Of course, since the flag to enable WebAPK installations only exists in the Dev and Canary channels on Chrome for Android, we are assuming that this feature is a WIP and thus not everything will work at this time. Since we know that Chrome is able to send push notifications (for instance on Facebook), it is possible that Progressive Web Apps installed this way may also be able to receive push notifications in the near future.
Otherwise, this is a neat look into an experimental feature that I hope becomes more robust as time goes on. I like using Web Apps personally as they tend to serve me the information I need without any bells and whistles that tend to lag the device or drain my battery. Furthermore, this approach solves one of my major qualms with web apps, that being the fact that they were required to stay on your home screen in order to be launched. With web wrappers of various popular sites becoming more and more common, hopefully we'll see more companies adopt the Progressive Web App standard.
from xda-developers http://ift.tt/2k46ZHh via IFTTT
In our last discussion, we invited your views on the future of Google Daydream in 2017. Now we move the discussion towards Google Tango, or simply 'Tango' as it is now called.
In 2016, the only Tango certified device was the Lenovo Phab 2 Pro, which offered a nice glimpse at Tango functionality but suffered from its mid-range specifications. This year, ASUS has announced that their ZenFone AR will feature support for Tango (and Daydream VR to boot) but will more premium specifications. As the year goes on, we may see more devices from more OEMs come with Tango functionality.
So our question to you is,
Will Google Tango catch on in 2017? Will Tango-enabled devices sway consumers away from conventional flagship experiences? Or will AR-specific hardware be priced out of reach of most consumers?
Let us know in the comments below!
from xda-developers http://ift.tt/2jLhrG4 via IFTTT
Google's Chrome browser has been the most popular web browser in the world for a few years now, and its dominance is even more pronounced in Android. Although Chrome aims to be a one-size-fits all browser, some users prefer using third-party browsers (most of which are based on the Chromium open source project) for added features or to experience a different UI design.
Some popular web browsers allow you to place the address bar at the bottom – a useful option for those of us with larger phones. For a long time, this wasn't possible in Google Chrome. But early last November, Google added an experimental flag called Chrome Home to Chrome Dev and Canary.
When enabled (just click the link above in your browser), the browser would display the entire address bar at the bottom of the screen rather than its typical place at the top. It was a dream come true for big phone users – except for one major problem.
Yeah, the browser would render a blank space for where the address bar used to be. This blank space would take up quite a sizable portion of any webpage – and it was a definite eyesore. I'm sure many of our readers who heard of this tip, myself included, immediately disabled the flag once they realized how much precious screen real estate they were losing.
But fortunately, it looks like this visual bug has been fixed. We don't know exactly when it was fixed as each Google Chrome channel receives frequent updates (and likely most people disabled this flag and never bothered to re-enable it), but we can confirm that this bug is fixed in the Beta, Dev, and Canary channels.
Unfortunately, the stable channel of Google Chrome is still stuck on version 55 of Chromium, which does not contain this flag at all. But if you are running one of either the Beta, Dev, or Canary builds, then the Chrome flag should be working properly now. I've been running it today and haven't encountered any major issues so far, which is a good sign, but remember that any flag you enable is considered experimental so you should assume that it won't run perfectly.
from xda-developers http://ift.tt/2iOTYol via IFTTT
