Dirty Cow Vulnerability is Still Possible After November’s Security Update

Toward the end of last month, we reported on a very critical Linux vulnerability that made it possible to gain root access on every single Android device. It turns out, this privilege-escalation exploit has been present in the Linux kernel for 9 years. However, it hit public awareness last month. This vulnerability has been given the name Dirty Cow, and it was assigned as CVE-2016-5195 in the Linux bug tracker system.

By exploiting the Dirty Cow vulnerability, the user can take advantage of a bug that involves a race condition of the copy on write Linux memory duplication technique. The bug allows the user to actually have write-access on memory mappings that are normally read-only. When we wrote about the issue, it was already patched within the Linux kernel, however, Android users who want their device to be secure have not been so fortunate with the November security update.

Android OEMs have the control to patch anything they want on any of the phones they sell. For instance, BlackBerry actually patched the QuadRooter vulnerability before Google included it in their monthly Android security update. However, most OEMs will wait on Google to send out patches, and then a few (like LG and Samsung) will include some patches that are unique to their custom software.

Android's Senior Vice President, Hiroshi Lockheimer, has confirmed in an interview that Google generally patches Android exploits a month after they are made available to manufacturers. Lockheimer continues by telling us security patches go out to Android OEMs first, and then a month later they will be pushed out to Nexus and Pixel devices. This makes things fair for the Android OEMs as it gives them time to implement and test these patches, but it can leave users open to security vulnerability for an entire month (or more).

So we will likely see this Dirty Cow exploit patched in the December security update for Android, and a Google spokesman confirmed such schedule with ArsTechnica.

Source: Ars Technica

from xda-developers http://www.xda-developers.com/dirty-cow-vulnerability-is-still-possible-after-novembers-security-update/
via IFTTT

WhatsApp Extensions Xposed Module Adds Extra Functionality to WhatsApp

Open-source WhatsApp Extensions Xposed Module by XDA Senior Member Surajkumar adds in features like reply reminders, hiding last seen and read receipts, zooming profile photos and more!

from xda-developers http://www.xda-developers.com/xda-external-link/whatsapp-extensions-xposed-module-adds-extra-functionality-to-whatsapp/
via IFTTT

Latest Humble Mobile Bundle Features 7+ Board Games

Some digital board games in the Play Store are very popular and often end up costing around $5 a piece. The latest Humble Mobile bundle helps alleviate this financial burden by offering a number of popular games at a very enticing price. There are three tiers to this bundle with 8 games to start off with. Within a week, the Humble Bundle team will also announce which additional games will be added to the middle tier.

The first tier of the Humble Mobile Bundle features two games that will only cost you $1 combined. The first game in the tier is called Carcassonne and it can be compared to the likes of Civilization as it has you placing tiles with roads, cities, fields, and cloisters. The second game in this $1 tier is called Scotland Yard, a winner of the "Game of the Year" award for its physical version back in 1983 (which sold over 30 million units).

The price of the second tier is at $3, and paying this amount will get you the previously mentioned games, along with 3 more (and more additions that will be announced soon). The first game here is called Splendor, and you play as a merchant during the Renaissance while you acquire mines, transportation methods and artisans. Then there is the strategy game Catan where you'll compete with up to four players for the most settlements, the longest roads and the largest army. Last up for this tier is called THE aMAZEing Labyrinth, which has been out for 25 years, sold over 13 million copies of the physical version and tasks you with navigation various mazes.

The third and final tier of this Humble Mobile Bundle is priced at $5. Paying this much will get you all of the previously mentioned games as well as three more. First up we have Ticket To Ride (which will cost you $7 alone if you buy it from the Play Store right now) and comes with the official Ticket to Ride USA map along with 6 additional maps and 2 expansions. Then there is San Juan, a card game that has you taking on the role of the governor, builder, producer, trader or councilor. Finally there is Galaxy Trucker, a game that has you building space ships, dodge meteors, and fight off bad guys.

Source: Humble Mobile Bundle

from xda-developers http://www.xda-developers.com/latest-humble-mobile-bundle-features-7-board-games/
via IFTTT

HTC Publishes Revenue for October, Down 12.43% MoM

It's no surprise that HTC has been struggling to bring in a profit and increase the company's revenues for a while now. We have been covering this extensively since the company started seeing a decline and there have not been many positive aspects to look at throughout this troubling time for the Taiwanese technology company. Still, after all the issues the company has been having, they still sound very optimistic despite the drop in revenue.

