Sep 19

Notifying your users with FCM


Posted by Jingyu Shi, Developer Advocate, Partner Devrel

This is the second in a series of blog posts in which outline strategies and guidance in Android with regard to power.

Notifications are a powerful channel you can use to keep your app’s users connected and updated. Android provides Notification APIs to create and post notifications on the device, but quite often these notifications are triggered by external events and sent to your app from your app server.

In this blog post, we’ll explain when and how to generate these remote notifications to provide timely updates to users and minimize battery drain.

Use FCM for remote notifications

We recommend using Firebase Cloud Messaging (FCM) to send remote notifications to Android devices. FCM is a free, cross-platform messaging solution that reliably delivers hundreds of billions of messages per day. It is primarily used to send remote notifications and to notify client applications that data is available to sync. If you still use Google Cloud Messaging (GCM) or the C2DM library , both of which are deprecated, it’s time to upgrade to FCM!

There are two types of FCM messages you can choose from:

  • Notification Messages, which simplify notification handling and are high priority by default.
  • Data Messages, for when you want to handle the FCM messages within the client app.

You can set the priority to either high or normal on the data messages. You can find out more about FCM messages and message handling in this blog post on Firebase Blog.

FCM is optimized to work with Android power management features. Using the appropriate message priority and type helps you reach your users in a timely manner, and also helps save their battery. Learn more about power management features in this blog post: “Moar Power in P and the future”.

To notify or not?

All of the notifications that you send should be well-structured and actionable, as well as provide timely and relevant information to your users. We recommend that you follow these notification guidelines, and avoid spamming your users. No one wants to be distracted by irrelevant or poorly-structured notifications. If your app behaves like this, your users may block the notifications or even uninstall your app.

The When not to use a notification section of the Material Design documentation for notifications highlights cases where you should not send your user a notification. For example, a common use case for a normal priority FCM Data Message is to tell the app when there’s content ready for sync, which requires no user interaction. The sync should happen quietly in the background, with no need for a notification, and you can use the WorkManager1 or JobScheduler API to schedule the sync.

Post a notification first

If you are sending remote notifications, you should always post the notification as soon as possible upon receiving the FCM message. Adding any additional network requests before posting a notification will lead to delayed notifications for some of your users. When not handled properly, the notifications might not be seen at all, see the “avoid background service” section below.


⚠️ Avoid adding any additional network requests before posting a notification

Also keep in mind that, depending on the state of the device, user actions, and app behavior, one or many power saving features could be restricting your app’s background work. As a result, your app’s jobs and alarms might be delayed, and its ability to access the network might be restricted.

For all of these reasons, to ensure timely delivery of the notification, you should always show the notification promptly when the FCM message is received, before any other work like network fetch or scheduling jobs.

FCM message payload is your friend

To post a notification upon the receipt of an FCM message, you should include all the data needed for the notification in the FCM message payload.

The same applies to data sync–we recommend that your app send as much data as possible in the FCM payload and, if needed, load the remainder of the data when the app opens. On a well-performing network, there’s a good chance that the data will be synced by the time the user opens the app so the spinner won’t be shown to the user. If network connectivity is not good, a notification will be sent to the user with the content in the FCM payload to inform the user in a timely manner. The user can then open the app to load all the data.

You can also encrypt FCM messages end-to-end using libraries like Capillary. The image below shows a general flow of how to handle FCM messages.

Need more data?

As convenient as FCM message payload is, it comes with a 4KB maximum limit. If you need to send a rich notification with an image attachment, or you want to improve your user experience by keeping your app in sync with media content, you may need more than the 4KB payload limit. For this, we recommend using FCM messages in combination with the WorkManager 1 or JobScheduler API.

If you need to post a rich notification, we recommend posting the notification first, with some of the content in the FCM message. Then schedule a job to fetch the remainder of the content. Once the job is finished, update the notification if it is still active. For example, you can include a thumbnail or preview of the content in the FCM payload and post it in the notification first. Then schedule a job to fetch the rest of the media files. Be aware that if you’ve scheduled jobs from the FCM message handler, it is possible that when the user launches the app, the scheduled job won’t have finished yet. You should handle this case gracefully.

In short, use the data in the FCM message payload to post a notification and keep your app content updated first. If you still need more data, then schedule jobs with APIs like WorkManager 1 or JobScheduler API.

Avoid background services

One common pitfall is using a background service to fetch data in the FCM message handler, since background service will be stopped by the system per recent changes to Google Play Policy (Starting late 2018, Google Play will require a minimum target API level ).

Android 9 Pie will also impose background execution limits when battery saver is on. Starting a background service will lead to IllegalStateException from a normal priority FCM message. High priority messages do grant you a short whitelist window that allows you to start a background service. However, starting a background service with a network call will put the service at risk of getting terminated by the system, because the short execution window is only intended to be used for posting a notification.

