Showing posts with label Develop. Show all posts
Showing posts with label Develop. Show all posts

Wednesday, October 19, 2016

Improving Stability with Private C/C++ Symbol Restrictions in Android N


Posted by Dimitry Ivanov & Elliott Hughes, Software Engineers



As documented in the href="https://developer.android.com/preview/behavior-changes.html#ndk">Android N
behavioral changes
, to protect Android users and apps from unforeseen
crashes, Android N will restrict which libraries your C/C++ code can link
against at runtime
. As a result, if your app uses any private symbols from
platform libraries, you will need to update it to either use the public NDK APIs
or to include its own copy of those libraries. Some libraries are public: the
NDK exposes libandroid, libc, libcamera2ndk, libdl,
libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES,
libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are
private, and Android N only allows access to them for platform HALs, system
daemons, and the like. If you aren’t sure whether your app uses private
libraries, you can immediately check it for warnings on the N Developer Preview.


We’re making this change because it’s painful for users when their apps stop
working after a platform update. Whether they blame the app developer or the
platform, everybody loses. Users should have a consistent app experience across
updates, and developers shouldn’t have to make emergency app updates to handle
platform changes. For that reason, we recommend against using private C/C++
symbols. Private symbols aren’t tested as part of the Compatibility Test Suite
(CTS) that all Android devices must pass. They may not exist, or they may behave
differently. This makes apps that use them more likely to fail on specific
devices, or on future releases — as many developers found when Android 6.0
Marshmallow switched from OpenSSL to BoringSSL.


You may be surprised that there’s no STL in the list of NDK libraries. The three
STL implementations included in the NDK — the LLVM libc++, the GNU STL, and
libstlport — are intended to be bundled with your app, either by statically
linking into your library, or by inclusion as a separate shared library. In the
past, some developers have assumed that they didn’t need to package the library
because the OS itself had a copy. This assumption is incorrect: a particular STL
implementation may disappear (as was the case with stlport, which was removed in
Marshmallow), may never have been available (as is the case with the GNU STL),
or it may change in ABI incompatible ways (as is the case with the LLVM libc++).


In order to reduce the user impact of this transition, we’ve identified a set of
libraries that see significant use from Google Play’s most-installed apps, and
that are feasible for us to support in the short term (including
libandroid_runtime.so, libcutils.so, libcrypto.so, and libssl.so). For legacy
code in N, we will temporarily support these libraries in order to give you more
time to transition. Note that we don't intend to continue this support in any
future Android platform release, so if you see a warning that means your code
will not work in a future release — please fix it now!



Table 1. What to expect if your app is linking against private native libraries.

LibrariesApp's targetSdkVersionRuntime access via dynamic linkerImpact, N Developer PreviewImpact, Final N ReleaseImpact, future platform version
NDK PublicAnyAccessible
Private (graylist)<=23Temporarily accessibleWarning / ToastWarningError
>=24RestrictedErrorErrorError
Private (all other)>AnyRestrictedErrorErrorError



What behavior will I see?



Please test your app during the N Previews.


N Preview behavior



  • All public NDK libraries (libandroid, libc, libcamera2ndk, libdl, libGLES,
    libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++,
    libvulkan, and libz), plus libraries that are part of your app are accessible.
  • For all other libraries you’ll see a warning in logcat and a toast on the
    display. This will happen only if your app’s targetSdkVersion is less than N. If
    you change your manifest to target N, loading will fail: Java’s
    System.loadLibrary will throw, and C/C++’s dlopen(3) will return NULL.




Test your apps on the Developer Preview — if you see a toast like this one, your app is accessing private native APIs. Please fix your code soon!



N Final Release behavior



  • All NDK libraries (libandroid, libc, libcamera2ndk, libdl, libGLES,
    libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++,
    libvulkan, and libz), plus libraries that are part of your app are accessible.
  • For the temporarily accessible libraries (such as libandroid_runtime.so,
    libcutils.so, libcrypto.so, and libssl.so), you’ll see a warning in logcat for
    all API levels before N, but loading will fail if you update your app so that
    its targetSdkVersion is N or later.
  • Attempts to load any other libraries will fail in the final release of
    Android N, even if your app is targeting a pre-N platform version.



