Thursday, June 30, 2016

Building for Billions

Posted by Sam Dutton, Ankur Kotwal, Developer Advocates; Liz Yepsen, Program Manager






�TOP-UP WARNING.� �NO CONNECTION.� �INSUFFICIENT BANDWIDTH TO PLAY THIS
RESOURCE.�



These are common warnings for many smartphone users around the world.



To build products that work for billions of users, developers must address key
challenges: limited or intermittent connectivity, device compatibility, varying
screen sizes, high data costs, short-lived batteries. We first presented href="https://developers.google.com/billions/?utm_campaign=android_discussion_billions_063016&utm_source=anddev&utm_medium=blog">developers.google.com/billions
and related Android and Web resources at Google I/O last month, and today you
can watch the video presentations about href="https://www.youtube.com/watch?v=vaEV8bNi1Dw">Android or the href="https://www.youtube.com/watch?v=E6hGubMkNfM">Web.



These best practices can help developers reach billions by delivering
exceptional performance across a range of connections, data plans, and devices.
g.co/dev/billions will
help you:



Seamlessly transition between slow, intermediate, and offline
environments



Your users move from place to place, from speedy wireless to patchy or expensive
data. Manage these transitions by storing data, queueing requests, optimizing
image handling, and performing core functions entirely offline.



Provide the right content for the right context



Keep context in mind - how and where do your users consume your content?
Selecting text and media that works well across different viewport sizes,
keeping text short (for scrolling on the go), providing a simple UI that doesn�t
distract from content, and removing redundant content can all increase
perception of your app�s quality while giving real performance gains
like reduced data transfer. Once these practices are in place, localization
options can grow audience reach and increase engagement.



Optimize for mobile hardware



Ensure your app or Web content is served and runs well for your widest possible
addressable market, covering all actively used OS versions, while still
following best practices, by testing on virtual or actual devices in target
markets. Native Android apps should set minimum and target SDKs. Also, remember
low cost phones have smaller amounts of RAM; apps should therefore adjust usage
accordingly and minimize background running. For in-depth information on
minimizing APK size, check out this href="https://medium.com/@wkalicinski/smallerapk-part-8-native-libraries-open-from-apk-fc22713861ff">series
of Medium posts. On the Web, optimize JavaScript CPU usage, avoid raster
image rendering, and minimize resource requests. Find out more href="https://developers.google.com/web/fundamentals/performance/?utm_campaign=android_discussion_billions_063016&utm_source=anddev&utm_medium=blog">here.



Reduce battery consumption



Low cost phones usually have shorter battery life. Users are sensitive to
battery consumption levels and excessive consumption can lead to a high
uninstall rate or avoidance of your site. Benchmark your battery usage against
sessions on other pages or apps, or using tools such as Battery Historian, and
avoid long-running processes which drain batteries.



Conserve data usage



Whatever you�re building, conserve data usage in three simple steps: understand
loading requirements, reduce the amount of data required for interaction, and
streamline navigation so users get what they want quickly. Conserving data on
behalf of your users (and with native apps, offering configurable network usage)
helps retain data-sensitive users -- especially those on prepaid plans or
contracts with limited data -- as even �unlimited� plans can become expensive
when roaming or if unexpected fees are applied.



Have another insight, or a success launching in low-connectivity conditions or
on low-cost devices? Let us know on our href="https://plus.sandbox.google.com/+GoogleDevelopers/posts/WffV23WSrc8">G+
post.

Wednesday, June 29, 2016

New video tips to help news publishers find success on Google Play

Posted by Tamzin Taylor - Strategic Partner Lead, Google Play






Today we have released a three-part video series �Tips for
your news app on Google Play�
, where you can find actionable tips
and learn best practices for developing, launching and monetising a high quality
news app. The video series accompanies the recently published href="https://play.google.com/store/books/details/Google_Inc_The_News_Publisher_Playbook_for_Android?id=O7T3CwAAQBAJ">News
Publisher Playbook.


