For those of you eagerly awaiting official builds for Lineage OS, we have some good news for you: the official Lineage OS builds have now finally started coming in. The team behind the Lineage OS project announced in an official blog post that they will start rolling out official builds. In the first phase, official builds are planned for more than eighty devices.
Following the announcement, builds for the Google Nexus 6P, Nexus 5X, Moto G4/G4 Plus, Nextbit Robin, Xiaomi Redmi 1s, and the OnePlus One have gone live. Unlike CyanogenMod builds, these ROMs won't ship with superuser binaries pre-installed. Instead, you will need to flash a separate zip file that the team will provide.
Migrating to a new custom ROM can be a hassle for many users as the developers usually request that you perform a factory reset. However, the developer team will be throwing us a bone here and will be offering experimental data migration builds for the first two months which allow users to flash Lineage OS on top of an existing CM 13 or CM 14.1 installation without having to wipe any user data. These experimental builds will feature an ugly watermark reminding users that they should not use the build as a daily driver, but should treat it as a stepping stone for migrating to Lineage OS. Users who install these experimental builds are strongly recommended to then flash the weekly build.
Release candidates will roll out every week and will be signed by a private key for authentication, so users know that they are running an official Lineage OS build. To grab the builds, head over to the official download page here. You can check out the installation statistics page here or the newly minted wiki page right here. If you're a developer, you can keep up to date with all of the latest changes to Lineage OS by following its Gerrit project page here.
We see big companies such as Google facing these antitrust allegations in many parts of the world as well. So it feels almost inevitable for these claims to surface once your company gets so big and does business in so many countries. The latest to go after Qualcomm is actually Apple themselves, as they have announced they're suing Qualcomm for $1 billion in the U.S. District Court for the Southern District of California. Apple claims that Qualcomm is overcharging for chips, and that they've even refused to pay close to $1 billion in promised rebates.
Apple believes Qualcomm withheld these rebates because they were in discussion with South Korea's antitrust regulator, the Korea Fair Trade Commission. Apple even goes as far as to say Qualcomm attempted to extort Apple into giving the Korea Fair Trade Commission false information in exchange for the release of those rebate payments to Apple. Qualcomm immediately put out an official statement once this lawsuit was made public and says "Apple's claims are baseless."
Qualcomm says that Apple has been "actively encouraging regulatory attacks" on the business that Qualcomm does in various regions around the world. Claiming that Apple is "misrepresenting facts and withholding information" when they talk to those in the KFTC and FTC. Qualcomm says they're looking forward to hearing these claims explained in court and they'll be there to prove Apple is intentionally mischaracterizing their agreements and negotiations.
Read the full statement by following the link below:
While many people complain that OEMs are slow to push out big official updates to Android, Google is able to roll out the latest version of Google Play Services to over 90% of the active user base. Updates to Google Play Services doesn't change the core UI of Android, and it doesn't add in new APIs for developers to utilize.
However, it can add in new features to smartphones and tablets that have a deep level of integration into the Android platform.
We've just learned that Google is in the process of rolling out a new update of Google Play Services at this very moment. This update will bring its version up to 10.2 (10.2.91 to be exact right now) and we're already seeing one big feature added in this update. This update likely adds in other fixes and optimizations as well, but Andreas Proschofsky has uploaded a screenshot of the new Instant Tethering feature that they were able to discover once they received the update.
You can manually download and install this update by yourself by clicking here (just be sure you grab the appropriate version for your specific device), or you can wait for the update to be pushed to your device via the Google Play Store. It seems the Instant Tethering feature is a server side switch though, and Google will be testing this on a small percentage of Pixel and Nexus devices which are running Android 7.1.1 Nougat at first.
Once you get the update and once the feature is activated for your device, you'll see two toggles that will let you designate if you want the device to provide a data connection or receive a data connection. Sometimes you'll be able to toggle both of these on, but Google says the Nexus 9 and Pixel C will only be supported as clients.
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 disassembles 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.
The batteries from company B 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.
While the battery design itself allowed for more room for the jelly roll, 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
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