You should avoid using background services but use WorkManager 1 or JobScheduler API instead to perform operations in the background.

Power & message priority

Android 6 Marshmallow introduced Doze. FCM is optimized to work with Doze, and you can use high priority FCM messages to notify your users immediately. In Doze mode, normal priority messages are deferred to a maintenance window. This enables the system to save battery when a device is idle, but still ensure users receive time-critical notifications. Consider an instant messaging app that sends users messages from friends or incoming phone calls or a home monitoring app sends users alarm notifications. These are some of the acceptable examples where you can use high priority FCM messages.

In addition, Android 9 Pie introduced App Standby Buckets and App Restrictions.

The table below shows how various power-management features affect message delivery behaviors.

High priority message delivery Normal priority message delivery
App in Foreground Immediate, unless app is restricted (see below) Immediate, unless app is restricted (see below)
App in Background
Device in Doze (M+) and Doze “on the go” (N+) Immediate Deferred until maintenance window
App Standby Buckets (P+) May be restricted No restriction
App Restrictions (P+) All messages dropped (see below) All messages dropped (see below)
Battery Saver No restriction No restriction


★ Note: Starting January 2019, App Restrictions (in Battery Setting) will include restrictions on FCM messages. You can find out if your app is in the restricted state with the isBackgroundRestricted API. Once your app is in the restricted state, no FCM messages will be delivered to the app at all. This will apply to both high and normal priority FCM messages and when app is in either foreground or background.

App Standby Buckets impose different levels of restrictions based on the app’s standby bucket. Based on which bucket your app belongs to, there might be a cap for the number of high priority messages you are allowed to send per day. Once you reach the cap, any subsequent high priority messages will be downgraded to normal priority. See more details in the power management restrictions.

High priority FCM messages are designed to send remote notifications or trigger actions that involve user interactions. As long as you always use high priority messages for these purposes, your high priority messages will be delivered immediately and remote notifications will be displayed without delay. In addition, when a notification from a high priority message causes a user to open your app, the app gets promoted to the active bucket, which exempts it from FCM caps. The example below shows an instant messaging app moving to the active bucket after the user taps on a notification triggered by a high priority FCM message.

However, if you use high priority messages to send notifications to the blocked notification channels or tasks which do not involve user interactions, you will run the risk of wasting the high priority messages allocated in your app’s bucket. Once reaching the cap, you won’t be able to send urgent notifications anymore.

In summary, you should only use high priority FCM messages to deliver immediate, time-critical notifications to users. Doing so will ensure these messages and subsequent high priority messages reach your users without getting downgraded. You should use normal priority messages to trigger events that do not require immediate execution, such as a notification that is not time-sensitive or a data sync in the background.

Test with Android 9!

We highly recommend that you test your apps under all of the power management features mentioned above. To learn more about handling FCM messages on Android in your code, visit the Firebase blog.

Thank you for helping move the ecosystem forward, making better Android apps, and saving users’ batteries!

Acknowledgements: This blog posts is in joint collaboration with FCM and Android teams.

1 WorkManager is the recommended solution for background processing once it’s stable.


Android Developers Blog

Sep 17

Material design in the 2014 Google I/O app

By Roman Nurik, lead designer for the Google I/O Android App

Every year for Google I/O, we publish an Android app for the conference that serves two purposes. First, it serves as a companion for conference attendees and those tuning in from home, with a personalized schedule, a browsing interface for talks, and more. Second, and arguably more importantly, it serves as a reference demo for Android design and development best practices.

Last week, we announced that the Google I/O 2014 app source code is now available, so you can go check out how we implemented some of the features and design details you got to play with during the conference. In this post, I’ll share a glimpse into some of our design thinking for this year’s app.


On the design front, this year’s I/O app uses the new material design approach and features of the Android L Developer Preview to present content in a rational, consistent, adaptive and beautiful way. Let’s take a look at some of the design decisions and outcomes that informed the design of the app.

Surfaces and shadows

In material design, surfaces and shadows play an important role in conveying the structure of your app. The material design spec outlines a set of layout principles that helps guide decisions like when and where shadows should appear. As an example, here are some of the iterations we went through for the schedule screen:

First iteration

Second iteration

Third iteration


The first iteration was problematic for a number of reasons. First, the single shadow below the app bar conveyed that there were two “sheets” of paper: one for the app bar and another for the tabs and screen contents. The bottom sheet was too complex: the “ink” that represents the contents of a sheet should be pretty simple; here ink was doing too much work, and the result was visual noise. An alternative could be to make the tabs a third sheet, sitting between the app bar and content, but too much layering can also be distracting.


The second and third iterations were stronger, creating a clear separation between chrome and content, and letting the ink focus on painting text, icons, and accent strips.