href="https://www.youtube.com/playlist?list=PLWz5rJ2EKKc_ElGrEtiEXc83m1SeYu3-Q">Watch
the video series to learn:


  • 10 tips on how to design and develop your News app
  • 10 tips to help you launch your News app and start gaining readers
  • 10 tips to engage your readers and monetize your News app




You can also href="https://play.google.com/store/books/details/Google_Inc_The_News_Publisher_Playbook_for_Android?id=O7T3CwAAQBAJ&hl=en_GB">get
the News Publisher Playbook on the Play Store to help you develop a
successful news mobile strategy on Android. It includes tips on mobile website
optimization, how to create a Google Play Newsstand edition, how to improve your
native app, and more.


Give us your feedback


Once you�ve checked out the video series, we�d love to hear your feedback so we
can continue to help you find success with and achieve your business objectives.
Leave a comment or a thumbs up, and href="https://www.youtube.com/channel/UCVHFbqXqoYvEWM1Ddxl0QDg?sub_confirmation=1">subscribe
to the Android Developers YouTube channel!


Also, href="https://www.youtube.com/playlist?list=PLWz5rJ2EKKc_ElGrEtiEXc83m1SeYu3-Q">check
out our other videos in in the Tips for Success on Google Play series,
including the recent video on href="https://www.youtube.com/watch?v=PfwHq8w9GBc&list=PLWz5rJ2EKKc_ElGrEtiEXc83m1SeYu3-Q&index=11">10
tips to build an app for billions of users.


For more best practices to find success on Google Play, href="http://g.co/play/playbook-androiddevblogposts-evergreen">get the new
Playbook for Developers app.



Monday, June 27, 2016

Android changes for NDK developers

Posted by Dmitry Malykhanov, Developer Advocate




Related to other improvements to the Android platform, the dynamic linker in
Android M and N has stricter requirements for writing clean, cross-platform
compatible native code in order to load. It is necessary that an application�s
native code follows the rules and recommendations in order to ensure a smooth
transition to recent Android releases.



Below we outline in detail each individual change related to native code
loading, the consequences and steps you can take to avoid issues.



Required tools: there is an <arch>-linux-android-readelf binary (e.g.
arm-linux-androideabi-readelf or i686-linux-android-readelf) for each
architecture in the NDK (under toolchains/), but you can use readelf for any
architecture, as we will be doing basic inspection only. On Linux you need to
have the �binutils� package installed for readelf, and �pax-utils� for scanelf.


Private API (Enforced since API 24)



Native libraries must use only href="http://developer.android.com/ndk/guides/stable_apis.html?utm_campaign=android_discussion_ndkchanges_062716&utm_source=anddev&utm_medium=blog">public API,
and must not link against non-NDK platform libraries. Starting with API 24 this
rule is enforced and applications are no longer able to load non-NDK platform
libraries. The rule is enforced by the dynamic linker, so non-public libraries
are not accessible regardless of the way code tries to load them:
System.loadLibrary(...), DT_NEEDED entries, and direct calls to dlopen(...) will
fail in exactly the same way.



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.



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). In order to
give you more time to transition, we will temporarily support these libraries;
so if you see a warning that means your code will not work in a future release
-- please fix it now!



$ readelf --dynamic libBroken.so | grep NEEDED
0x00000001 (NEEDED) Shared library: [libnativehelper.so]
0x00000001 (NEEDED) Shared library: [libutils.so]
0x00000001 (NEEDED) Shared library: [libstagefright_foundation.so]
0x00000001 (NEEDED) Shared library: [libmedia_jni.so]
0x00000001 (NEEDED) Shared library: [liblog.so]
0x00000001 (NEEDED) Shared library: [libdl.so]
0x00000001 (NEEDED) Shared library: [libz.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so]
0x00000001 (NEEDED) Shared library: [libm.so]
0x00000001 (NEEDED) Shared library: [libc.so]


Potential problems: starting from API 24 the dynamic linker will not load
private libraries, preventing the application from loading.



Resolution: rewrite your native code to rely only on public API. As a short term
workaround, platform libraries without complex dependencies (libcutils.so) can
be copied to the project. As a long term solution the relevant code must be
copied to the project tree. SSL/Media/JNI internal/binder APIs should not be
accessed from the native code. When necessary, native code should call
appropriate public Java API methods.



