Posted by Rich Hyndman, Android Developer Advocate
With the growth of the Internet of Things, connecting Android applications to Wi-Fi enabled devices is becoming more and more common. Whether you’re building an app for a remote viewfinder, to set up a connected light bulb, or to control a quadcopter, if it’s Wi-Fi based you will need to connect to a hotspot that may not have Internet connectivity.
From Lollipop onwards the OS became a little more intelligent, allowing multiple network connections and not routing data to networks that don’t have Internet connectivity. That’s very useful for users as they don’t lose connectivity when they’re near Wi-Fis with captive portals. Data routing APIs were added for developers, so you can ensure that only the appropriate app traffic is routed over the Wi-Fi connection to the external device.
To make the APIs easier to understand, it is good to know that there are 3 sets of networks available to developers:
In all versions of Android you start by scanning for available Wi-Fi networks with WiFiManager#startScan, iterate through the ScanResults looking for the SSID of your external Wi-Fi device. Once you’ve found it you can check if it is already a configured network using WifiManager#getConfiguredNetworks and iterating through the WifiConfigurations returned, matching on SSID. It’s worth noting that the SSIDs of the configured networks are enclosed in double quotes, whilst the SSIDs returned in ScanResults are not.
If your network is configured you can obtain the network ID from the WifiConfiguration object. Otherwise you can configure it using WifiManager#addNetwork and keep track of the network id that is returned.
To connect to the Wi-Fi network, register a BroadcastReceiver that listens for WifiManager.NETWORK_STATE_CHANGED_ACTION and then call WifiManager.enableNetwork (int netId, boolean disableOthers), passing in your network ID. The enableNetwork call disables all the other Wi-Fi access points for the next scan, locates the one you’ve requested and connects to it. When you receive the network broadcasts you can check with WifiManager#getConnectionInfo that you’re successfully connected to the correct network. But, on Lollipop and above, if that network doesn’t have internet connectivity network, requests will not be routed to it.
Routing network requests
To direct all the network requests from your app to an external Wi-Fi device, call ConnectivityManager#setProcessDefaultNetwork on Lollipop devices, and on Marshmallow call ConnectivityManager#bindProcessToNetwork instead, which is a direct API replacement. Note that these calls require android.permission.INTERNET; otherwise they will just return false.
Alternatively, if you’d like to route some of your app traffic to the Wi-Fi device and some to the Internet over the mobile network:
Now you can keep your users connected whilst they benefit from your innovative Wi-Fi enabled products.
Posted by Lily Sheringham, Google Play team
Based in Dublin, Ireland, StoryToys is a leading publisher of interactive books and games for children. Like most kids’ app developers, they faced the challenges of engaging with the right audiences to get their content discovered. Since the launch of the Family section on Google Play, StoryToys has experienced an uplift of 270% in revenue and an increase of 1300% in downloads.
Hear Emmet O’Neill, Chief Product Officer, and Gavin Barrett, Commercial Director, discuss how the Family section creates a trusted and creative space for families to find new content. Also hear how beta testing, localized pricing and more, has allowed StoryToy’s flagship app, My Very Hungry Caterpillar, to significantly increase engagement and revenue.
Learn more about Google Play for Families and get the Playbook for Developers app to stay up-to-date with more features and best practices that will help you grow a successful business on Google Play.
Posted by Sami Tolvanen, Software Engineer
Android uses multiple layers of protection to keep users safe. One of these layers is verified boot, which improves security by using cryptographic integrity checking to detect changes to the operating system. Android has alerted about system integrity since Marshmallow, but starting with devices first shipping with Android 7.0, we require verified boot to be strictly enforcing. This means that a device with a corrupt boot image or verified partition will not boot or will boot in a limited capacity with user consent. Such strict checking, though, means that non-malicious data corruption, which previously would be less visible, could now start affecting process functionality more.
By default, Android verifies large partitions using the dm-verity kernel driver, which divides the partition into 4 KiB blocks and verifies each block when read, against a signed hash tree. A detected single byte corruption will therefore result in an entire block becoming inaccessible when dm-verity is in enforcing mode, leading to the kernel returning EIO errors to userspace on verified partition data access.
This post describes our work in improving dm-verity robustness by introducing forward error correction (FEC), and explains how this allowed us to make the operating system more resistant to data corruption. These improvements are available to any device running Android 7.0 and this post reflects the default implementation in AOSP that we ship on our Nexus devices.
Using forward error correction, we can detect and correct errors in source data by shipping redundant encoding data generated using an error-correcting code. The exact number of errors that can be corrected depends on the code used and the amount of space allocated for the encoding data.
Reed-Solomon is one of the most commonly used error-correcting code families, and is readily available in the Linux kernel, which makes it an obvious candidate for dm-verity. These codes can correct up to ⌊t/2⌋ unknown errors and up to t known errors, also called erasures, when t encoding symbols are added.
A typical RS(255, 223) code that generates 32 bytes of encoding data for every 223 bytes of source data can correct up to 16 unknown errors in each 255 byte block. However, using this code results in ~15% space overhead, which is unacceptable for mobile devices with limited storage. We can decrease the space overhead by sacrificing error correction capabilities. An RS(255, 253) code can correct only one unknown error, but also has an overhead of only 0.8%.
An additional complication is that block-based storage corruption often occurs for an entire block and sometimes spans multiple consecutive blocks. Because Reed-Solomon is only able to recover from a limited number of corrupted bytes within relatively short encoded blocks, a naive implementation is not going to be very effective without a huge space overhead.
In the changes we made to dm-verity for Android 7.0, we used a technique called interleaving to allow us to recover not only from a loss of an entire 4 KiB source block, but several consecutive blocks, while significantly reducing the space overhead required to achieve usable error correction capabilities compared to the naive implementation.
Efficient interleaving means mapping each byte in a block to a separate Reed-Solomon code, with each code covering N bytes across the corresponding N source blocks. A trivial interleaving where each code covers a consecutive sequence of N blocks already makes it possible for us to recover from the corruption of up to (255 - N) / 2 blocks, which for RS(255, 223) would mean 64 KiB, for example.
An even better solution is to maximize the distance between the bytes covered by the same code by spreading each code over the entire partition, thereby increasing the maximum number of consecutive corrupted blocks an RS(255, N) code can handle on a partition consisting of T blocks to ⌈T/N⌉ × (255 - N) / 2.
Interleaving with distance D and block size B.
An additional benefit of interleaving, when combined with the integrity verification already performed by dm-verity, is that we can tell exactly where the errors are in each code. Because each byte of the code covers a different source block—and we can verify the integrity of each block using the existing dm-verity metadata—we know which of the bytes contain errors. Being able to pinpoint erasure locations allows us to effectively double our error correction performance to at most ⌈T/N⌉ × (255 - N) consecutive blocks.
For a ~2 GiB partition with 524256 4 KiB blocks and RS(255, 253), the maximum distance between the bytes of a single code is 2073 blocks. Because each code can recover from two erasures, using this method of interleaving allows us to recover from up to 4146 consecutive corrupted blocks (~16 MiB). Of course, if the encoding data itself gets corrupted or we lose more than two of the blocks covered by any single code, we cannot recover anymore.
While making error correction feasible for block-based storage, interleaving does have the side effect of making decoding slower, because instead of reading a single block, we need to read multiple blocks spread across the partition to recover from an error. Fortunately, this is not a huge issue when combined with dm-verity and solid-state storage as we only need to resort to decoding if a block is actually corrupted, which still is rather rare, and random access reads are relatively fast even if we have to correct errors.
Strictly enforced verified boot improves security, but can also reduce reliability by increasing the impact of disk corruption that may occur on devices due to software bugs or hardware issues.
The new error correction feature we developed for dm-verity makes it possible for devices to recover from the loss of up to 16-24 MiB of consecutive blocks anywhere on a typical 2-3 GiB system partition with only 0.8% space overhead and no performance impact unless corruption is detected. This improves the security and reliability of devices running Android 7.0.
Posted by Dave Burke, VP of Engineering
As we close in on the public rollout of Android 7.0 Nougat to devices later this summer, today we’re releasing Developer Preview 5, the last milestone of this preview series. Last month’s Developer Preview included the final APIs for Nougat; this preview gives developers the near-final system updates for all of the supported preview devices, helping you get your app ready for consumers.
Here’s a quick rundown of what’s included in the final Developer Preview of Nougat:
Working with this latest Developer Preview, you should make sure your app handles all of the system behavior changes in Android N, like Doze on the Go, background optimizations, screen zoom, permissions changes, and more. Plus, you can take advantage of new developer features in Android N such as Multi-window support, Direct Reply and other notifications enhancements, Direct boot, new emojis and more.
Publish your apps to alpha, beta or production channels in Google Play
After testing your apps with Developer Preview 5 you should publish the updates to Google Play soon. We recommend compiling against, and optionally targeting, API 24 and then publishing to your alpha, beta, or production channels in the Google Play Developer Console. A great strategy to do this is using Google Play’s beta testing feature to get early feedback from a small group of users -- including Developer Preview users — and then doing a staged rollout as you release the updated app to all users.
How to get Developer Preview 5
If you are already enrolled in the Android Beta program, your devices will get the Developer Preview 5 update right away, no action is needed on your part. If you aren’t yet enrolled in Android Beta, the easiest way to get started is by visiting android.com/beta and opt-in your eligible Android phone or tablet -- you’ll soon receive this preview update over-the-air. As always, you can also download and flash this update manually. The Nougat Developer Preview is available for Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices, as well as General Mobile 4G [Android One] devices.
Thanks so much for all of your feedback so far. Please continue to share feedback or requests either in the N Developer Preview issue tracker, N Preview Developer community, or Android Beta community as we work towards the consumer release later this summer. Android Nougat is almost here!
Also, the Android engineering team will host a Reddit AMA on r/androiddev to answer all your technical questions about the platform tomorrow, July 19 from 12-2 PM (Pacific Time). We look forward to addressing your questions!
If you’re an indie game developer, you know that games are a powerful medium of expression of art, whimsy, and delight. Being on Google Play can help you reach over a billion users and build a successful, global business. That’s why we recently introduced programs, like the Indie Corner, to help more gamers discover your works of art.
To further celebrate and showcase the passion and innovation of indie game developers, we’re hosting the Google Play Indie Games Festival at the Terra Gallery in San Francisco, on September 24.
This is a great opportunity for you to showcase your indie title to the public, increase your network, and compete to win great prizes, such as Tango devices, free tickets for Google I/O 2017, and Google ad campaign support. Admission will be free and players will get the chance to play and vote on their favorites.
If you’re interested in showcasing your game, we’re accepting submissions now through August 14. We’ll then select high-quality games that are both innovative and fun for the festival. Submissions are open to US and Canadian developers with 15 or less full time staff. Only games published on or after January 1, 2016 or those to be published by December 31, 2016 are eligible. See complete rules.
We encourage virtual reality and augmented reality game submissions that use the Google VR SDK and the Tango Tablet Development Kit.
At the end of August, we’ll announce the group of indies to be featured at the festival.
You can learn more about the event here. We can’t wait to see what innovative and fun experiences you share with us!
Posted by Hoi Lam, Android Wear Developer Advocate
At Google I/O 2016, we launched the Android Wear 2.0 Developer Preview, which gives developers early access to the next major release of Android Wear. Since I/O, feedback from the developer community has helped us identify bugs and shape our product direction. Thank you!
Today, we are releasing the second developer preview with new functionalities and bug fixes. Prior to the consumer release, we plan to release additional updates, so please send us your feedback early and often. Please keep in mind that this preview is a work in progress, and is not yet intended for daily use.
compileSdkVersion
targetSdkVersion
WearableActionDrawer
peek_view
drawer_content
WearableDrawerView
notifyDataSetChanged
public class MainActivity extends Activity { ... @Override /* KeyEvent.Callback */ public boolean onKeyDown(int keyCode, KeyEvent event) { switch (keyCode) { case KeyEvent.KEYCODE_NAVIGATE_NEXT: Log.d(TAG, "Next"); break; case KeyEvent.KEYCODE_NAVIGATE_PREVIOUS: Log.d(TAG, "Previous"); break; } // If you did not handle, then let it be handled by the next possible element as deemed by // Activity. return super.onKeyDown(keyCode, event); } }
The Android Wear 2.0 Developer Preview includes an updated SDK with tools and system images for testing on the official Android emulator, the LG Watch Urbane 2nd Edition LTE, and the Huawei Watch.
To get started, follow these steps:
We will update this developer preview over the next few months based on your feedback. The sooner we hear from you, the more we can include in the final release, so don't be shy!
Posted by Chad Brubaker, Android Security team
In Android Nougat, we’ve changed how Android handles trusted certificate authorities (CAs) to provide safer defaults for secure app traffic. Most apps and users should not be affected by these changes or need to take any action. The changes include:
For more details on these changes and what to do if you’re affected by them, read on.
Apps have always been able customize which certificate authorities they trust. However, we saw apps making mistakes due to the complexities of the Java TLS APIs. To address this we improved the APIs for customizing trust.
Protection of all application data is a key goal of the Android application sandbox. Android Nougat changes how applications interact with user- and admin-supplied CAs. By default, apps that target API level 24 will—by design—not honor such CAs unless the app explicitly opts in. This safe-by-default setting reduces application attack surface and encourages consistent handling of network and file-based application data.
Customizing the CAs your app trusts on Android Nougat is easy using the Network Security Config. Trust can be specified across the whole app or only for connections to certain domains, as needed. Below are some examples for trusting a custom or user-added CA, in addition to the system CAs. For more examples and details, see the full documentation.
To allow your app to trust custom CAs only for local debugging, include something like this in your Network Security Config. The CAs will only be trusted while your app is marked as debuggable.
<network-security-config> <debug-overrides> <trust-anchors> <!-- Trust user added CAs while debuggable only --> <certificates src="user" /> </trust-anchors> </domain-config> </network-security-config>
To allow your app to trust custom CAs for a specific domain, include something like this in your Network Security Config.
<network-security-config> <domain-config> <domain includeSubdomains="true">internal.example.com</domain> <trust-anchors> <!-- Only trust the CAs included with the app for connections to internal.example.com --> <certificates src="@raw/cas" /> </trust-anchors> </domain-config> </network-security-config>
To allow your app to trust user-added CAs for multiple domains, include something like this in your Network Security Config.
<network-security-config> <domain-config> <domain includeSubdomains="true">userCaDomain.com</domain> <domain includeSubdomains="true">otherUserCaDomain.com</domain> <trust-anchors> <!-- Trust preinstalled CAs --> <certificates src="system" /> <!-- Additionally trust user added CAs --> <certificates src="user" /> </trust-anchors> </domain-config> </network-security-config>
To allow your app to trust user-added CAs for all domains, except for those specified, include something like this in your Network Security Config.
<network-security-config> <base-config> <trust-anchors> <!-- Trust preinstalled CAs --> <certificates src="system" /> <!-- Additionally trust user added CAs --> <certificates src="user" /> </trust-anchors> </base-config> <domain-config> <domain includeSubdomains="true">sensitive.example.com</domain> <trust-anchors> <!-- Only allow sensitive content to be exchanged with the real server and not any user or admin configured MiTMs --> <certificates src="system" /> <trust-anchors> </domain-config> </network-security-config>
To allow your app to trust user-added CAs for all secure connections, add this in your Network Security Config.
<network-security-config> <base-config> <trust-anchors> <!-- Trust preinstalled CAs --> <certificates src="system" /> <!-- Additionally trust user added CAs --> <certificates src="user" /> </trust-anchors> </base-config> </network-security-config>
To provide a more consistent and more secure experience across the Android ecosystem, beginning with Android Nougat, compatible devices trust only the standardized system CAs maintained in AOSP.
Previously, the set of preinstalled CAs bundled with the system could vary from device to device. This could lead to compatibility issues when some devices did not include CAs that apps needed for connections as well as potential security issues if CAs that did not meet our security requirements were included on some devices.
First, be sure that your CA needs to be included in the system. The preinstalled CAs are only for CAs that meet our security requirements because they affect the secure connections of most apps on the device. If you need to add a CA for connecting to hosts that use that CA, you should instead customize your apps and services that connect to those hosts. For more information, see the Customizing trusted CAs section above.
If you operate a CA that you believe should be included in Android, first complete the Mozilla CA Inclusion Process and then file a feature request against Android to have the CA added to the standardized set of system CAs.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