Another area where the concept of “surfaces” played a role was in our details page. In our first release, as you scroll the details screen, the top banner fades from the session image to the session color, and the photo scrolls at half the speed beneath the session title, producing a parallax effect. Our concern was that this design bent the physics of material design too far. It’s as if the text was sliding along a piece of paper whose transparency changed throughout the animation.


A better approach, which we introduced in the app update on June 25th, was to introduce a new, shorter surface on which the title text was printed. This surface has a consistent color and opacity. Before scrolling, it’s adjacent to the sheet containing the body text, forming a seam. As you scroll, this surface (and the floating action button attached to it) rises above the body text sheet, allowing the body text to scroll beneath it.


This aligns much better with the physics in the world of material design, and the end result is a more coherent visual, interaction and motion story for users. (See the code: Fragment, Layout XML)

Color

A key principle of material design is also that interfaces should be “bold, graphic, intentional” and that the foundational elements of print-based design should guide visual treatments. Let’s take a look at two such elements: color and margins.


In material design, UI element color palettes generally consist of one primary and one accent color. Large color fields (like the app bar background) take on the main 500 shade of the primary color, while smaller areas like the status bar use a darker shade, e.g. 700.

The accent color is used more subtly throughout the app, to call attention to key elements. The resulting juxtaposition of a tamer primary color and a brighter accent, gives apps a bold, colorful look without overwhelming the app’s actual content.

In the I/O app, we chose two accents, used in various situations. Most accents were Pink 500, while the more conservative Light Blue 500 was a better fit for the Add to Schedule button, which was often adjacent to session colors. (See the code: XML color definitions, Theme XML)


And speaking of session colors, we color each session’s detail screen based on the session’s primary topic. We used the base material design color palette with minor tweaks to ensure consistent brightness and optimal contrast with the floating action button and session images.


Below is an excerpt from our final session color palette exploration file.

Session colors, with floating action button juxtaposed to evaluate contrast

Desaturated session colors, to evaluate brightness consistency across the palette

Margins

Another important “traditional print design” element that we thought about was margins, and more specifically keylines. While we’d already been accustomed to using a 4dp grid for vertical sizing (buttons and simple list items were 48dp, the standard action bar was 56dp, etc.), guidance on keylines was new in material design. Particularly, aligning titles and other textual items to keyline 2 (72dp on phones and 80dp on tablets) immediately instilled a clean, print-like rhythm to our screens, and allowed for very fast scanning of information on a screen. Gestalt principles, for the win!


Grids

Another key principle in material design is “one adaptive design”:

A single underlying design system organizes interactions and space. Each device reflects a different view of the same underlying system. Each view is tailored to the size and interaction appropriate for that device. Colors, iconography, hierarchy, and spatial relationships remain constant.

Now, many of the screens in the I/O app represent collections of sessions. For presenting collections, material design offers a number of containers: cards, lists, and grids. We originally thought to use cards to represent session items, but since we’re mostly showing homogenous content, we deemed cards inappropriate for our use case. The shadows and rounded edges of the cards would add too much visual clutter, and wouldn’t aid in visually grouping content. An adaptive grid was a better choice here; we could vary the number of columns on screen size (see the code), and we were free to integrate text and images in places where we needed to conserve space.


Delightful details

Two of the little details we spent a lot of time perfecting in the app, especially with the L Developer Preview, were touch ripples and the Add to Schedule floating action button.

We used both the clipped and unclipped ripple styles throughout the app, and made sure to customize the ripple color to ensure the ripples were visible (but still subtle) regardless of the background. (See the code: Light ripples, Dark ripples)

But one of our favorite details in the app is the floating action button that toggles whether a session shows up in your personalized schedule or not:

We used a number of new API methods in the L preview (along with a fallback implementation) to ensure this felt right:


  1. View.setOutline and setClipToOutline for circle-clipping and dynamic shadow rendering.
  2. android:stateListAnimator to lift the button toward your finger on press (increase the drop shadow)
  3. RippleDrawable for ink touch feedback on press
  4. ViewAnimationUtils.createCircularReveal for the blue/white background state reveal
  5. AnimatedStateListDrawable to define the frame animations for changes to icon states (from checked to unchecked)

The end result is a delightful and whimsical UI element that we’re really proud of, and hope that you can draw inspiration from or simply drop into your own apps.

What’s next?

And speaking of dropping code into your own apps, remember that all the source behind the app, including L Developer Preview features and fallback code paths, is now available, so go check it out to see how we implemented these designs.

We hope this post has given you some ideas for how you can use material design to build beautiful Android apps that make the most of the platform. Stay tuned for more posts related to this year’s I/O app open source release over the coming weeks to get even more great ideas for ways to deliver the best experience to your users.

Join the discussion on
+Google Design


Android Developers Blog

Sep 13

Hungry for some Big Android BBQ?