A complete list of public libraries is available within the NDK, under
platforms/android-API/usr/lib.


Note: SSL/crypto is a special case, applications must NOT use platform libcrypto
and libssl libraries directly, even on older platforms. All applications should
use href="http://developer.android.com/training/articles/security-gms-provider.html?utm_campaign=android_discussion_ndkchanges_062716&utm_source=anddev&utm_medium=blog">GMS
Security Provider to ensure they are protected from known vulnerabilities.


Missing Section Headers (Enforced since API 24)



Each ELF file has additional information contained in the section headers. These
headers must be present now, because the dynamic linker uses them for sanity
checking. Some developers try to strip them in an attempt to obfuscate the
binary and prevent reverse engineering. (This doesn�t really help because it is
possible to reconstruct the stripped information using widely-available tools.)



$ readelf --header libBroken.so | grep 'section headers'
Start of section headers: 0 (bytes into file)
Size of section headers: 0 (bytes)
Number of section headers: 0
$


Resolution: remove the extra steps from your build that strip section headers.


Text Relocations (Enforced since API 23)



Starting with API 23, shared objects must not contain text relocations. That is,
the code must be loaded as is and must not be modified. Such an approach reduces
load time and improves security.



The usual reason for text relocations is non-position independent hand-written
assembler. This is not common. Use the href="https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide#Finding_broken_object_code">scanelf
tool as described in href="http://developer.android.com/about/versions/marshmallow/android-6.0-changes.html?utm_campaign=android_discussion_ndkchanges_062716&utm_source=anddev&utm_medium=blog#behavior-runtime">our
documentation for further diagnostics:



$ scanelf -qT libTextRel.so
libTextRel.so: (memory/data?) [0x15E0E2] in (optimized out: previous simd_broken_op1) [0x15E0E0]
libTextRel.so: (memory/data?) [0x15E3B2] in (optimized out: previous simd_broken_op2) [0x15E3B0]
[skipped the rest]


If you have no scanelf tool available, it is possible to do a basic check with
readelf instead, look for either a TEXTREL entry or the TEXTREL flag. Either
alone is sufficient. (The value corresponding to the TEXTREL entry is irrelevant
and typically 0 --- simply the presence of the TEXTREL entry declares that the
.so contains text relocations). This example has both indicators present:



$ readelf --dynamic libTextRel.so | grep TEXTREL
0x00000016 (TEXTREL) 0x0
0x0000001e (FLAGS) SYMBOLIC TEXTREL BIND_NOW
$


Note: it is technically possible to have a shared object with the TEXTREL
entry/flag but without any actual text relocations. This doesn�t happen with the
NDK, but if you�re generating ELF files yourself make sure you�re not generating
ELF files that claim to have text relocations, because the Android dynamic
linker trusts the entry/flag.



Potential problems: Relocations enforce code pages being writable, and
wastefully increase the number of dirty pages in memory. The dynamic linker has
issued warnings about text relocations since Android K (API 19), but on API 23
and above it refuses to load code with text relocations.



Resolution: rewrite assembler to be position independent to ensure no text
relocations are necessary. Check the href="https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide">Gentoo
documentation for cookbook recipes.


Invalid DT_NEEDED Entries (Enforced since API 23)



While library dependencies (DT_NEEDED entries in the ELF headers) can be
absolute paths, that doesn�t make sense on Android because you have no control
over where your library will be installed by the system. A DT_NEEDED entry
should be the same as the needed library�s SONAME, leaving the business of
finding the library at runtime to the dynamic linker.



Before API 23, Android�s dynamic linker ignored the full path, and used only the
basename (the part after the last �/�) when looking up the required libraries.
Since API 23 the runtime linker will honor the DT_NEEDED exactly and so it won�t
be able to load the library if it is not present in that exact location on the
device.



Even worse, some build systems have bugs that cause them to insert DT_NEEDED
entries that point to a file on the build host, something that
cannot be found on the device.