Future platform behavior



  • In O, all access to the temporarily accessible libraries will be removed.
    As a result, you should plan to update your app regardless of your
    targetSdkVersion prior to O. If you believe there is missing functionality from
    the NDK API that will make it impossible for you to transition off a temporarily
    accessible library, please file a bug here.



What do the errors look like?



Here’s some example logcat output from an app that hasn’t bumped its target SDK
version (and so the restriction isn’t fully enforced because this is only the
developer preview):




03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120


This is telling you that your library “libapplib.so” refers to the library
“libandroid_runtime.so”, which is a private library.


When Android N ships, or if you set your target SDK version to N now, you’ll see
something like this if you try to use System.loadLibrary from Java:

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by "/system/lib/libnativeloader.so"
is not accessible for the namespace "classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)


If you’re using href="http://man7.org/linux/man-pages/man3/dlopen.3.html">dlopen(3) from
C/C++ you’ll get a NULL return and href="http://man7.org/linux/man-pages/man3/dlerror.3.html">dlerror(3) will
return the same “dlopen failed...” string as shown above.


For more information about how to check if your app is using private symbols,
see the FAQ on developer.android.com.

Tuesday, October 18, 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!
Connecting your App to a Wi-Fi Device

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:


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:


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

Wednesday, July 20, 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.

Thursday, June 16, 2016

Android N APIs are now final, get your apps ready for Android N!

Posted by Dave Burke, VP of Engineering






As we put the finishing touches on the href="https://developer.android.com/preview/index.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">next release of
Android, which will begin to roll out to consumers later this summer, we’re
releasing the 4th Developer Preview of Android N, including the Android N final
SDK
. And thanks to your continued feedback over the last three releases, all of
the APIs are now final as well. If you’ve already enrolled your device in the
Android Beta Program, (available at href="https://android.com/beta">android.com/beta) you will receive an update
to this Developer Preview shortly.


Get your apps ready for Android N



The final SDK for Android N is now available for download through the SDK
Manager in Android
Studio
. It gives you everything you need to develop and test against the
official APIs in the Android N platform. Once you’ve installed the final SDK,
you can update your project’s compileSdkVersion to API 24 to
develop with the Android N APIs and build and test on the new platform, for href="https://developer.android.com/preview/api-overview.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">new features
such as Multi-window support, direct-reply notifications, and others. We also
recommend updating your app’s targetSdkVersion to API 24 to opt-in
and test your app with Android N specific href="https://developer.android.com/preview/behavior-changes.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">behavior
changes. For details on how to setup your app with the final SDK, see href="https://developer.android.com/preview/setup-sdk.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">Set up the
Preview. For details on API level 24 check out the href="https://developer.android.com/sdk/api_diff/24/changes.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">API diffs
and the updated href="https://developer.android.com/reference/packages.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">API reference,
now hosted online.



Along with the Android N final SDK, we’ve also updated the href="https://developer.android.com/topic/libraries/support-library/revisions.html?utm_campaign=android_launch_npreview_061516&utm_source=anddev&utm_medium=blog">Android
Support Library to 24.0.0. This allows you to use multi-window and
picture-in-picture callbacks, new notification features, methods for supporting
Direct Boot, and new MediaBrowser APIs in a backward compatible manner.


Publish your apps to alpha, beta or production channels in Google Play



Now that you have a final set of APIs, you can publish updates compiling with,
and optionally targeting, API 24 to Google Play. You can now publish app updates
that use API 24 to your alpha, beta, or even production channels in the Google
Play Developer Console. In this way, you can test your app’s
backward-compatibility and push updates to users whose devices are running
Developer Preview 4.



To make sure that your updated app runs well on Android N, as well as older
versions, a common strategy is to use 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 do a staged rollout as you release
the updated app to all users.


How to Get Developer Preview 4



Developer Preview 4 includes updated system images for all supported Preview
devices as well as for the Android emulator. If you are already enrolled in the
Android Beta program, your devices will
get the Developer Preview 4 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 (and later) preview
updates 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 N 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 and the Sony Xperia Z3.



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. We’re
looking forward to seeing your apps on Android N!















Friday, June 10, 2016

Security "Crypto" provider deprecated in Android N

Posted by Sergio Giro, software engineer



random_droid


If your Android app derives keys using the SHA1PRNG algorithm from the Crypto
provider, you must start using a real key derivation function and possibly re-encrypt your data.



The Java Cryptography Architecture allows developers to create an instance of a class like a cipher, or a pseudo-random number generator, using calls like:



SomeClass.getInstance("SomeAlgorithm", "SomeProvider");


Or simply:



SomeClass.getInstance("SomeAlgorithm");


For instance,



Cipher.getInstance(“AES/CBC/PKCS5PADDING”);


SecureRandom.getInstance(“SHA1PRNG”);


On Android, we don’t recommend specifying the provider. In general, any call to
the Java Cryptography Extension (JCE) APIs specifying a provider should only be
done if the provider is included in the application or if the application is
able to deal with a possible ProviderNotFoundException.



Unfortunately, many apps depend on the now removed “Crypto” provider for an
anti-pattern of key derivation.



This provider only provided an implementation of the algorithm “SHA1PRNG” for
instances of SecureRandom. The problem is that the SHA1PRNG algorithm is not
cryptographically strong. For readers interested in the details, On
statistical distance based testing of pseudo random sequences and experiments
with PHP and Debian OpenSSL
,Section 8.1, by Yongge Want and Tony Nicol,
states that the “random” sequence, considered in binary form, is biased towards
returning 0s, and that the bias worsens depending on the seed.



As a result, in Android N we are deprecating the
implementation of the SHA1PRNG algorithm and the Crypto provider altogether
.
We’d previously covered the issues with using SecureRandom for key derivation a
few years ago in href=http://android-developers.blogspot.com/2013/02/using-cryptography-to-store-credentials.html>Using
Cryptography to Store Credentials Safely. However, given its continued use,
we will revisit it here.



A common but incorrect usage of this provider was to derive keys for encryption
by using a password as a seed. The implementation of SHA1PRNG had a bug that
made it deterministic if setSeed() was called before obtaining output. This bug
was used to derive a key by supplying a password as a seed, and then using the
"random" output bytes for the key (where “random” in this sentence means
“predictable and cryptographically weak”). Such a key could then be used to
encrypt and decrypt data.



In the following, we explain how to derive keys correctly, and how to decrypt
data that has been encrypted using an insecure key. There’s also a
full example
, including a helper class to use the deprecated SHA1PRNG
functionality, with the sole purpose of decrypting data that would be otherwise
unavailable.



Keys can be derived in the following way:




  • If you're reading an AES key from disk, just store the actual key and don't go through this weird dance. You can get a SecretKey for AES usage from the bytes by doing:


    SecretKey key = new SecretKeySpec(keyBytes, "AES");


  • If you're using a password to derive a key, follow href="http://nelenkov.blogspot.com/2012/04/using-password-based-encryption-on.html">Nikolay Elenkov's excellent tutorial with the caveat that a good rule of thumb is the salt size should be the same size as the key output. It looks like this:



   /* User types in their password: */  
String password = "password";

/* Store these things on disk used to derive key later: */
int iterationCount = 1000;
int saltLength = 32; // bytes; should be the same size
as the output (256 / 8 = 32)
int keyLength = 256; // 256-bits for AES-256, 128-bits for AES-128, etc
byte[] salt; // Should be of saltLength

/* When first creating the key, obtain a salt with this: */
SecureRandom random = new SecureRandom();
byte[] salt = new byte[saltLength];
random.nextBytes(salt);

/* Use this to derive the key from the password: */
KeySpec keySpec = new PBEKeySpec(password.toCharArray(), salt,
iterationCount, keyLength);
SecretKeyFactory keyFactory = SecretKeyFactory
.getInstance("PBKDF2WithHmacSHA1");
byte[] keyBytes = keyFactory.generateSecret(keySpec).getEncoded();
SecretKey key = new SecretKeySpec(keyBytes, "AES");



That's it. You should not need anything else.



To make transitioning data easier, we covered the case of developers that have
data encrypted with an insecure key, which is derived from a password every
time. You can use the helper class InsecureSHA1PRNGKeyDerivator in
the example app
to derive the key.



 private static SecretKey deriveKeyInsecurely(String password, int
keySizeInBytes) {
byte[] passwordBytes = password.getBytes(StandardCharsets.US_ASCII);
return new SecretKeySpec(
InsecureSHA1PRNGKeyDerivator.deriveInsecureKey(
passwordBytes, keySizeInBytes),
"AES");
}


You can then re-encrypt your data with a securely derived key as explained
above, and live a happy life ever after.