Last month we reported on the company's Q3 earnings report and learned they lost $57 million after taxes. This was actually a loss of $63 million, but once you factor in taxes, the total amount reduced to $57 million. Despite that, they did have some good news for investors last month. They were able to bring in $700 million in overall revenue, which is up 18% compared to the quarter before and up 4% when compared to the same quarter of 2015.

However, things are not looking good for HTC this month. Granted, these monthly financial reports are unaudited, but they do give us a rough idea as to how well, or poorly, the company is doing. In the PDF press release linked below, HTC tells us their consolidated revenue for October of this year is NT$8.17 bn (which is $259.64 million). Then they go on to tell us that their overall revenue for January of this year all the way until October of this year is NT$64.09 bn.

However, what they exclude from this PDF press release is that these monthly numbers are actually down MoM and YoY. When looking at HTC's Investors page, we can see that October's monthly revenues were down 12.43% when compared to September revenues. On top of that, when we compare October's monthly revenues to October of last year, we see the numbers are down 8.66%.

Still, despite all of the troubles, HTC is still optimistic that they will see positive earnings throughout the fourth quarter as the HTC Vive picks up momentum thanks to the holiday season.

Source: HTC (PDF)

from xda-developers http://www.xda-developers.com/htc-publishes-october-revenues-down-12-43-mom/
via IFTTT

Android 7.0 Compatibility Document Released with Plenty of Interesting Changes

Earlier today, The updated Android 7.0 Compatibility Document was released. This document gives an outline to OEMs about what they can and should not change when creating android for their devices. It includes guidelines for Android Auto, Android TV, Wear, and for Phones and Tablets proper.

In the latest update, quite a bit has changed, and Reddit user and r/Android moderator IAmAN00bie took the time to comb through and point out all changes that really stuck out. Below is a list of his findings, as well as the ones we have noticed while reading the document:

APIs

• Confirmed: Android 7.0 does not require use of Vulkan APIs.
  • Device implementations, if not including support of the Vulkan APIs:
    • MUST report 0 VkPhysicalDevices through the vkEnumeratePhysicalDevices call.
    • MUST NOT declare any of the Vulkan feature flags
      PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL and PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.
• 3.1.1. Android Extensions
  • Android includes the support of extending the managed APIs while keeping the same API level version. Android device implementations MUST preload the AOSP implementation of both the shared library ExtShared and services ExtServices with versions higher than or equal to the minimum versions allowed per each API level. For example, Android 7.0 device implementations, running API level 24 MUST include at least version 1.

Android Auto

• Screen requirements for Android Auto:
  • Android Automotive devices MUST have a screen with the physical diagonal size greater than or equal to 6 inches.
  • Android Automotive devices MUST have a screen size of at least 750 dp x 480 dp.
• Android Auto temperature sensors must measure the cabin temperature:
  • For Android Automotive implementations, SENSOR_TYPE_AMBIENT_TEMPERATURE MUST measure the temperature inside the vehicle cabin.

Audio

• Under "Professional Audio" in CDD, there's a new set of requirements:
  • Latencies and USB audio requirements MUST be met using the OpenSL ES PCM buffer queue API.
• 7.8.2.1 Analog Audio Ports
  • In order to be compatible with the headsets and other audio accessories using the 3.5mm audio plug across the Android ecosystem, if a device implementation includes one or more analog audio ports, at least one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device implementation has a 4 conductor 3.5mm audio jack, it:
    • MUST support the detection and mapping to the keycodes for the following 3 ranges of equivalent impedance between the microphone and ground conductors on the audio plug:
      • 70 ohm or less : KEYCODE_HEADSETHOOK
      • 210-290 Ohm : KEYCODE_VOLUME_UP
      • 360-680 Ohm : KEYCODE_VOLUME_DOWN

Package Manager

• Here's something interesting I found that hasn't yet been covered yet:
  • The package manager MUST support verifying ".apk" files using the APK Signature Scheme v2 .
  • Here's the documentation for this change.

Display

• OEM settings that change Display Density/Size must follow AOSP implementation:
  • Device implementations are STRONGLY RECOMMENDED to provide users a setting to change the display size. If there is an implementation to change the display size of the device, it MUST align with the AOSP implementation as indicated below:
• Multi-window support must follow AOSP implementation:
  • 3.8.14. Multi-windows
    • A device implementation MAY choose not to implement any multi-window modes, but if it has the capability to display multiple activities at the same time it MUST implement such multi-window mode(s) in accordance with the application behaviors and APIs described in the Android SDK multi-window mode support documentation and meet the following requirements
