lundi 21 août 2017

Android Oreo has a Rescue Party Feature to Help with Bootloops

Most of the new features of Android Oreo has been known about since the company released its first developer preview for Android O. We’ve been talking about the new features here on XDA for months and yet there are always new goodies to be discovered once the full update is released. One of these new features is called the Rescue Party and its goal is to help you to recover an Android Oreo smartphone or tablet that has run into bootloop issues.

Almost all of us here at XDA have been there before too. We try to install an incompatible or problematic modification, or just run into a bit of bad luck and then our device is stuck in a bootloop. This can often be a literal bootloop and it will cause the device to boot to a certain period and then simply reboot. Other times people will see their device getting stuck during the boot cycle and this is also commonly referred to as a bootloop within sectors of the community.

Google specifies two different methods and cases where the Rescue Party is triggered, so this will only happen in certain circumstances and won’t be a fix-all for everything. Still, this is quite interesting and could go a long way to preventing people from submitting support tickets for warranty inquiries. This will also be great for OEMs since the Rescue Party feature could fix the issue the customer was having and thus save their employees from having to deal with it.

Rescue party triggers when system_server restarts more than 5 times in 5 minutes or a persistent system app crashes more than 5 times in 30 seconds. So once Android Oreo detects a crash loop, it then escalates a series of actions to recover the device. This starts out by processing the task associated with that level, and attempts to let the device recover from the situation. Each level is progressively more aggressive and will clear/reset certain things.

This whole process ends when the device finally boots as it should, or by the device booting directly into recovery mode so you can perform a factory reset.

Source: Google

from xda-developers

Android 8.0 Oreo System Images Available for Supported Pixel and Nexus Devices

In a surprising turn of events, Google revealed the next version of Android will be called Oreo. This is interesting because they’ve teased it so much up until now, that some felt it was the company trolling us, and that it had to have been something else. Still, today is the day that Android Oreo has been named and it’s also the day that the next version of Android is released to the public. OTA updates are not going out just yet, but the system images for supported Pixel and Nexus devices have been released!

For those curious, you can download Android Oreo system images right now for the Pixel, Pixel XL, Nexus 5X, Nexus 6P, Nexus Player, and the Pixel C. These are the full system images that we’re used to seeing the company release. Google offers flashing instructions for these system images here, but warns that it will remove all of the user data from your device. So be sure to backup as much of your important data as possible before proceeding with those instructions.

As far as OTA updates are concerned, Google has announced that Pixel and Nexus 5X/6P builds have entered carrier testing. We should expect those to go out once that process is completed (assuming they pass the tests carriers put them through). That OTA update process will roll out in phases, just like other OTA updates from Google, and this can take some time to reach all supported devices. We’re also told that Pixel C and Nexus Player OTA updates will be going out about that time as well. If your device is currently enrolled in the Android Beta Program, then you can expect to get the final OTA update in the near future.

Google will be pushing these sources to AOSP sometime today so custom ROM developers can get their hands dirty if they so choose. We imagine there will be a race for the first AOSP build of Android 8.0 Oreo, not unlike with previous releases. Lastly, we recently talked about how Google is working with some OEMs to get Android 8.0 on their devices quicker. Google has said OEMs such as Essential, General Mobile, HMD Global Home of Nokia Phones, Huawei, HTC, Kyocera, LG, Motorola, Samsung, Sharp and Sony have plans to push their first Oreo update before the end of the year.


from xda-developers

Meet Google’s Latest OS Dessert: Android 8.0 Oreo

Every year at Google I/O, Google lifts up the veil on the newest update of Android by offering Developer Preview builds. But the I/O announcement is focused more towards developers than end-users, so Google prefers keeping the name and version number of the latest OS a secret until it is ready with a more polished and stable product that can be shipped to end users. For this year, Google chose the eventful Total Solar Eclipse over the USA as the perfect occasion to present us with the latest treat. Meet Android 8.0 Oreo.

Android 8.0 Oreo follows along the dessert naming convention that Google utilizes for the world’s most popular smartphone OS. And as is tradition, the Android Oreo statue was also unveiled at Google’s headquarters in Mountain View, California.

The total solar eclipse event fit in surprisingly well with Oreo’s marketing, with the vanilla creme center and the chocolate biscuit wafer symbolizing the synergy between the sun and moon during a solar eclipse. There usually isn’t much of a hidden meaning behind the naming schemes except being alphabetical and dessert-inspired, but in this case, Google saw the perfect opportunity to ensure its latest release benefits and complements the solar eclipse and remains a talking point with the common people.

What’s new in Android 8.0 Oreo?

Android Oreo brings with it a host of new features and improvements over Android Nougat. While not all of them would be immediately visible to end users, they would surely contribute towards the end experience of a mature smartphone OS.

Redesigned Emojis