Posted by Colt McAnlis, Head Performance Wrangler

The Big Android BBQ (BABBQ) is almost here and Google Developers will be there serving up a healthy portion of best practices for Android development and performance! BABBQ will be held at the Hurst Convention Center in Dallas/Ft.Worth, Texas on October 22-23, 2015.

We also have some great news! If you sign up for the event through August 25th, you will get 25% off when you use the promotional code “ANDROIDDEV25″. You can also click here to use the discount.

Now, sit back, and enjoy this video of some Android cowfolk preparing for this year’s BBQ!

The Big Android BBQ is an Android combo meal with a healthy serving of everything ranging from the basics, to advanced technical dives, and best practices for developers smothered in a sweet sauce of a close knit community.

This year, we are packing in an unhealthy amount of Android Performance Patterns, followed up with the latest and greatest techniques and APIs from the Android 6.0 Marshmallow release. It’s all rounded out with code labs to let you get hands-on learning. To super-size your meal, Android Developer instructors from Udacity will be on-site to guide users through the Android Nanodegree. (Kinda like a personal-waiter at an all-you-can-learn buffet).

Also, come watch Colt McAnlis defend his BABBQ “Speechless” Crown against Silicon Valley reigning champ Chet Haase. It’ll be a fist fight of humor in the heart of Texas!

You can get your tickets here, and we look forward to seeing you in October!

Join the discussion on

+Android Developers


Android Developers Blog

Sep 12

Moar Power in Android 9 Pie and the future


Posted by Madan Ankapura, Product Manager, Android

This is the first in a series of blog posts that outline strategies and guidance in Android with regard to power.

Your users care a lot about battery — if it runs out too quickly, it means they can’t use your apps. Being a good steward of battery power is an important part of your relationship with the user, and we’re continuing to add features to the platform that can help you accomplish this.

As part of our announced Play policy about improving app security and performance, an app’s target API level must be no more than one year older than the current Android release. Keeping the target API level current will ensure that apps can take advantage of security and performance enhancements offered in the latest platform releases. When you update your app’s target API level, it’s important that you evaluate your background and foreground needs, which could have a significant impact on power & performance.

Past releases of Android included a number of features that helped manage battery life better, like:

  • Job Scheduler in Android 5.0 Lollipop, which allows deferring work
  • Doze and App Standby in Android 6.0 Marshmallow, which disables network access and suspends syncs and background work – when device or apps are unused for a prolonged period.
  • Doze improvements in Android 7.0 Nougat, which applies a subset of Doze restrictions when the screen is off and not stationary.
  • Background limits in Android 8.0 Oreo, which prevent background services and throttle location updates.

In Android 9 Pie, we made further improvements based on these three principles:

  1. Developers want to build cool apps
  2. Apps need to be power-efficient
  3. Users don’t want to be bothered to configure app settings

This means that the OS needs to be smarter and adapt to user preferences while improving the battery life of the device. To address these needs, we have introduced App Standby Buckets, Background Restrictions, and improved Battery Saver. Please test your app with these features enabled on a device running Android 9 Pie.

Battery Saver and Doze operate on a device-wide level, while Adaptive Battery (app standby buckets powered by a Deepmind ML model) and background restrictions operate on a per-app basis. The diagram below helps understand when a scheduled work will run.

As you update your apps to target Oreo or above, please review this checklist and follow the below table for background work

Currently Using Porting to Oreo
JobScheduler JobScheduler
Firebase JobDispatcher Firebase JobDispatcher
Background Service Jobscheduler
Foreground Service Foreground Service with action to STOP service

Note: when the WorkManager API becomes stable, we will be recommending WorkManager for most of these use cases

We recommend the following strategy given the importance for app developers to invest in the right design patterns and architecture:

  1. Do the needed work when the user is actively using the app
  2. Make any work/task that is done in the background deferrable
  3. Use foreground services but provide an action in the notification so user can stop the foreground service

Similarly, other OS primitives like alarms, network, and FCM messages also have constraints that are described in the developer documentation on power-management restrictions. You can learn more about each of these features via Google I/O presentation, DevByte and additional power optimization developer documentation.

We will be publishing a series of design pattern guidances in the upcoming weeks. Stay tuned.

Acknowledgements: This series of blog posts is in joint collaboration with Android Framework and DevRel teams.


Android Developers Blog

Sep 09

Interactive watch faces with the latest Android Wear update

Posted by Wayne Piekarski, Developer Advocate

The Android Wear team is rolling out a new update that includes support for interactive watch faces. Now, you can detect taps on the watch face to provide information quickly, without having to open an app. This gives you new opportunities to make your watch face more engaging and interesting. For example, in this animation for the Pujie Black watch face, you can see that just touching the calendar indicator quickly changes the watch face to show the agenda for the day, making the watch face more helpful and engaging.

