Tampilkan postingan dengan label Develop. Tampilkan semua postingan
Tampilkan postingan dengan label Develop. Tampilkan semua postingan

Rabu, 20 Juli 2016

Connecting your App to a Wi-Fi Device

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:


  • WiFiManager#startScan returns a list of available Wi-Fi networks. They are
    primarily identified by SSID.
  • WiFiManager#getConfiguredNetworks returns a list of the Wi-Fi networks
    configured on the device, also indexed by SSID, but they are not necessarily
    currently available.
  • ConnectivityManager#getAllNetworks returns a list of networks that are being
    interacted with by the phone. This is necessary as from Lollipop onwards a
    device may be connected to multiple networks at once, Wi-Fi, LTE, Bluetooth,
    etc… The current state of each is available by calling href="https://developer.android.com/reference/android/net/ConnectivityManager.html#getNetworkInfo(android.net.Network)">ConnectivityManager#getNetworkInfo
    and is identified by a network ID.


In all versions of Android you start by scanning for available Wi-Fi networks
with href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#startScan()">WiFiManager#startScan,
iterate through the href="https://developer.android.com/reference/android/net/wifi/ScanResult.html">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 href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#getConfiguredNetworks()">WifiManager#getConfiguredNetworks
and iterating through the href="https://developer.android.com/reference/android/net/wifi/WifiConfiguration.html">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 href="https://developer.android.com/reference/android/net/wifi/ScanResult.html">ScanResults
are not.



If your network is configured you can obtain the network ID from the
WifiConfiguration object. Otherwise you can configure it using href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#addNetwork(android.net.wifi.WifiConfiguration)">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
href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#NETWORK_STATE_CHANGED_ACTION">WifiManager.NETWORK_STATE_CHANGED_ACTION
and then call href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#enableNetwork(int,%20boolean)">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 href="https://developer.android.com/reference/android/net/wifi/WifiManager.html#getConnectionInfo()">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 href="https://developer.android.com/reference/android/net/ConnectivityManager.html#setProcessDefaultNetwork(android.net.Network)">ConnectivityManager#setProcessDefaultNetwork
on Lollipop devices, and on Marshmallow call href="https://developer.android.com/reference/android/net/ConnectivityManager.html#bindProcessToNetwork(android.net.Network)">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:


  • For HTTP requests you can use href="https://developer.android.com/reference/android/net/Network.html#openConnection(java.net.URL)">Network#openConnection(java.net.URL),
    directly routing your request to this network.
  • For low-level socket communication, open a socket and call href="https://developer.android.com/reference/android/net/Network.html#bindSocket(java.net.Socket)">Network#bindSocket(java.net.Socket),
    or alternatively use href="https://developer.android.com/reference/android/net/Network.html#getSocketFactory()">Network#getSocketFactory.


Now you can keep your users connected whilst they benefit from your innovative
Wi-Fi enabled products.



Selasa, 19 Juli 2016

Strictly Enforced Verified Boot with Error Correction

Posted by Sami Tolvanen, Software Engineer



Overview



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 href="https://g.co/ABH">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.


Error-correcting codes



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.



href="https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction">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 href="https://en.wikipedia.org/wiki/Erasure_code">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.


Recovering from consecutive corrupted blocks



In the changes we made to href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a739ff3f543afbb4a041c16cd0182c8e8d366e70">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.


Conclusion



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.



Senin, 18 Juli 2016

Final Developer Preview before Android 7.0 Nougat begins rolling out

Posted by Dave Burke, VP of Engineering






As we close in on the public rollout of href="https://developer.android.com/preview/index.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog">Android 7.0 Nougat
to devices later this summer, today we’re releasing Developer Preview
5
, the last milestone of this preview series. href="http://android-developers.blogspot.com/2016/06/android-n-apis-are-now-final.html">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:


  • System images for Nexus and other preview devices
  • An emulator that you can use for doing the final testing of your apps to
    make sure they’re ready
  • The final N APIs (API level 24) and latest system behaviors and UI
  • The latest bug fixes and optimizations across the system and in preinstalled
    apps


Working with this latest Developer Preview, you should make sure your app
handles all of the href="https://developer.android.com/preview/behavior-changes.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog">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 href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog">new developer
features in Android N such as href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#multi-window_support">Multi-window
support, Direct Reply and other href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#notification_enhancements">notifications
enhancements, href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#direct_boot">Direct
boot, href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_developerpreview5_071816&utm_source=anddev&utm_medium=blog#emoji">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 href="https://developer.android.com/distribute/engage/beta.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">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 href="https://android.com/beta">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 href="https://developer.android.com/preview/download.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog#flash">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 href="https://code.google.com/p/android/issues/list?can=2&q=label%3ADevPreview-N">N
Developer Preview issue tracker, href="https://plus.google.com/communities/103655397235276743411">N Preview
Developer community, or href="https://plus.google.com/communities/106765800802768335079">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!