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

The Google Assistant Developer Platform will be Available in December

At Google I/O earlier this year, the company announced a new service that would be used in a number of its products and services: Google Assistant. Google Assistant is an enhanced version of Google Now, and is currently being featured in Allo, the Pixel, Pixel XL and Google Home. During the Pixel launch event last month, we learned that Google would be opening Google Assistant to developers with APIs they are calling Actions on Google.

The main reason why people are enjoying Amazon's personal assistant, Alexa, so much is because of how many 3rd-party services that can connect to it. It seems like each month the company is rolling out another update with new skills for their customers to take advantage of. If Google Home, and ultimately Google Assistant, is going to be as popular and as useful then it will need a lot of 3rd-party developer support as well. And Google has realized this too.

Google did announce the Actions on Google API during the October launch event, but they did not tell us when they would make it available to developers. While we still don't have an exact date, we do know these APIs will be open to developers sometime in December. You can check out the landing page for Actions on Google right here, and this will let you sign up to be notified about any news and updates for the service.

Google has a lot of catching up to do if they want Google Assistant to compete with Alexa. We'll have to wait and see how many 3rd-party developers jump on board once the Actions on Google API has been made available. It's being reported that Google is already working with a number of brands to get them familiar with the system. These partners include Spotify, CNN, Uber and OpenTable.

Source: Google

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

$13 Android Lav Mic Review

It's time for another adventure into the world of crappy Android accessories. This time we are trying out a lav mic that is said to work with any smartphone.

For those of you looking to improve the audio recordings from your phone, this might be the solution for you. It depends on if this lav mic is compatible with your device. While the product description suggests that this mic will work with any Android device, I was only able to get it to work on my Sony Xperia Z3 Tablet Compact. No luck with my Nexus 6P or Honor 8.

When it does work, it works well. You can use the default camera app or any recording app to make use of the mic. Personally I will use this to capture audio when filming with my DSLR, then sync the audio afterwards in editing. This is probably the main reason people buy this particular product. For this purpose, the $13 investment is worth it. Of course this is depending on if you have a compatible device.

Check out the Lavalier Lapel Microphone on Amazon, using our affiliate link here.

What would you like to see featured in an Android Crap video? Let me know in the comments down below!

 

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

Android Auto Now Available for Every Car through Updated App on Smartphones

While there are over 200 car models from more than 50 brands that support Android Auto, chances are you haven't gotten around to trying it yet. More are still launching every day, but to regular middle-class folk a car upgrade is not a frequent occurrence.

This is why Google is now announcing Android Auto functionality for smartphones, allowing you to use any smartphone running Lollipop or later as a mini car dashboard. This is an update to the Android Auto app that gives your phone a driver-friendly interface with easy, glanceable access to everything you need on the road. From it, you can check directions, control your music or manage communications, all with as few distractions as possible for safe driving.

You can either place your phone in a mount or connect it to your car's display to turn your not-so-smart dashboard into a driver-friendly screen. Control your music with apps like Spotify or Play Music, make calls, and control Google Maps for turn-by-turn navigation all with minimal interaction and even some hands-free voice commands. You can also start the app automatically when your phone pairs to a Bluetooth-supported car mount or the car itself. Finally, voice commands are getting enhanced in the coming weeks to make the experience more accessible, smoother and safer.

This is certainly the right way to go for Android Auto as a service going forward. Not being limited to expensive implementations in specific cars will allow everyone to get a better Android car experience. We can't wait to test the update ourselves, but in the mean time you can find the original Android Auto app on the Playstore to wait for the update or download the new APK.

More than 30 countries (where Android Auto is currently available) are receiving the updates in the coming days. You can sign up on the Android Auto website to receive an email notification once it becomes available to your device!

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

General Mobile GM 5 is the 1st Android One Phone to Ship with Nougat

It's been a while since we've seen a new Android One smartphone announced. Google had actually removed the Android One section from the official Android website (now the old URL simply redirects to the homepage of Android.com), so many were wondering what the future held for Google's experimental Android project.

Some thought that it would be abandoned like we saw with the Google Play Edition phones, while others were holding onto hope that we would see more Android One products launched.

Android One had a goal of letting smartphone OEMs focus solely on the hardware so Google could take full control of the software. To accomplish this though, Google had strict guidelines as to what type of hardware would be allowed in the phone, as well as how much the smartphone OEM could charge for it. Sadly, this vision was not as successful as some had wanted and it forced Google to be more open with their rules and guidelines of the hardware and its pricing.

General Mobile has just announced the latest Android One smartphone and it is called the GM 5. The device will be available in Gold, Black and Space Gray colors and it will be the first Android One smartphone to ship with Android 7.0 Nougat. The General Mobile GM 5 has a 5″ 720p display with Gorilla Glass 4 protection, a Snapdragon 410 SoC, 2GB of RAM, 16GB of internal storage, microSD card slot, 5MP front-facing camer, a 13MP rear camera, the option of 1 or 2 SIM slots, and a 2,500mAh capacity battery.

The General Mobile GM 5 will be marketed for the internal market and will be sold in countries including Azerbaijan, Albania, Afghanistan, Belgium, Bosnia, Croatia, Cyprus, Georgia, Ghana, Greece, Iraq, Kenya, Luxembourg, Moldova, Netherlands, Pakistan, Serbia, Tunisia, Turkey, and Uzbekistan. Pricing has yet to be revealed, but we will learn more when it is made available for purchase later this month.

Source: General Mobile

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