Interactive watch face API

The first step in building an interactive watch face is to update your build.gradle to use version 1.3.0 of the Wearable Support library. Then, you enable interactive watch faces in your watch face style using setAcceptsTapEvents(true):

setWatchFaceStyle(new WatchFaceStyle.Builder(mService)
    .setAcceptsTapEvents(true)
    // other style customizations
    .build());

To receive taps, you can override the following method:

@Override
public void onTapCommand(int tapType, int x, int y, long eventTime) { }

You will receive events TAP_TYPE_TOUCH when the user initially taps on the screen, TAP_TYPE_TAP when the user releases their finger, and TAP_TYPE_TOUCH_CANCEL if the user moves their finger while touching the screen. The events will contain (x,y) coordinates of where the touch event occurred. You should note that other interactions such as swipes and long presses are reserved for use by the Android Wear system user interface.

And that’s it! Adding interaction to your existing watch faces is really easy with just a few extra lines of code. We have updated the WatchFace sample to show a complete implementation, and design and development documentation describing the API in detail.

Wi-Fi added to LG G Watch R

This release also brings Wi-Fi support to the LG G Watch R. Wi-Fi support is already available in many Android Wear watches and allows the watch to communicate with the companion phone without requiring a direct Bluetooth connection. So, you can leave your phone at home, and as long as you have Wi-Fi, you can use your watch to receive notifications, send messages, make notes, or ask Google a question. As a developer, you should ensure that you use the Data API to abstract away your communications, so that your application will work on any kind of Android Wear watch, even those without Wi-Fi.

Updates to existing watches

This update to Android Wear will roll out via an over-the-air (OTA) update to all Android Wear watches over the coming weeks. The wearable support library version 1.3 provides the implementation for touch interactions, and is designed to continue working on devices which have not been updated. However, the touch support will only work on updated devices, so you should wait to update your apps on Google Play until the OTA rollout is complete, which we’ll announce on the Android Wear Developers Google+ community. If you want to release immediately but check if touch interactions are available, you can use this code snippet:

PackageInfo packageInfo = PackageManager.getPackageInfo("com.google.android.wearable.app", 0);
if (packageInfo.versionCode > 720000000) {
  // Supports taps - cache this result to avoid calling PackageManager again
} else {
  // Device does not support taps yet
}


Android Wear developers have created thousands of amazing apps for the platform and we can’t wait to see the interactive watch faces you build. If you’re looking for a little inspiration, or just a cool new watch face, check out the Interactive Watch Faces collection on Google Play.

Join the discussion on

+Android Developers


Android Developers Blog

Sep 08

Introducing the ExifInterface Support Library

With the release of the 25.1.0 Support Library, there’s a new entry in the family: the ExifInterface Support Library. With significant improvements introduced in Android 7.1 to the framework’s ExifInterface, it only made sense to make those available to all API 9+ devices via the Support Library’s ExifInterface.

The basics are still the same: the ability to read and write Exif tags embedded within image files: now with 140 different attributes (almost 100 of them new to Android 7.1/this Support Library!) including information about the camera itself, the camera settings, orientation, and GPS coordinates.

Camera Apps: Writing Exif Attributes

For Camera apps, the writing is probably the most important – writing attributes is still limited to JPEG image files. Now, normally you wouldn’t need to use this during the actual camera capturing itself – you’d instead be calling the Camera2 API CaptureRequest.Builder.set() with JPEG_ORIENTATION, JPEG_GPS_LOCATION or the equivalents in the Camera1 Camera.Parameters. However, using ExifInterface allows you to make changes to the file after the fact (say, removing the location information on the user’s request).

Reading Exif Attributes

For the rest of us though, reading those attributes is going to be our bread-and-butter; this is where we see the biggest improvements.

Firstly, you can read Exif data from JPEG and raw images (specifically, DNG, CR2, NEF, NRW, ARW, RW2, ORF, PEF, SRW and RAF files). Under the hood, this was a major restructuring, removing all native dependencies and building an extensive test suite to ensure that everything actually works.

For apps that receive images from other apps with a content:// URI (such as those sent by apps that target API 24 or higher), ExifInterface now works directly off of an InputStream; this allows you to easily extract Exif information directly out of content:// URIs you receive without having to create a temporary file.

Uri uri; // the URI you've received from the other app
InputStream in;
try {
  in = getContentResolver().openInputStream(uri);
  ExifInterface exifInterface = new ExifInterface(in);
  // Now you can extract any Exif tag you want
  // Assuming the image is a JPEG or supported raw format
} catch (IOException e) {
  // Handle any errors
} finally {
  if (in != null) {
    try {
      in.close();
    } catch (IOException ignored) {}
  }
}

Note: ExifInterface will not work with remote InputStreams, such as those returned from a HttpURLConnection. It is strongly recommended to only use them with content:// or file:// URIs.