$ readelf --dynamic libSample.so | grep NEEDED
0x00000001 (NEEDED) Shared library: [libm.so]
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000001 (NEEDED) Shared library: [libdl.so]
0x00000001 (NEEDED) Shared library:
[C:\Users\build\Android\ci\jni\libBroken.so]
$


Potential problems: before API 23 the DT_NEEDED entry�s basename was used, but
starting from API 23 the Android runtime will try to load the library using the path
specified, and that path won�t exist on the device. There are broken third-party
toolchains/build systems that use a path on a build host instead of the SONAME.



Resolution: make sure all required libraries are referenced by SONAME only. It
is better to let the runtime linker to find and load those libraries as the
location may change from device to device.


Missing SONAME (Used since API 23)



Each ELF shared object (�native library�) must have a SONAME (Shared Object
Name) attribute. The NDK toolchain adds this attribute by default, so its
absence indicates either a misconfigured alternative toolchain or a
misconfiguration in your build system. A missing SONAME may lead to runtime
issues such as the wrong library being loaded: the filename is used instead when
this attribute is missing.



$ readelf --dynamic libWithSoName.so | grep SONAME
0x0000000e (SONAME) Library soname: [libWithSoName.so]
$


Potential problems: namespace conflicts may lead to the wrong library being
loaded at runtime, which leads to crashes when required symbols are not found,
or you try to use an ABI-incompatible library that isn�t the library you were
expecting.



Resolution: the current NDK generates the correct SONAME by default. Ensure
you�re using the current NDK and that you haven�t configured your build system
to generate incorrect SONAME entries (using the -soname linker
option).



Please remember, clean, cross-platform code built with a current NDK should have
no issues on Android N. We encourage you to revise your native code build so
that it produces correct binaries.

Android Mobile Vision restores operation and adds Text API

Posted by Michael Sipe, Product Manager






As an important framework for finding objects in photos and video, Mobile Vision
operation for Android devices is restored in Google Play Services v9.2.



This new version of Google Play Services fixes a download issue in Google Play
Services v.9.0 that caused a service outage. See href="https://developers.google.com/vision/release-notes">release notes for
details.



We�re also pleased to announce the Text API, a new component for Android Mobile
Vision.



The Text API�s optical character recognition technology reads Latin character
text (e.g. English, Spanish, German, French, etc.) in photos and returns the
text as well as the organizational structure (paragraphs, lines, words). Mobile
apps can now:


  • Organize photos that contain text
  • Automate tedious data entry for credit cards, receipts, and business cards
  • Translate documents (along with the href="https://cloud.google.com/translate/">Cloud Translate API)
  • Keep track of real objects, such as reading the numbers on subway trains
  • Provide accessibility features


If you want to get started quickly, you can try our href="http://g.co/codelabs/mobile-vision-ocr">codelab which will get Android
developers reading text with their apps in under an hour.



Like the Mobile Vision Face and Barcode components, the Text API runs on-device
and is suitable for real-time applications. For more information, check out the
Mobile Vision Developer
site
.

Create Intelligent, Context-Aware Apps with the Google Awareness APIs


Posted by Bhavik Singh, Product Manager



Last month at Google I/O 2016 we announced the new Google Awareness APIs,
enabling your apps to intelligently react to user context using snapshots and
fences with minimal impact on system resources.



Today we�re proud to announce that the Google Awareness API is available to all
developers through Google Play services.






Using 7 different types of context�including location, weather, user activity,
and nearby beacons�your app can better understand your users� current
situations, and use this information to provide optimized and customized
experiences.



The Awareness API offers two ways to take advantage of context signals within
your app:


  • The Snapshot API lets your app easily request information
    about the user's current context. For example, "give me the user's current
    location and the current weather conditions".
  • The Fence API lets your app react to changes in user�s
    context - and when it matches a certain set of conditions. For example, "tell me
    whenever the user is walking and their headphones are plugged in". Similar to
    the Geofencing API, once an awareness fence is registered, it can send callbacks
    to your app even when it's not running.


As a single, simplified surface, the Awareness APIs combine optimally processed
context signals in new ways that were not previously possible, providing more
accurate and insightful context cues, while also managing system resources to
save battery and minimize bandwidth.