Android Oreo bids goodbye to the blob emojis that we had grown used to in the past Android versions. In their place are a redesigned set of emojis which are rounder than blob emojis.

Background Limits

Battery life continues to be a priority for Google in Oreo. Android 8.0 puts additional automatic limits on what apps can do in the background in these three main areas: implicit broadcasts, background services and location updates. We discussed in detail how Google was laying the foundations for killing rogue background processes in Android Nougat, and now the company is making additional changes to rein in rogue applications draining your battery life.

Notification Channels

Android Oreo introduces notification channels to provide a unified system to help users manage notifications with app-defined categories for notification content. This will allow developers to create a notification channel for each distinct type of notification that they need to send as well as to reflect choices made by users of the app. Users can also manage most of the settings associated with notifications using a consistent system UI. Once a notification channel is created, only the system can change its importance, giving power back to the user. Users can also snooze notifications to reappear at a later time. Notifications will reappear with the same level of importance they first appeared with.

Furthermore, Android Oreo also adds new visuals and grouping to notifications that make it easier for users to see what’s going on when they have an incoming message or are glancing at the notification shade.

Autofill APIs

Android Oreo officially recognizes the role of password managers by including an Autofill API. This platform support for autofill will make it possible for users to select an autofill app the same way they select a keyboard app. Google is adding new APIs to implement an Autofill service as well.

Picture in Picture for phones, and new Windowing features

PiP display is now available for phones as well as tablets, so users can now look forward to watching a video while they’re answering a chat or any other such task. Other new windowing features include a new app overlay window for apps to make use of, and multi-display support for launching an activity on a remote display.

Adaptive Icons and Font Resources in XML

Android Oreo brings adaptive icons which can now display a variety of shapes across different devices and models. You can set a launcher icon using a circular shape on one OEM device and use a “squircle” on another. Each device OEM will provide a mask which the system then uses to render all icons with the same shape. The system also animates interactions with the icons and also uses the icons in shortcuts, the Settings app, the sharing dialog, and the overview screen.

Fonts are now a fully supported resource type in Android Oreo. Apps can now use fonts in XML layouts as well as declare font style and weight along with the font files.

 Support for Wide-gamut color for apps

Developers of imaging apps can now take advantage of new devices that have a wide-gamut color capable display. To display wide gamut images, apps will need to enable a flag in their manifest per activity and load bitmaps with an embedded wide color profile. We’re been clamoring for this feature for months, and it appears Google has finally answered our prayers.


Android O also supports high-quality Bluetooth audio codecs such as the LDAC codec from Sony as well as aptX support, which is a high-quality Bluetooth codec from Qualcomm.

New Wi-Fi features include Wi-Fi Aware, also known as Neighborhood Aware Networking (NAN). On devices with appropriate hardware, apps and nearby devices can discover and communicate with each other over Wi-Fi without an Internet access point.

There’s also new Bluetooth functionality such as bluetooth battery level indicators and bluetooth in-band ringtones. While small improvements in their individual capacity, these contribute towards the maturity of the OS.

Accessibility Feature: Fingerprint Gestures

Accessibility services can also respond to alternative input mechanisms such as a directional swipe gesture along a device’s fingerprint sensor. This means that third-party developers can take advantage of fingerprint gestures, officially, to perform their own actions!

Android 8.0 Oreo is being pushed to the Android Open Source Project (AOSP) for everyone to access today. The update builds for Nexus 5X, Nexus 6P and Pixels has entered into carrier testing, and Google expects the phased roll out to begin soon alongside that of the Pixel C and Nexus Player. Google is also working closely with OEM partners like Essential, General Mobile, HMD Global, Huawei, HTC, Kyocera, LG, Motorola, Samsung, Sharp and Sony to ensure that new devices are either launched with Android 8.0 Oreo or are upgraded to the latest sweet. Further, devices in the Android Beta Program will also receive this final version.

We can’t wait to get our hands on the latest treat, just to see what else Google is hiding under the hood!

What are your thoughts on Android 8.0 Oreo? Do you agree with Google’s nomenclature choice for this version? Let us know in the comments below!


from xda-developers

Sony Losses Class Action Lawsuit in Waterproof Claims for Original Xperia Z Line

Arguably, one of the pioneers in the consumer sector for more “rugged” devices (or at the very least IP certification) has to be Sony. Back in 2012, they introduced the Xperia Z line of the devices, which marked a turning point for Sony in most of its philosophy as well as its design language.

They completely overhauled the look and feel of the devices they had in favor of the glass slab that they offer even in today’s phones and tablets. Despite its fragile appearance, most of their offerings were drop-tested and were able to withstand a substantial amount of mistreatment. On top of all that, the Sony Xperia Z was the first commercially available phone from Sony to me, marketed as “water resistant” with an IP56 rating for water and dust ingress (which isn’t really much, but at least it would keep your phone going in spite of an accidental drop in the beach or in the pool). However, the phone was advertised in such a way that it it looked as if the device was waterproof and not water resistant (there is a big difference). This led to a lot of water-damaged devices, which Sony did nothing about and eventually, a class action lawsuit was filed (and won) against Sony.