For most attributes, you’d simply use the getAttributeInt(), getAttributeDouble(), or getAttribute() (for Strings) methods as appropriate.

One of the most important attributes when it comes to displaying images is the image orientation, stored in the aptly-named TAG_ORIENTATION, which returns one of the ORIENTATION_ constants. To convert this to a rotation angle, you can post-process the value.

int rotation = 0;
int orientation = exifInterface.getAttributeInt(
    ExifInterface.TAG_ORIENTATION,
    ExifInterface.ORIENTATION_NORMAL);
switch (orientation) {
  case ExifInterface.ORIENTATION_ROTATE_90:
    rotation = 90;
    break;
  case ExifInterface.ORIENTATION_ROTATE_180:
    rotation = 180;
    break;
  case ExifInterface.ORIENTATION_ROTATE_270:
    rotation = 270;
    break;
}

There are some helper methods to extract values from specific Exif tags. For location data, the getLatLong() method gives you the latitude and longitude as floats and getAltitude() will give you the altitude in meters. Some images also embed a small thumbnail. You can check for its existence with hasThumbnail() and then extract the byte[] representation of the thumbnail with getThumbnail() – perfect to pass to BitmapFactory.decodeByteArray().

Working with Exif: Everything is optional

One thing that is important to understand with Exif data is that there are no required tags: each and every tag is optional – some services even specifically strip Exif data. Therefore throughout your code, you should always handle cases where there is no Exif data, either due to no data for a specific attribute or an image format that doesn’t support Exif data at all (say, the ubiquitous PNGs or WebP images).

Add the ExifInterface Support Library to your project with the following dependency:

compile "com.android.support:exifinterface:25.1.0"

But when an Exif attribute is exactly what you need to prevent a mis-rotated image in your app, the ExifInterface Support Library is just what you need to #BuildBetterApps


Android Developers Blog

Sep 06

Get the guide to finding success in new markets on Google Play

Posted by Lily Sheringham, Developer Marketing at Google Play

With just a few clicks, you can publish an app to Google Play and access a
global audience of more than 1 billion 30 days active users. Finding success in
global markets means considering how each market differs, planning for high
quality localization, and tailoring your activity to the local audience. The new
Going
Global Playbook provides best practices and tips, with advice from
developers who’ve successfully gone global.

This guide includes advice to help you plan your approach to going global,
prepare your app for new markets, take your app to market, and also include data
and insights for key countries and other useful resources.

This ebook joins others that we’ve recently published including The
Building for Billions Playbook and The
News Publisher Playbook. All of our ebooks are promoted in the Playbook for Developers app, which is
where you can stay up to date with all the news and best practices you need to
find success on Google Play.


How useful did you find this blogpost?



Android Developers Blog

Sep 06

Start building Actions on Google

Posted by Jason Douglas, PM Director for Actions on Google

The Google Assistant brings
together all of the technology and smarts we’ve been building for years,
from the Knowledge Graph to Natural Language Processing. To be a truly
successful Assistant, it should be able to connect users across the apps and
services in their lives. This makes enabling an ecosystem where developers can
bring diverse and unique services to users through the Google Assistant really
important.

In October, we previewed
Actions on Google, the developer platform for the Google Assistant. Actions on Google further
enhances the Assistant user experience by enabling you to bring your services to
the Assistant. Starting today, you can build Conversation Actions for Google
Home and request to
become an early access partner for upcoming platform features.

Conversation Actions for Google Home

Conversation Actions let you engage your users to deliver information, services,
and assistance. And the best part? It really is a conversation — users won’t
need to enable a skill or install an app, they can just ask to talk to your
action. For now, we’ve provided two developer samples of what’s possible, just
say “Ok Google, talk to Number Genie ” or try “Ok Google, talk to Eliza’ for the
classic 1960s AI exercise.

You can get started today by visiting the Actions on Google website for
developers. To help create a smooth, straightforward development experience, we
worked with a number of
development partners, including conversational interaction development tools
API.AI and Gupshup, analytics tools DashBot and VoiceLabs and consulting
companies such as Assist, Notify.IO, Witlingo and Spoken Layer. We also created
a collection of samples and voice user
interface (VUI) resources or you can
check out the integrations from our early access
partners as they roll out over the coming weeks.


Introduction to Conversation Actions by Wayne Piekarski

Coming soon: Actions for Pixel and Allo + Support for Purchases and
Bookings

Today is just the start, and we’re excited to see what you build for the Google
Assistant. We’ll continue to add more platform capabilities over time, including
the ability to make your integrations available across the various Assistant
surfaces like Pixel phones and Google Allo. We’ll also enable support for
purchases and bookings as well as deeper Assistant integrations across
verticals. Developers who are interested in creating actions using these
upcoming features should register for our early access
partner program and help shape the future of the platform.