Note 1: as a temporary measure to keep apps working, we decided to still create
the instance for apps targeting SDK version 23, the SDK version for Marshmallow,
or less. Please don't rely on the presence of the Crypto provider in the Android
SDK, our plan is to delete it completely in the future.



Note 2: Because many parts of the system assume the existence of a SHA1PRNG
algorithm, when an instance of SHA1PRNG is requested and the provider is not
specified we return an instance of OpenSSLRandom, which is a strong source of
random numbers derived from OpenSSL.




Thursday, June 9, 2016

Notifications in Android N

Posted by Ian Lake, Developer Advocate

Android notifications are often a make-or-break interaction between your Android app and users. To provide a better user experience, notifications on Android N have received a visual refresh, improved support for custom views, and expanded functionality in the forms of Direct Reply, a new MessagingStyle, and bundled notifications.

Same notification, new look

The first and most obvious change is that the default look and feel of notifications has significantly changed. Many of the fields that were spread around the notifications have been collapsed into a new header row with your app’s icon and name anchoring the notification. This change ensured that the title, text, and large icon are given the most amount of space possible and, as a result, notifications are generally slightly larger now and easier to read.



Given the single header row, it is more important than ever that the information there is useful. When you target Android N, by default the time will be hidden - if you have a time critical notification such as a messaging app, you can re-enable it with setShowWhen(true). In addition, the subtext now supersedes the role of content info and number: number is never shown on Android N devices and only if you target a previous version of Android and don’t include a subtext will content info appear. In all cases, ensure that the subtext is relevant and useful - don’t add an account email address as your subtext if the user only has one account, for example.

Notification actions have also received a redesign and are now in a visually separate bar below the notification.



You’ll note that the icons are not present in the new notifications; instead more room is provided for the labels themselves in the constrained space of the notification shade. However, the notification action icons are still required and continue to be used on older versions of Android and on devices such as Android Wear.

If you’ve been building your notification with href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.Builder.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">NotificationCompat.Builder and the standard styles available to you there, you’ll get the new look and feel by default with no code changes required.

Better Support for Custom Views

If you’re instead building your notification from custom RemoteViews, adapting to any new style has been challenging. With the new header, expanding behavior, actions, and large icon positioning as separate elements from the main text+title of the notification, we’ve introduced a new DecoratedCustomViewStyle and DecoratedMediaCustomViewStyle to provide all of these elements, allowing you to focus only on the content portion with the new setCustomContentView() method.



This also ensures that future look and feel changes should be significantly easier to adapt to as these styles will be updated alongside the platform with no code changes needed on the app side.

Direct Reply

While notification actions have already been able to launch an Activity or do background work with a Service or BroadcastReceiver, Direct Reply allows you to build an action that directly receives text input inline with the notification actions.



Direct Reply uses the same href="https://developer.android.com/reference/android/support/v4/app/RemoteInput.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">RemoteInput API - originally introduced for Android Wear - to mark an href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.Action.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">Action as being able to directly receive input from the user.

The RemoteInput itself contains information like the key which will be used to later retrieve the input and the hint text which is displayed before the user starts typing.

// Where should direct replies be put in the intent bundle (can be any string)
private static final String KEY_TEXT_REPLY = "key_text_reply";

// Create the RemoteInput specifying this key
String replyLabel = getString(R.string.reply_label);
RemoteInput remoteInput = new RemoteInput.Builder(KEY_TEXT_REPLY)
.setLabel(replyLabel)
.build();


Once you’ve constructed the RemoteInput, it can be attached to your Action via the aptly named href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.Action.Builder.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog#addRemoteInput(android.support.v4.app.RemoteInput)">addRemoteInput() method. You might consider also calling setAllowGeneratedReplies(true) to enable href="https://developer.android.com/wear/preview/index.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">Android Wear 2.0 to generate href="https://developer.android.com/wear/preview/api-overview.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog#smart-replies">Smart Reply choices when available and make it easier for users to quickly respond.

// Add to your action, enabling Direct Reply for it
NotificationCompat.Action action =
new NotificationCompat.Action.Builder(R.drawable.reply, replyLabel, pendingIntent)
.addRemoteInput(remoteInput)
.setAllowGeneratedReplies(true)
.build();