• Seemingly very minor change:
  • MAY display affiliated recents as a group that moves together.

Android TV

• Android TV on 7.0 is required to support live pause/play:
  • 3.12.1.4. Time shifting
    • Android Television device implementations MUST support time shifting, which allows the user to pause and resume live content. Device implementations MUST provide the user a way to pause and resume the currently playing program, if time shifting for that program is available.
• Interesting changes to data storage requirements, tl;dr Android TV now requires minimum of 4GB while other devices must have at least 3GB
  • Android Television devices MUST have at least 4GB and other device implementations MUST have at least 3GB of non-volatile storage available for application private data. That is, the /data partition
    • MUST be at least 4GB for Android Television devices and at least 3GB for other device implementations. Device implementations that run Android are STRONGLY RECOMMENDED to have at least 4GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.
• New requirements with regards to TV controllers for Android TV:
  • The TV App MUST allow navigation for the following functions via the D-pad, Back, and Home keys on the Android Television device's input device(s) (i.e. remote control, remote control application, or game controller):
    • Changing TV channels
    • Opening EPG
    • Configuring and tuning to third-party TIF-based inputs
    • Opening Settings menu

Android Wear

• Interesting thing about navigation keys with regards to Android Wear:
  • Android Watch device implementations, and no other Android device types, MAY consume the long press event on the key event KEYCODE_BACK and omit it from being sent to the foreground application.