We�ve worked closely with some of our partners, who have already found amazing
ways to integrate context awareness into their apps:






href="https://play.google.com/store/apps/details?id=com.trulia.android&hl=en">Trulia,
an online residential real estate site, uses our Fence API to suggest
open houses. When the weather is perfect and the user is walking around near a
house they are interested in, Trulia sends a notification reminding them to stop
by. This sort of tailored notification can help users engage with open houses at
the perfect time for them.




href="https://play.google.com/store/apps/details?id=fm.superplayer.jukebot&hl=en">SuperPlayer
Music, on the other hand, uses our Snapshot API and Fence API to suggest the
perfect music to match your mood. Whether you�re just finishing up a run and
beginning to stretch, setting off on a long car ride, or just getting to the
gym, their assistant can understand your context and suggest the right playlist
for you.



With our initial set of signals and our awesome partners, we�re just getting
started with the Awareness APIs. Join us on a journey to build tailored
experiences within your apps, by getting started with the href="https://developers.google.com/awareness/?utm_campaign=android_launch_awarenessapi_062716&utm_source=anddev&utm_medium=blog">Google Awareness API developer
documentation, and learn more by watching our Google I/O session





Wednesday, June 22, 2016

Introducing the Android Basics Nanodegree

Posted by Shanea King-Roberson, Lead Program Manager Twitter: @shaneakr Instagram: @theshanea







Do you have an idea for an app but you don�t know where to start? There are over
1 billion Android devices worldwide, providing a way for you to deliver your
ideas to the right people at the right time. Google, in partnership with
Udacity, is making Android development accessible and understandable to
everyone, so that regardless of your background, you can learn to build apps
that improve the lives of people around you.



Enroll in the new Android Basics
Nanodegree
. This series of courses and services teaches you how to build
simple Android apps--even if you have little or no programming experience. Take
a look at some of the apps built by our students:



The app "ROP Tutorial" built by student Arpy Vanyan raises awareness of a
potentially blinding eye disorder called Retinopathy of Prematurity that can
affect newborn babies.











And user Charles Tommo created an app called �Dr Malaria� that teaches people
ways to prevent malaria.











With courses designed by Google, you can
learn skills that are applicable to building apps that solve real world
problems. You can learn at your own pace to use href="http://developer.android.com/tools/studio/index.html">Android Studio
(Google�s official tool for Android app development) to design app user
interfaces and implement user interactions using the Java programming language.



The courses walk you through
step-by-step on how to build an order form for a coffee shop, an app to track
pets in a shelter, an app that teaches vocabulary words from the Native American
Miwok tribe, and an app on recent earthquakes in the world. At the end of the
course, you will have an entire portfolio of apps to share with your friends and
family.



Upon completing the Android Basics Nanodegree, you also have the opportunity to
continue your learning with the Career-track Android Nanodegree (for
intermediate developers). The first 50 participants to finish the Android Basics
Nanodegree have a chance to win a scholarship for the Career-track Android
Nanodegree. Please visit href="http://udacity.com/legal/scholarship">udacity.com/legal/scholarship
for additional details and eligibility requirements. You now have a complete
learning path to help you become a technology entrepreneur or most importantly,
build very cool Android apps, for yourself, your communities, and even the
world.



All of the individual courses that make
up this Nanodegree are available online for no charge at href="http://udacity.com/google">udacity.com/google. In addition, Udacity
provides paid services, including access to coaches, guidance on your project,
help staying on track, career counseling, and a certificate upon completion for
a fee.



You will be exposed to introductory computer science concepts in the Java
programming language, as you learn the following skills.


  • Build app user interfaces
  • Implement user interactions
  • Store information in a database
  • Pull data from the internet into your app
  • Identify and fix unexpected behavior in the app
  • Localize your app to support other languages


To enroll in the Android Basics Nanodegree program, href="http://udacity.com/nd803">click here.



See you in class!


Tuesday, June 21, 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.

Grow your business on Google Play with help from the new Playbook for Developers app