Keep in mind that the pendingIntent being passed into your Action should be an Activity on Marshmallow and lower devices that don’t support Direct Reply (as you’ll want to dismiss the lock screen, start an Activity, and focus the input field to have the user type their reply) and should be a Service (if you need to do work on a separate thread) or BroadcastReceiver (which runs on the UI thread) on Android N devices so as the process the text input in the background even from the lock screen. (There is a separate user control to enable/disable Direct Reply from a locked device in the system settings.)

Extracting the text input in your Service/BroadcastReceiver is then possible with the help of the href="https://developer.android.com/reference/android/support/v4/app/RemoteInput.html#getResultsFromIntent(android.content.Intent)">RemoteInput.getResultsFromIntent() method:

private CharSequence getMessageText(Intent intent) {
Bundle remoteInput = RemoteInput.getResultsFromIntent(intent);
if (remoteInput != null) {
return remoteInput.getCharSequence(KEY_TEXT_REPLY);
}
return null;
}


After you’ve processed the text, you must update the notification. This is the trigger which hides the Direct Reply UI and should be used as a technique to confirm to the user that their reply was received and processed correctly.

For most templates, this should involve using the new setRemoteInputHistory() method which appends the reply to the bottom of the notification. Additional replies should be appended to the history until the main content is updated (such as the other person replying).



However, if you’re building a messaging app and expect back and forth conversations, you should use MessagingStyle and append the additional message to it.

MessagingStyle

We’ve optimized the experience for displaying an ongoing conversation and using Direct Reply with the new MessagingStyle.



This style provides built-in formatting for multiple messages added via the addMessage() method. Each message supports passing in the text itself, a timestamp, and the sender of the message (making it easy to support group conversations).

builder.setStyle(new NotificationCompat.MessagingStyle("Me")
.setConversationTitle("Team lunch")
.addMessage("Hi", timestampMillis1, null) // Pass in null for user.
.addMessage("What's up?", timestampMillis2, "Coworker")
.addMessage("Not much", timestampMillis3, null)
.addMessage("How about lunch?", timestampMillis4, "Coworker"));


You’ll note that this style has first-class support for specifically denoting messages from the user and filling in their name (in this case with “Me”) and setting an optional conversation title. While this can be done manually with a BigTextStyle, by using this style Android Wear 2.0 users will get immediate inline responses without kicking them out of the expanded notification view, making for a seamless experience without needing to build a full Wear app.

Bundled Notifications

Once you’ve built a great notification by using the new visual designs, Direct Reply, MessagingStyle, and href="https://www.youtube.com/watch?v=-iog_fmm6mE">all of our previous best practices, it is important to think about the overall notification experience, particularly if you post multiple notifications (say, one per ongoing conversation or per new email thread).



Bundled notifications offer the best of both worlds: a single summary notification for when users are looking at other notifications or want to act on all notifications simultaneously and the ability to expand the group to act on individual notifications (including using actions and Direct Reply).

If you’ve built href="https://developer.android.com/training/wearables/notifications/stacks.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">stacking notifications for Android Wear, the API used here is exactly the same. Simply add href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.Builder.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog#setGroup(java.lang.String)">setGroup() to each individual notification to bundle those notifications together. You’re not limited to one group, so bundle notifications appropriately. For an email app, you might consider one bundle per account for instance.

It is important to also create a summary notification. This summary notification, denoted by href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.Builder.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog#setGroupSummary(boolean)">setGroupSummary(true), is the only notification that appears on Marshmallow and lower devices and should (you guessed it) summarize all of the individual notifications. This is an opportune time to use the href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.InboxStyle.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">InboxStyle, although using it is not a requirement. On Android N and higher devices, some information (such as the subtext, content intent, and delete intent) is extracted from the summary notification to produce the collapsed notification for the bundled notifications so you should continue to generate a summary notification on all API levels.

To improve the overall user experience on Android N devices, posting 4 or more notifications without a group will cause those notifications to be automatically bundled.

N is for Notifications

Notifications on Android have been a constant area of progressive enhancement. From the single tap targets of the Gingerbread era to expandable notifications, actions, MediaStyle, and now features such as Direct Reply and bundled notifications, notifications play an important part of the overall user experience on Android.

With many new tools to use (and href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">NotificationCompat to help with backward compatibility), I’m excited to see how you use them to #BuildBetterApps

Follow the href="https://plus.google.com/collection/sLR0p?utm_campaign=android_series_design_multiwindow_blog_051116&utm_source=anddev&utm_medium=blog">Android Development Patterns Collection for more!