People used to do all sorts of crazy things with the phones. Everything from dropping them on concrete, to dunking them on glasses of water, wine, beer, hot chocolate, and there is even a video in Youtube of someone cooking the device in soup (because why not, right?) Then, you had the more “sane” ones (like yours truly) who would simply use the device, at most to take pictures in a pool (at around 2 inches in depth) to test how the camera would perform under water. There were some precautions that needed to be taken before the water activities took place, like for instance making sure all the access ports were securely closed to prevent water ingress. Personally, I always did it with my phone. However, one day, my Xperia Z simply stopped working.

I decided to have a close look at the ports (which had multiple water detecting strips) to see if maybe I had forgotten to close the lids as per manufacturer instructions. The water indicators were white as snow, which means that either the device was failing for a different reason or water had gone in through a different place. Upon closer inspection of the device, I noticed that the back glass panel of the phone was raised and could actually be pressed back into place only for it to pop up again. The area was right around where the processor was placed (a Snapdragon S4 Pro) and it was no surprise as there were reported overheating issues with the device.

Upon closer inspection, I found that the glass on the back was warped, likely because of the heat coming from the chipset, which also likely loosened the glue thus compromising seals in place to prevent water from getting in. With all this information (as well as a myriad of complains about similar issues in our forum as well as Sony’s official forum), I decided to send my device over to Sony for a warranty repair. About 2 weeks later, I received an e-mail update from Sony stating that my device was on its way back to me and that I was correct in my assumption as the technicians had found rust caused by water shorting some components inside the device. However, because it was me who used the device under water, they said the damage was my fault and was not covered under the warranty (despite the device supposedly being able to withstand light water immersion). In case you are wondering, they also included the pictures of the water indicators being white in the report, which means that it was not really going in through a user-accessible area (in other words, water did not go in because I did not follow directions). Since my phone had turned into a glass covered paper weight, I decided to sell it on eBay for spares (as the screen and everything else was immaculate.)

Fast forward a few years, as it turns out most other people who suffered a similar fate did not sit idly and decided to file a Class Action lawsuit against Sony. According to the settlement, there were 24 models affected (ironically, the original Z is not listed as being one of them) starting from the ZR, which was a close cousin of the original Z and going all the way to the Xperia Z5, along with a few tablets as well. The settlement goes on to state that there are a few things that, if you were affected, you can opt for:

  • Warranty extension for up to a year if the device is within warranty period;
  • Warranty extension for up to 6 months if the device is no longer under warranty;
  • Up to 50% of MSRP as refund for compensation if the device is listed among the ones on the Sony lawsuit;

If you are going for the cash alternative, you do have a deadline to meet, which is January,30, 2018. Whichever course of action you do decide to take, please make sure that you understand the entire lawsuit document before doing anything!

Did you get affected by this or any other similar marketing claims? Please share your experiences in the comments below!

You can find more information about the lawsuit in the official Landes v. Sony Mobile Communications site.

Via: PhoneArena

from xda-developers

Chrome OS Gets its Own Product Type for Chromecast

Chromecast started out as a side project for Google that quickly turned into the best selling hardware device the company sells. Over 3.8 million were sold in the first 12 months it was launched and last year at Google I/O we learned that the company had sold over 25 million units since its inception (and is now up to 30 million). With its success, you would think that Google would be paying more attention to the small details surrounding this product.

However, Google even seems to be struggling with the branding over the years. March of last year we saw the company try to rebrand the casting technology behind the Chromecast device to Google Cast. Then less than a year later we saw reports of this being changed for 3rd-party products from Google Cast to “Chromecast Built-in.” Google had even removed the Google Cast name from the landing page on their website, which to this day shows the new branding and redirects you to a different landing page.

At that time though, the Google Cast branding name was still on places such as their Android TV landing page. This has since been updated with the Chromecast Built-in moniker, but it’s interesting to see the company go through these transitions over the years. Another small detail that seems to have been overlooked for quite some time is how a Chrome OS device is labeled when it is streaming to a Chromecast supported product.

In the Google Home application, any streams to a Chromecast device that is registered to your account shows up there. It confused many people that Chrome OS wasn’t labeled properly here since the operating system is a 1st-party product from Google. However, a new commit on the Chromium Gerrit shows that Chrome OS is getting its own product type. This commit says it will allow the Cast Receiver on Chrome OS to be properly recognized as a standalone product by other components of the Cast ecosystem (like the Google Home application).

from xda-developers

Google is Adding Support for eMBMS for Reduced Mobile Network Congestion