Build, explore and let us know what you think about Actions on Google! And to say in the loop, be sure to sign up for our newsletter, join our Google+ community, and use the “actions-on-google” tag on StackOverflow.


Android Developers Blog

Sep 06

Staged releases allow you to bring new features to your users quickly, safely and regularly.


Posted by Peter Armitage, Software Engineer, Google Play

Releasing a new version of your app is an exciting moment when your team’s hard work finally gets into the hands of your users. However, releasing can also be challenging – you want to keep your existing users happy without introducing performance regressions or bugs. At Google I/O this year, we talked about staged releases as an essential part of how Google does app releases, allowing you to manage the inherent risks of a new release by making a new version of your app available to just a fraction of your users. You can then increase this fraction as you gain confidence that your new version works as expected. We are excited that starting today staged releases will be possible on testing tracks, as well as the production track.

We will take a closer look at how staged releases work, and how you can use them as part of your release process.

Advantages of a staged release

The first benefit of a staged release is that it only exposes a fraction of your users to the new version. If the new version contains a bug, only a small number of people will be inconvenienced by it. This is much safer than releasing a new version to all of your users at once.

Another benefit is that if you discover a bug, you can halt the rollout, preventing any new users from downloading that version. Instead, they will receive the previous version.

These capabilities should relieve a lot of the uncertainty of rolling out a new version. And that will allow you to do it more often. We encourage releasing versions of a server more often because it reduces the changes between those versions, allowing you to more easily test and troubleshoot. The same principle applies to apps, though there will be a delay before most of your users upgrade to the latest version.

Staged releases as part of your normal release process

Let’s look at a typical release process for an app with 100,000 users.

  1. Every Monday the developer builds a new version of the app from the latest version of the code that passes the automatic tests. They push the new release to Google Play’s internal test track, and their QA team immediately starts testing it manually. Any bugs they find can be fixed and a new version can be built and pushed for them to re-check.
  2. On Tuesday, if the QA team have approved the latest release, it can be promoted to the app’s alpha track. All the employees at the company have opted in to testing. Once the new release is pushed to the alpha track, the employees can download the new version. They can do this manually, or they may have auto-updates enabled, in which case they will probably update within a few hours.
  3. On Wednesday, if there are no reported issues with the release, they can promote the release to the production track and start a rollout at 10%. This means 10,000 users will have the opportunity to upgrade. Some will upgrade immediately, others will wait. The 10% of users that receive the app first are randomly selected, and the users will be randomly chosen each week.
  4. On Thursday, the developer checks the Play Console to see their crash reports, Android vitals, and feedback. If these all look good they can increase the rollout to 100%. All users will be able to upgrade to the new version.
  5. On Friday, the developer doesn’t change anything, to ensure a stress-free weekend!

For big apps and small apps

Some apps are just starting out, and although there’s no QA team, it’s still worth testing the app on a few different devices before releasing it. Instead of having a track for employees, the developer has added their friends and family, who can contact them if they see an issue.

When an app gets larger and uses the open testing track, it may have 5,000 testers. These testers won’t give public feedback on the Play store, but will be able to give feedback to the developer directly. If this app has 1 million users, they may first release to 1%, before going to 10%, then 100%.

Once an app becomes very popular, it could have over 100,000 testers. In that case the developer is now able to do a staged release on their testing track.

How to bounce back from issues

Bugs happen, and if you discover a problem with your new version you may want to halt the release. This will stop users from getting the new version, either by upgrading or installing for the first time. However, those who have already got the new version will not downgrade.

If the issue was not in the app itself, but on a server that the app communicates with, it may be best to fix the issue in the server, then resume the release. Resuming it allows some fraction of your users to access the new version again. This is the same set of users that were able to download the release before it was halted.

If the issue was in the app, you will have to fix it and release a new version. Or alternatively, you may choose to rebuild the previous version with a higher version code. Then you can start a staged release to the same set of users that the previous release went to.

API support

Staged releases are supported in v3 of the Play Console API on all tracks. Mark a release as “inProgress” and set a fraction of the population to target. For instance, to start a staged release to 5%:

{
  "releases": [{
      "versionCodes": ["99"],
      "userFraction": 0.05,
      "status": "inProgress"
  }]
}

Alternatively, if you release using the UI, it will suggest a fraction.

What next?

We hope you find these features useful and take advantage of them for successful updates with Google Play. If you’re interested in some of the other great tools for distributing your apps, check out the I/O 2018 sessions, and learn more about test tracks and staged updates.

How useful did you find this blogpost?

★ ★ ★ ★ ★



Android Developers Blog

Sep 04

Important best practices to improve app engagement

Posted by Niko Schröer, Business Development, Google Play