Posted by Dom Elliott, the Google Play team








Today, the href="http://g.co/play/playbook-androiddevelopers-blog-launch">Playbook for
Developers
mobile app is now
generally available for Android devices. The app helps you stay up-to-date with
the features and best practices to grow your business on Google Play. Thanks to
all our beta testers over the last six weeks whose feedback helped us tweak and
refine the app in preparation for launch.


Here�s how you read and watch content in the Playbook for Developers app:


  • Choose topics relating to your business interests to personalize My
    Playbook
    with curated articles and videos from Google and experts
    across the web.
  • Explore the in-depth guide to Google�s developer
    products, with articles grouped by what you�re trying to do: develop, launch,
    engage, grow, and earn.
  • Take actions on items � complete, share, save, or dismiss them � and read
    your Saved articles later, including offline if they�re
    written in the app. A data connection will be needed to read articles and videos
    from across the web.






The app supports Android 5.0 and above. If you're on an older device, check out our ebook, The Secrets to App Success on Google Play. We will be adding and updating content
in the app to help you stay up-to-date and grow your business. href="http://g.co/play/playbook-androiddevelopers-blog-launch">Get the Playbook
for Developers app today and then href="mailto:playbookfeedback@google.com">give us your feedback. The app is
also available in the following languages: href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=id&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=id">Bahasa
Indonesia, href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=de&&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=de">Deutsch,
href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=es-419&&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=es-419">espa�ol
(Latinoam�rica), href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=fr&&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=fr">le
fran�ais, href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=pt-BR&&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=pr-BR">portugu�s
do Brasil, href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=vi&&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=vi">ti?ng
Vi?t, href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=ru&&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=ru">???????
???�?, href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=ko&&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=ko">???,
href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=zh-CN&&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=zh-CN">??
(??), href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=zh-TW&&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=zh-TW">??
(??), and href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&hl=ja&&utm_source=androiddevelopers&utm_medium=blog&utm_campaign=ja">???.



This is the second app we�ve released for Google Play developers. Get the href="http://g.co/play/consoleapp">Google Play Developer Console app to
review your app's performance statistics and financial data, get notified about
your app's status and publishing changes, and read and reply to user reviews on
the go.


Thursday, June 16, 2016

One Year of Android Security Rewards





A year ago, we added Android Security Rewards to the long standing Google Vulnerability Rewards Program. We offered up to $38,000 per report that we used to fix vulnerabilities and protect Android users.



Since then, we have received over 250 qualifying vulnerability reports from researchers that have helped make Android and mobile security stronger. More than a third of them were reported in Media Server which has been hardened in Android N to make it more resistant to vulnerabilities.



While the program is focused on Nexus devices and has a primary goal of improving Android security, more than a quarter of the issues were reported in code that is developed and used outside of the Android Open Source Project. Fixing these kernel and device driver bugs helps improve security of the broader mobile industry (and even some non-mobile platforms).



By the Numbers



Here�s a quick rundown of the Android VRP�s first year:




  • We paid over $550,000 to 82 individuals. That�s an average of $2,200 per reward and $6,700 per researcher.

  • We paid our top researcher, @heisecode, $75,750 for 26 vulnerability reports.

  • We paid 15 researchers $10,000 or more.

  • There were no payouts for the top reward for a complete remote exploit chain leading to TrustZone or Verified Boot compromise.



Thank you to those who submitted high quality vulnerability reports to us last year.




Improvements to Android VRP





We�re constantly working to improve the program and today we�re making a few changes to all vulnerability reports filed after June 1, 2016.





We�re paying more!



  • We will now pay 33% more for a high-quality vulnerability report with proof of concept. For example, the reward for a Critical vulnerability report with a proof of concept increased from $3000 to $4000.

  • A high quality vulnerability report with a proof of concept, a CTS Test, or a patch will receive an additional 50% more.

  • We�re raising our rewards for a remote or proximal kernel exploit from $20,000 to $30,000.

  • A remote exploit chain or exploits leading to TrustZone or Verified Boot compromise increase from $30,000 to $50,000.