In one of the latest additions to AOSP, Google has added eMBMS support. eMBMS stands for Evolved Multimedia Broadcast/Multicast Service, and is also known as LTE Broadcast. This technology is present in the Snapdragon 800 series and later, and Google is now adding full support for the service. This service is hugely beneficial when many people are likely to want to watch or view the same content within a region or network. A situation it may be used in, for example, is wanting to broadcast different angles of a live event. Rather than streaming individual videos to each user (unicast), the same video streams are sent to everyone at the same time and the users themselves choose (multicast).

What is eMBMS?

To explain eMBMS, multicasting needs to be explained first. As said above, multicasting is a system for sending video streams to various users at a time without overloading the system it’s using.

eMBMS Demonstration. Video by Anandtech.

This technology first debuted in the MSM8974, more commonly known as the Snapdragon 800, which came in the Nexus 5 and many other flagship devices of 2013. eMBMS can be useful in places such as stadiums for broadcasting to devices of spectators. Running this on mobile networks (which is what eMBMS is) would mean that for data being sent to many people, such as a new software update, those on LTE may face decreased network congestion due to this technology.

eMBMS is multicasting but on a mobile data network. It’s aimed at providing emergency alerts, software updates, live stream services and mobile TV and radio broadcasting. Verizon in America have already launched this service, and it has been deployed at a few events in recent years. The technology was first demonstrated at a large scale event in February 2014 at the Super Bowl XLVIII by Verizon. Samsung Galaxy Note 3’s (one of the first Snapdragon 800 devices) were used and various points of view one could choose were transmitted to each device. The videos were broadcast at 1.8Mbps and the data feed was at 750Kbps. As well as all of that, Nokia documented that eMBMS actually reduces costs for the provider, due to its efficiency. All of this is for combating the 1000x data challenge that we will eventually face.

What is the 1000x Data Challenge?

The 1000x data challenge is a phenomenon that Qualcomm is trying to combat before it becomes a major problem. This is a scenario wherein there are so many devices that they are requiring 1000 times the amount of bandwidth that can be supplied at a given time. According to a recent study from Cisco in June 2017, the forecasted amount of data that will be used for video across the internet by the year 2021 is a staggeringly high 82%. This is a huge amount of bandwidth. To show just how much video we watch, Cisco claimed that each month we will consume more than 5 million years of video.

Thankfully, with Multicast and eMBMS technology, this challenge can be faced appropriately. Rather than continuously ramping up server power and costs, we can benefit from a more efficient, long term solution in the form of eMBMS, or LTE broadcast, technology, especially now that it is being included in AOSP source. This means that theoretically, any Android device on the next release should support eMBMS, as any Snapdragon device since the 800 series supports it. Currently, the main front runners supporting this technology are as follows: Verizon in America, Kt and Reliance in Asia and EE and Vodafone in Europe. We hope to see more network providers supplying this technology, as with modern day connections it can sometimes be vital to access an uncongested and working internet connection anywhere you are.

from xda-developers

Chrome Receiving Support for EAC-3 (Dolby Digital Plus) Passthrough

Chrome will receive support for Dolby Digital Plus (also known as Enchanced AC-3) passthrough in an upcoming update, as can be seen on the Chromium Gerrit. This is a huge addition for those using Android TVs with a sound system which uses Dolby Digital Plus. Dolby Digital Plus is an advanced surround sound audio technology that has found its way into many home devices, including home theaters and car sound systems.

The commit description is as follows:

When the connected HDMI receiver supports (E)AC3 passthrough, we can directly pass raw compressed (E)AC3 bitstream to AudioTrack.

This addition is beneficial to audio enthusiasts, as this means you no longer need to rely on the device running Chrome to decode it. Instead, you let your preferred audio system do all of the decoding and rendering of the audio data that it needs to do. This should usually lead to enhanced audio quality, as the device will be optimized by the manufacturer for the best audio quality on the Dolby Digital Plus device. This upgrade is especially important for Android TVs, as they are the most likely to be outputting to a sound bar or other Hi-Fi devices supporting this.

The raw audio part refers to audio before it’s processed. When the system processes audio, sometimes it may apply equalization, compression or loudness-boosting in certain frequencies. These are to provide a “better audio experience” but may actually be a detriment to the enjoyment of someone with a high-end system that can do its own decoding and processing. Providing the already-processed audio to an EAC-3 enabled device would be defeating the purpose of such a device. Dolby Digitial Plus, for example, supports up to 5 audio channels at 640kbps, while Android TV if playing from an older version of Chrome will feed 320kbps in a single audio channel to the device, as the device will do the processing and then output to the sound system. For audio enthusiasts this is a huge addition, and also means anything using Chrome custom tabs will get the same treatment.

Source: Chromium Gerrit

from xda-developers