Driving installs is important to growing a user base, but it’s not much use if
your app sits on users’ devices and is rarely opened. In a competitive app
landscape, it’s increasingly important to engage and retain users over the long
term to build a successful business. Users who are using your app more will have
a higher lifetime value and be more likely to share your app. Watch my Playtime
session below to hear about the tools and features other developers are using to
increase app engagement. You can also read the summary of my main tips below.

1. Build a high quality app to engage Android users

Building a high quality app is the foundation of a great user experience on
Android. The better your app’s user experience is, the more engaged your users
will be. Optimizing for material
design, for example, can significantly improve user engagement as well as
building for Android
Wear, Auto or TV where it
makes sense based on your value proposition.

To achieve high quality, we recommend you to check out the latest Android
features, tips, and best practices in our Playbook
for Developers.

The developer of the golf app, Hole19,
tailored their app’s user experience thoughtfully for Android Wear and, as a
result, saw a 40% increase in user engagement compared to non-Wear users. Watch a video about Hole19′s
success.

2. Make your users feel at home

Personalising your app experience to make users feel at home is a good way to
start a long lasting relationship. Onboarding new users is a crucial step in
this process. Onboarding should be fast and seamless and ask for minimal user
input – after all users want to start using your app as quickly as possible.
Furthermore, the onboarding should be a core part of the overall product
experience. Use images and wording that’s true to your brand and only ask for
user input when it’s actually needed, to reduce friction and avoid losing users.

Freeletics,
a fitness app, created an engaging user onboarding flow in which they tailored
imagery and text to male and female users respectively. They also moved the
registration process to a later stage in the funnel to reduce friction. The
improved onboarding flow increased user activity by 58% within the first 7 days.
They also implemented Google Smart
Lock to seamlessly sign-in returning users.

3. Optimize feature releases as a way to increase user
engagement

Introducing new features is essential to staying ahead of competition and
relevant to your users to ensure they keep coming back to your app. To make new
feature launches successful drivers for user engagement, follow these simple
steps:

  • Define a clear objective for each release to measure your impact, e.g.
    increase number of users who edit a photo by at least 10%.

  • Use
    beta testing to gather user feedback and iterate a feature before it’s
    rolled out to all of your users.

  • Enable
    the pre-launch report in the Play developer console to spot potential flaws
    and ensure technical stability in your alpha and beta apps.

  • Guide users to each new feature as if it is a light onboarding experience.
    Visually highlight what’s new and provide a short explanation why users should
    care.

  • Measure performance with analytics to see if the
    new feature drives engagement (that you’ve defined as your objective).

4. Use notifications wisely

Push notifications are a popular engagement tool and rightfully so. However,
there is a fine line between driving engagement and annoying users (who might
then uninstall your app). Follow these guidelines to ensure your notifications
are on the right side of the line:

  • Be relevant and only send messages that matter to the user in context. Be
    creative and true to your brand, speak your users language and use an authentic
    tone.

  • Make notifications actionable for your users and don’t forget to deep link
    to content where applicable to save your users time.

  • Remember that not all your users are equal so personalize your message to
    different user cohorts with Firebase
    Notifications.

  • Consider timeliness of your messages to get users the right notification at
    the right time and with the right frequency. For example, it might be better to
    send a notification about something interesting to read at a time when the user
    normally gets out their phone – like during their commute – instead of the
    middle of the day, when they might be busy and dismiss a new notification.

  • Finally, give users control over what notifications they receive so that
    they can opt-in and opt-out of the notifications they like and don’t like
    respectively. If users get annoyed about certain types of notifications and
    don’t have a way to disable them, they might uninstall your app.

The Norwegian news app Aftenposten
implemented a new onboarding flow that clarified which notifications were
available, allowing readers to manage their preferences. This reduced uninstalls
by 9.2.% over 60 days and led to a 28% decrease in the number of users muting
notifications completely. Read
more about Aftenposten’s success.

5. Reward your most engaged users

Last but not least, you should find ways to reward your most loyal users to
retain them over time and to make it desirable to less engaged users to engage
more. These rewards can come in many shapes and forms. Start by keeping it
simple and make sure the reward adds real value to the user and fits in your
app’s ecosystem. You can do this by:

  • Giving sneak peeks of new features by inviting them to a beta
    group.

  • Decorating user accounts with badges based on their behaviour.
  • Offer app exclusive discounts or promo
    codes that can only be redeemed in your app.

Generally, the more you can personalize the reward the better it will work.

Find success with ongoing experimentation

A great Android app gives developers a unique opportunity to create a lasting
relationship with users and build a sustainable business with happy customers.
Therefore optimising apps to engage and retain your users by following these 5
tips should be front and centre of your development goals and company strategy.
Find more tips and best practices by watching the sessions at this
year’s Playtime events.

How useful did you find this blogpost?




Android Developers Blog