• Regarding Accessibility: Android Wear devices are recommended (but not required) to implement a talkback-like feature if they support audio output:
  • Android Watch devices with audio output SHOULD provide implementations of an accessibility service on the device comparable in or exceeding functionality of the TalkBack accessibility service (http://ift.tt/1G4KDcv).

Telephony

• Call blocking is now required to be implemented for 7.0 devices with telephony capabilities:
  • 7.4.1.1. Number Blocking Compatibility
    • Android Telephony device implementations MUST include number blocking support and:
      • MUST fully implement BlockedNumberContract and the corresponding API as described in the SDK documentation.
      • MUST block all calls and messages from a phone number in 'BlockedNumberProvider' without any interaction with apps. The only exception is when number blocking is temporarily lifted as described in the SDK documentation.
      • MUST NOT write to the platform call log provider for a blocked call.
      • MUST NOT write to the telephony provider for a blocked message.
      • MUST implement a blocked numbers management UI, which is opened with the intent returned by TelecomManager.createManageBlockedNumbersIntent() method.
      • MUST NOT allow secondary users to view or edit the blocked numbers on the device as the Android platform assumes the primary user to have full control of the telephony Page 59 of 85 services, a single instance, on the device. All blocking related UI MUST be hidden for secondary users and the blocked list MUST still be respected.
      • SHOULD migrate the blocked numbers into the provider when a device updates to Android 7.0.

Security/Kernel

• New kernel security requirements:
  • MUST split the media framework into multiple processes so that it is possible to more narrowly grant access for each process as described in the Android Open Source Project site.
• Safe Boot is outlined in the CDD, but is not required to be implemented:
  • 9.13. Safe Boot Mode
    • Android provides a mode enabling users to boot up into a mode where only preinstalled system apps are allowed to run and all third-party apps are disabled. This mode, known as "Safe Boot Mode", provides the user the capability to uninstall potentially harmful third-party apps. Android device implementations are STRONGLY RECOMENDED to implement Safe Boot Mode and meet following requirements:
      • Device implementations SHOULD provide the user an option to enter Safe Boot Mode from the boot menu which is reachable through a workflow that is different from that of normal boot.
      • Device implementations MUST provide the user an option to enter Safe Boot Mode in such a way that is uninterruptible from third-party apps installed on the device, except for when the third party app is a Device Policy Controller and has set the UserManager.DISALLOW_SAFE_BOOT flag as true.
      • Device implementations MUST provide the user the capability to uninstall any third-party apps within Safe Mode.
• Under "Managed Profile Support", something new regarding lock screens:
  • Support the ability to specify a separate lock screen meeting the following requirements to grant access to apps running in a managed profile.
    • Device implementations MUST honor the DevicePolicyManager.ACTION_SET_NEW_PASSWORD intent and show an interface to configure a separate lock screen credential for the managed profile.
    • The lock screen credentials of the managed profile MUST use the same credential storage and management mechanisms as the parent profile, as documented on the Android Open Source Project Site Page 24 of 85
    • The DPC password policies MUST apply to only the managed profile's lock screen credentials unless called upon the DevicePolicyManager instance returned by getParentProfileInstance

Data/Storage

• Data Saver feature is not required for OEMs to implement:
  • 7.4.7. Data Saver
    • Device implementations with a metered connection are STRONGLY RECOMMENDED to provide the data saver mode. If a device implementation provides the data saver mode, it:
      • MUST support all the APIs in the ConnectivityManager class as described in the SDK documentation.
      • MUST provide a user interface in the settings, allowing users to add applications to or remove applications from the whitelist.
    • Conversely if a device implementation does not provide the data saver mode, it:
      • MUST return the value RESTRICT_BACKGROUND_STATUS_DISABLED for ConnectivityManager.getRestrictBackgroundStatus
      • MUST not broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
      • MUST have an activity that handles the Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent but MAY implement it as a no-op.

This is just a selection of the full document. To read the full document for yourself, visit this link. We will be updating this page with more interesting changes as we find them. Let us know in the comments what you think about the new document and changes!

from xda-developers http://ift.tt/2ejAMwG
via IFTTT

Sony’s Concept for Android with 7.0 Nougat Launches for Xperia X

Way back in July 2015, Sony launched a unique "concept" software update for the Xperia Z3. Ordinarily, Sony Xperia devices came in with Sony's own skin and set of modifications on top of Android, but this concept software update was Sony experimenting with stock Android on its device. The best part about this experiment was that Sony was inviting users to be part of this project, even if Sony themselves did not have plans to abandon their own skin.

If you are a current Sony Xperia X user and are interested to see what the concept ROM experience is all about, there is some good news flowing in for you. The Xperia X is the latest addition to Sony's Concept for Android project, meaning that there will be opportunity for users to try out this ROM on their device. Additionally, since the concept ROM is based on Android 7.0 Nougat and features the stock Android experience without Sony's skin, you are practically getting a Nexus-like experience of the latest software on Sony hardware, provided to you directly by the OEM!

The latest Concept for Android for Xperia X includes:

• A sneak-peek at some of the latest features that will be part of future Xperia products
• Android 7.0, Nougat, which includes new native features such as multi-window support and improved notifications
• Access to Sony's inTouch community, providing direct access to Sony's software engineers and a chance to influence development & coming releases

The initiative is open initially to Xperia X (F5121) users in Europe. To participate in the experiment, download the Concept Installer app from the Google Play Store, and follow along the instructions to guide through the setup process. Perhaps the best part of this experiment is that it does not affect the warranty status of the device. Updates to the concept ROM are promised monthly, but users can opt-in for the alpha and experimental releases as well. You can also roll back to Sony's skin as well. You do lose your data, so users are advised to make backups beforehand.

We appreciate Sony bringing the pure Android experience to a new device and for a new OS version. We hope they extend this onto other devices as well.

What are your thoughts on Sony's Concept for Android program? Let us know in the comments below!

---

Source: Sony Mobile Blog

from xda-developers http://ift.tt/2fAsSfZ
via IFTTT

Google Releases Android’s Distribution Numbers for November

Google just released the November security update and around that time we also see the platform's official distribution numbers as well. This data was recorded during the 7-day period between November 1st and November 7th, and Google reminds us that any version of Android that doesn't make up at least 0.1% of the platform is not represented here in this graph. Yet, we're still seeing Android 2.2 Froyo being used by 0.1% of the people who are accessing the Play Store.

The big question here is how many people have been able to update to Android 7.0 Nougat since it was released, and now we have our answer. We're seeing that 0.3% of the platform has received their update and are using the latest version of Android. This is big as Nougat did not make an appearance in any of the previous Android's distribution reports. This is likely not as high of a percentage as many had hoped, but it's a start and it will continue to grow over the next year.

Next up, we have Android 6.0 Marshmallow, which has reached 24% of the overall user base for Android. This is up from 18.7% when compared to the September reports and was to be expected with it being shipped on new phones and more Lollipop devices being updated. Android 5.x Lollipop has actually dropped from 35% in September to 34.1% in November. But then we see that the Android 4.4 KitKat numbers have increased from 27.7% in September to 25.2% this month.

The numbers for Jelly Bean this month dropped again. They were sitting at 15.6% in September and are now at 13.7%. Both Ice Cream Sandwich and Gingerbread percentages dropped as well with both of them being on 1.3% of active devices in November when they were at 1.4% and 1.5% respectively in September. So most of the changes we have seen this month were expected, but it was a surprise to see the numbers for Lollipop dropping 0.9% compared to September.

Source: Android Developers

from xda-developers http://ift.tt/2eRRU91
via IFTTT