All of the changes, as well as the additional terms of the program, are explained in more detail in our Program Rules. If you�re interested in helping us find security vulnerabilities, take a look at Bug Hunter University and learn how to submit high quality vulnerability reports. Remember, the better the report, the more you�ll get paid. We also recently updated our severity ratings, so make sure to check those out, too.





Thank you to everyone who helped us make Android safer. Together, we made a huge investment in security research that has made Android stronger. We�re just getting started and are looking forward to doing even more in the future.

Wednesday, June 15, 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!















Android Developer Story: Sendy uses Google Play features to build for the next billion users

Posted by Lily Sheringham, Google Play team



href="https://play.google.com/store/apps/details?id=com.sendy.co.ke.sendyy&hl=en&e=-EnableAppDetailsPageRedesign">Sendy
is a door to door on-demand couriering platform founded in Nairobi, Kenya. It
connects customers and logistics providers, providing two unique apps, one for
the driver and one for the customer. Watch CEO & Co-founder, Meshack Alloys, and
Android Developer, Jason Rogena, explain how they use Developer Console
features, such as alpha and beta testing, as well as other tips and best
practices, to build for the next billion users.






href="https://play.google.com/store/books/details/Google_Inc_The_Building_for_Billions_Playbook_for?id=cJEjDAAAQBAJ&e=-EnableAppDetailsPageRedesign">Learn
more about building for billions and get more tips to grow your games
business by href="https://play.google.com/apps/testing/com.google.android.apps.secrets">opting-in
to the Playbook app beta and href="https://play.google.com/store/apps/details?id=com.google.android.apps.secrets&e=-EnableAppDetailsPageRedesign">download
the Playbook app in the Google Play Store.

Thursday, June 9, 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.




Wednesday, June 8, 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 href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.MessagingStyle.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">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 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#setShowWhen(boolean)">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 href="https://developer.android.com/reference/android/app/Notification.DecoratedCustomViewStyle.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">DecoratedCustomViewStyle and href="https://developer.android.com/reference/android/app/Notification.DecoratedMediaCustomViewStyle.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">DecoratedMediaCustomViewStyle to provide all of these elements, allowing you to focus only on the content portion with the new href="https://developer.android.com/reference/android/app/Notification.Builder.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog#setCustomContentView(android.widget.RemoteViews)">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 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#setAllowGeneratedReplies(boolean)">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 by calling href="https://developer.android.com/reference/android/app/NotificationManager.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog#notify(int,%20android.app.Notification)">notify() with the same id and tag (if used). 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 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#setRemoteInputHistory(java.lang.CharSequence[])">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 href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.MessagingStyle.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">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 href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.MessagingStyle.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">MessagingStyle.



This style provides built-in formatting for multiple messages added via the href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.MessagingStyle.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog#addMessage(java.lang.CharSequence, long, java.lang.CharSequence)">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, href="https://developer.android.com/reference/android/support/v4/app/NotificationCompat.MessagingStyle.html?utm_campaign=android_series_notificationsandroidnblog_060816&utm_source=anddev&utm_medium=blog">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!

Wednesday, June 1, 2016

Android Developer Story: Vietnamese games developer Divmob finds more users with localized pricing on Google Play

Posted by Lily Sheringham, Google Play team




Based in Ho Chi Minh City in Vietnam, games developer Divmob has grown quickly from an original team of five people to 40 employees since
it was founded three years ago. Divmob now has over 40 million downloads across
its various titles, including the popular game, Epic Heroes War.



Watch Ngo Van Luyen, CEO & Founder at Divmob, and his team explain how
introducing sub-dollar pricing in various markets resulted in a 300% increase
in daily transactions, and increased the number of paying users threefold.






Find out more about local pricing models on Google Play



We recently introduced new features in the Google Play Developer Console to
help you meet local expectations when setting prices, to make purchases more
attractive to your users. The Developer Console will now automatically round
pricing to local conventions in each market, and you can also set up pricing
templates to manage pricing across multiple currencies more efficiently, and
easily make bulk changes to the prices of multiple apps and in-app products in
a single click. Learn more about the improved local pricing tools.