Blog
News Feed FYI

Blocking Ads from Pages that Repeatedly Share False News

By Satwik Shukla, Product Manager & Tessa Lyons, Product Manager Over the past year we have taken several steps to reduce false news and hoaxes on Facebook. Currently, we do not allow advertisers to run ads that link to stories that have been marked false by third-party fact-checking organizations. Now we are taking an additional […]

Read More
android developers

How to improve app design for Wear 2.0

Posted by Steven Tepper, App Quality Consultant, Google Play

Wear
2.0 launched
back in February with added support for new hardware features
in addition to adopting new Material
Design themes
,
guidelines,
and a simpler vertical UI pattern. It also introduces a complications
API
, making it easier for apps to provide data to watch faces, and watch
faces to incorporate external data. The final big update was that, apps
targeting Wear 2.0 now have the ability to operate in a standalone
mode
, without needing a connection to a companion app on the phone.

There are a few design considerations in relation to navigation, notifications,
the complications API, and the standalone functionality to help you better
optimize for Wear 2.0 devices:

Navigation

  1. Use the WearableDrawerLayout navigation drawer for simple and infrequent
    navigation:
    Simple navigation includes tasks such as accessing app
    settings, switching users or logging out. You can implement
    this on Wear 2.0 to switch between different views or sections of the app via a
    swipe down from the top of the screen, or an action drawer can be set up for
    context-specific actions when swiping up from the bottom of the screen.
  2. Present a navigation drawer as a single-page drawer to enable users
    to navigate views quickly:
    A navigation drawer can be presented as
    either a multi-page or single-page drawer. The single-page layout is useful for
    when the user is expected to navigate quickly between 7 or less views of the
    app. Remember that if the app is using a single-page drawer, the iconography
    should be clear and understandable as there will not be any sort of text
    labeling in this layout. If there are more than 7 views to navigate to or the
    views are not easily represented by icons, you should instead use the multi-page
    drawer layout.

  3. Use multiple app launchers if your app has two or three discrete
    functions:
    For example, if your app supports
    both activity tracking—with various options, actions,
    and views—and historical analysis and management of tracked activities, you can
    use multiple app launchers to handle these tasks. Alternatively, if your app has
    a simple home screen, these features could be placed in line, at the bottom of
    the screen.
  4. Use peeking at the top of the action drawer to provide quick access
    to the primary action:
    If there is no primary action associated with
    the view, override the default behavior and force an overflow button to peek
    instead, exposing all actions at the bottom of a view, when tapped.

Ensure that for devices using Wear 2.0, your app takes advantage of these new UI
patterns to provide a consistent user experience. Check out more training
resources for Wear
Navigation and Actions
and the Material Design specifications for Navigation
and Action
Drawers.

Notifications

Wear 2.0 uses a simpler vertical navigation pattern, removing the horizontal
swiping gesture to present actions for a notification. Notification actions are
now presented as a single primary action (if applicable) at the bottom of a
notification. If there is no primary action, expanding the notification will
present options in a single, vertically scrollable view.

Notifications will work without needing many changes on both 1.x and 2.0
devices, but appear quite different:

When creating apps for Wear 2.0 devices, improve the user experience with
notifications by applying the following best practices:

  1. Support expandable notifications: Use BigTextStyle
    so that users can see more content on their watch.
  2. Use the collapsed view of the notification (if applicable):
    Add the primary action for your notification to the collapsed view of the
    notification using setContentIntent(), where appropriate.
  3. For messaging apps, use the MessagingStyle:
    Provide a rich chat app-like experience in the expanded notification using this
    style.
  4. Update user directions which are specific to Wear 1.0:
    Remove any text guiding users to act on a card by swiping horizontally
    (the Wear 1.x pattern).
  5. Enhancing notifications to use inline actions: This allows
    users to do things without needing tap to see the expanded notification details.
    Actions for messaging notifications can use several different input methods
    including Smart Reply presets, voice, and keyboard input. Take advantage of
    these features to provide added functionality and delight users.

To learn more about adding
wearable features to notifications
.

Complications

The complications API in Wear 2.0 makes it much easier for watch face developers
and third-party data providers to surface important information users want, at a
glance. Watch faces that support the API can be configured to use any of the
data providers that have been installed on the watch while maintaining complete
control over their appearance. Apps supporting the complication API allow the
app’s data to be accessible on any watch faces that support complications. These
complications can be displayed in a variety of forms (short text, icon, ranged
value, long text, small image, and large image) depending on what the data
provider has configured and how much space has been allocated on the watch face.

To ensure that complications fit the overall design of the watch face and
properly handle their data type, when adding complication support we recommend
watch face makers should:

  1. Use the TextRenderer
    class found in the Wear 2.0 SDK:
    This allows the text within
    complications to be adjusted to their bounds by shrinking the text, dynamically
    supporting line breaks or ellipsizing strings when they exceed the bounds of a
    text-based complication.
  2. Use the ComplicationDrawable
    class to set the background color, shape, border, and font options for the
    complications:
    This gives complete control of how the complication is
    rendered to the watch face.
  3. Design the watch face to provide a way for users to configure or
    adjust complications on the watch face through a settings menu:
    To
    learn how to construct these settings see the watch face sample
    on GitHub.
  4. Use the data provider test
    suite
    app to feed dummy data to the watch face complications:
    This
    will enable you to verify that all of the complications render properly and have
    fonts formatted for their bounds.
  5. As a complication data provider, expose relevant data by using the
    ComplicationProviderService:

    Simply define and configure what types of ComplicationData
    the app can provide for complications.

Standalone functionality on Wear devices

  1. Make sure your app is able to handle itself if there is no companion
    app installed when using the android.hardware.type.watch hardware feature
    flag
    : Using this feature enables your app to become searchable and
    installable directly on Wear devices without needing to install a companion
    phone app, so ensure your app can handle itself to avoid a confusing or broken
    user experience.
  2. Ensure your wearable app doesn’t rely on the phone app for
    sign-in/authentication or primary functionality
    : When requiring
    complicated input for authentication (for example, password entry) your wearable
    app can point to the companion phone, but should rely on web UI for
    account/password entry rather than an app.
  3. Where a companion app must be present on a phone to support your app
    in some other way, the app should use the CapabilityApi:

    This should be used to properly direct users to the Play Store listing on their
    companion device to install the missing app. Otherwise, the app should function
    on its own, using the Wear built-in Wi-Fi, GPS, or other connectivity functions.

  4. Include wording about any companion app requirements or briefly
    mention how your Wear app should function within the Play Store listing
    description
    : This will help set expectations and guide users to install
    the correct apps for the best possible experience.
  5. Incorporate the com.google.android.wearable.standalone
    flag in the manifest if your Wearable app can function without any phone
    companion interaction
    : This flag indicates that the wearable app can be
    installed and will fully function when not paired to an Android or iOS companion
    phone.

Though a lot was covered here, there are additional resources you can use to
ensure that your apps or games are optimized and use the latest patterns and
functionality on Wear. Be sure to review
the quality guidelines
and check out the developer training documentation to
learn more best practices for wearable app
development
and wearable
app design
in order to build quality apps for Wear.

How useful did you find this blogpost?







Read More
Apps

Gamescom, Hot Chips, Hackathon and inclusivity – Weekend Reading: Aug. 25 edition

This week was awash in news out of gamescom 2017, a European trade fair for digital gaming culture that took place in Cologne, Germany. If your head is spinning from all the announcements, take a deep breath and devote the next three minutes to watching this video, with everything you need to know out of…

The post Gamescom, Hot Chips, Hackathon and inclusivity – Weekend Reading: Aug. 25 edition appeared first on The Official Microsoft Blog.

Read More
Product News

Announcing New Ways to Enjoy Memories with Friends

We’ve added two new ways for people to relive meaningful memories and celebrate special moments on Facebook.

Read More
Android

Understanding the performance benefits of ConstraintLayout

Posted by Takeshi Hagikura, Developer Programs Engineer

Since announcing ConstraintLayout
at Google I/O last year, we’ve continued to improve the layout’s stability and
layout editor support. We’ve also added new features specific to
ConstraintLayout that help you build various type of layouts, such
as introducing
chains
and setting
size as a ratio
. In addition to these features, there is a notable
performance benefit by using ConstraintLayout. In this post, we’ll
walk through how you can benefit from these performance improvements.

How Android draws views?

To better understand the performance of ConstraintLayout, let’s
take a step back and see how Android draws views.

When a user brings an Android view into focus, the Android framework directs the
view to draw itself. This drawing process comprises 3 phases:

  1. Measure

    The system completes a top-down traversal of the view tree to determine how
    large each ViewGroup and View element should be. When a
    ViewGroup is measured, it also measures its children.

  2. Layout

    Another top-down traversal occurs, with each ViewGroup determining
    the positions of its children using the sizes determined in the measure phase.

  3. Draw

    The system performs yet another top-down traversal. For each object in the view
    tree, a Canvas object is created to send a list of drawing commands
    to the GPU. These commands include the ViewGroup and
    View objects’ sizes and positions, which the system determined
    during the previous 2 phases.

Figure 1. Example of how the measure phase traverses a view tree

Each phase within the drawing process requires a top-down traversal of the view
tree. Therefore, the more views you embed within each other (or nest) into the
view hierarchy, the more time and computation power it takes for the device to
draw the views. By keeping a flat hierarchy in your Android app layouts, you can
create a fast and responsive user interface for your app.

The expense of a traditional layout hierarchy

With that explanation in mind, let’s create a traditional layout hierarchy that
uses LinearLayout and RelativeLayout objects.

Figure 2. Example layout

Let’s say we want to build a layout like the image above. If you build it with
traditional layouts, the XML file contains an element hierarchy similar to the
following (for this example, we’ve omitted the attributes):

<RelativeLayout>
  <ImageView />
  <ImageView />
  <RelativeLayout>
    <TextView />
    <LinearLayout>
      <TextView />
      <RelativeLayout>
        <EditText />
      </RelativeLayout>
    </LinearLayout>
    <LinearLayout>
      <TextView />
      <RelativeLayout>
        <EditText />
      </RelativeLayout>
    </LinearLayout>
    <TextView />
  </RelativeLayout>
  <LinearLayout >
    <Button />
    <Button />
  </LinearLayout>
</RelativeLayout>

Although there’s usually room for improvement in this type of view hierarchy,
you’ll almost certainly still need to create a hierarchy with some nested views.

As discussed before, nested hierarchies can adversely affect performance. Let’s
take a look at how the nested views actually affect the UI performance using
Android Studio’s Systrace
tool. We called the measure and layout phases for each ViewGroup
(ConstraintLayout and RelativeLayout) programmatically
and triggered Systrace while the measure and layout calls are executing. The
following command generates an overview file that contains key events, such as
expensive measure/layout passes, that occur during a 20-second interval:

python $ANDROID_HOME/platform-tools/systrace/systrace.py --time=20 -o ~/trace.html gfx view res

For more details about how you can use Systrace, see the Analyzing UI
Performance with Systrace
guide.

Systrace automatically highlights the (numerous) performance problems with this
layout, as well as suggestions for fixing them. By clicking the “Alerts” tab,
you will find that drawing this view hierarchy requires 80 expensive passes
through the measure and layout phases!

Triggering that many expensive measure and layout phases is far from ideal; such
a large amount of drawing activity could result in skipped frames that users
notice. We can conclude that the layout has poor performance due to the nested
hierarchy as well as the characteristic of RelativeLayout, which
measures each of its children twice.

Figure 3. Looking at the alerts from Systrace for the
layout variant that uses RelativeLayout

You can check the entire code on how we performed these measurements in our GitHub
repository
.

The benefits of a ConstraintLayout object

If you create the same layout using ConstraintLayout, the XML file
contains an element hierarchy similar to the following (attributes again
omitted):

<android.support.constraint.ConstraintLayout>
  <ImageView />
  <ImageView />
  <TextView />
  <EditText />
  <TextView />
  <TextView />
  <EditText />
  <Button />
  <Button />
  <TextView />
</android.support.constraint.ConstraintLayout>

As this example shows, the layout now has a completely flat hierarchy. This is
because ConstraintLayout allows you to build complex layouts
without having to nest View and ViewGroup elements.

For example, let’s look at the TextView and EditText
in the middle of the layout:

When using a RelativeLayout, you need to create a new
ViewGroup to align the EditText vertically with the
TextView:
<LinearLayout
    android:id="@+id/camera_area"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="horizontal"
    android:layout_below="@id/title" >

    <TextView
        android:text="@string/camera"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_vertical"
        android:id="@+id/cameraLabel"
        android:labelFor="@+id/cameraType"
        android:layout_marginStart="16dp" />

    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content">

        <EditText
            android:id="@+id/cameraType"
            android:ems="10"
            android:inputType="textPersonName"
            android:text="@string/camera_value"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:layout_centerVertical="true"
            android:layout_marginTop="8dp"
            android:layout_marginStart="8dp"
            android:layout_marginEnd="8dp" />
    </RelativeLayout>
</LinearLayout>

By using ConstraintLayout instead, you can achieve the same effect
just by adding a constraint from the baseline of the TextView to
the baseline of the EditText without creating another
ViewGroup:

Figure 4. Constraint between EditText and TextView
<TextView
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      app:layout_constraintLeft_creator="1"
      app:layout_constraintBaseline_creator="1"
      app:layout_constraintLeft_toLeftOf="@+id/activity_main_done"
      app:layout_constraintBaseline_toBaselineOf="@+id/cameraType" />

When running the Systrace tool for the version of our layout that uses
ConstraintLayout, you see far fewer expensive measure/layout passes
during the same 20-second interval. This improvement in performance makes sense,
now that we’re keeping the view hierarchy flat!

Figure 5. Looking at the alerts from Systrace for the
layout variant that uses ConstraintLayout

On a related note, we built the ConstraintLayout variant of our
layout using just the layout
editor
instead of editing the XML by hand. To achieve the same visual effect
using RelativeLayout, we probably would have needed to edit the XML
by hand.

Measuring the performance difference

We analyzed how long every measure and layout pass took for two type of layouts,
ConstraintLayout and RelativeLayout, by using
OnFrameMetricsAvailableListener,
which was introduced in Android 7.0 (API level 24). This class allows you to
collect frame-by-frame timing information about your app’s UI
rendering.

By calling the following code, you can start recording per-frame UI actions:

window.addOnFrameMetricsAvailableListener(
        frameMetricsAvailableListener, frameMetricsHandler);

After timing information becomes available, the app triggers the
frameMetricsAvailableListener() callback. We are interested in the
measure/layout performance, so we call FrameMetrics.LAYOUT_MEASURE_DURATION
when retrieving the actual frame duration.

Window.OnFrameMetricsAvailableListener {
        _, frameMetrics, _ ->
        val frameMetricsCopy = FrameMetrics(frameMetrics);
        // Layout measure duration in nanoseconds
        val layoutMeasureDurationNs = 
                frameMetricsCopy.getMetric(FrameMetrics.LAYOUT_MEASURE_DURATION);

To learn more about the other types of duration information that
FrameMetrics can receive, see the FrameMetrics
API reference.

Measurement results: ConstraintLayout is faster

Our performance comparison shows that ConstraintLayout performs
about 40% better in the measure/layout phase than RelativeLayout:

Figure 6. Measure / Layout (unit: ms, average of 100
frames)

As these results show, ConstraintLayout is likely to be more
performant than traditional layouts. Moreover, ConstraintLayout has
other features that help you build complex and performant layouts, as discussed
in the benefits of a ConstraintLayout
object
section. For details, see the Build
a Responsive UI with ConstraintLayout
guide. We recommend that you use
ConstraintLayout when designing your app’s layouts. In almost all
cases when you would have previously need a deeply-nested layout,
ConstraintLayout should be your go-to layout for optimal
performance and ease of use.

Appendix: Measurement environment

All the measurements above were performed in the following environment.

Device Nexus 5X
Android Version 8.0
ConstraintLayout version 1.0.2

What’s next

Check out the developer
guide
, the API
reference documentation
, and the article
on Medium
to fully understand what ConstraintLayout can provide
for you. And once again, thank you to all who submitted feedback and issues over
the months since our alpha release of ConstraintLayout. We’re truly
grateful that we were able to release the production-ready 1.0
version
of ConstraintLayout earlier this year.
As we continue to improve ConstraintLayout, please continue to send
us feedback using the Android issue tracker.

Read More
News

Spotlight on Local News: Eclipse Edition

By Josh Mabry, Local News Partnerships and Amber Burgess, CrowdTangle If your News Feed was flooded with people talking about the eclipse this past week, you weren’t alone. 66 million people had 240 million interactions around the solar eclipse, making…

Read More
android developers

Start on Android and succeed on Google Play

Posted by Karolis Balciunas, VC & Startups Business Development, Google Play

Early Access was launched at Google I/O 2016 as a destination
on Google Play for beta app and game titles still in development, and to attract
early adopters willing to test those titles. The results speak for themselves.
The program has helped over 350 developers launch their titles and generated
over 40M beta installs for their apps and games during just the short window
before their public availability on the Play Store. More importantly, the
average rating for titles that have been through Early Access is 4.3☆ once in
production, putting them in a strong position to be favored in search and
discovery on Google Play.

Early Access also generates positive awareness for new titles. Alumni like Simple
Habit
and Digit
were chosen as finalists in the “Standout Startup” category at the Google
Play Awards
this year.
Omnidrone’s game Titan
Brawl
became the first game to reach 1M testers. Hear more about their
experience in the video below.

Early Access and our work with the venture capital community has taught us a lot
about successful startups. We know you seek rapid iteration towards
product-market fit and are thirsty for the same kind of powerful testing,
analytics, and user feedback that Google’s own product teams depend on to launch
successful products. When we know about your startup’s plans
well in advance of your launch date, we can impact your trajectory by supporting
you through this understood process of iterative improvement.

Start on Android

Earlier this year we launched Start
on Android
to identify the highest potential Android startups
earlier in their lifecycle and provide tools, perks, and guidance for those who
qualify. We’ve developed five components that have proven to be most impactful:

  1. Early Access participation enabling developers to recruit beta testers and
    respond to their feedback before it impacts an app’s rating on the Play Store.
  2. Pre-launch user interface and user experience reviews from the Play
    editorial team to help optimize onboarding experiences, material design
    implementation, business model execution, and user engagement.
  3. Access to Google perks like the Google Cloud Platform’s Spark Package which
    includes $20K in Google Cloud and Firebase credits, free 12 months of G Suite
    for up to 10 employees, and other financial incentives.
  4. Opportunities to participate in Google Play and other Google teams’ programs
    and special events including Google Cloud Platform,
    Google for Entrepreneurs,
    and Launchpad.
  5. Guidance in the form of videos and content on startup best practices
    available to all at StartonAndroid.com.

We are just getting started

We’ve already seen a lot of developer interest and received hundreds of public
applications and referrals from venture capitalists and other startup
influencers. Below are a few accepted startups:

  • Socratic
    – A Spark Capital backed company that allows students to solve math problems by
    snapping a photo with their camera and using computer vision to return relevant
    answers and related concepts and video.
  • Astro
    A Redpoint
    portfolio company that layers AI on top of your email to help intelligently
    manage your inbox.

  • Peanut
    – A Tinder-like app for connecting moms, funded by NEA and Felix Capital.
  • Gyroscope
    – A startup working on an “operating system for the human body”.
  • Empower – An exciting new money management
    app backed by Sequoia Capital, coming soon to Android.

We are incredibly proud of every developer we work with and grateful to our
friends within VC firms and the wider community who bring exciting new startups
to our attention.

Get in touch with us

If you would like to be part of Start on Android, complete the form at StartonAndroid.com. We’re looking for
developers who are planning to launch on Android soon, or have done so in the
past 6 months.

How useful did you find this blogpost?







Read More
android oreo

Making it safer to get apps on Android O

Posted by Edward Cunningham. Product Manager, Android Security

Eagle-eyed users of Android O will have noticed the absence of the ‘Allow
unknown sources’ setting, which has existed since the earliest days of Android
to facilitate the installation of apps from outside of Google Play and other
preloaded stores. In this post we’ll talk about the new Install unknown
apps
permission and the security benefits it brings for both Android
users and developers.

Earlier this year we introduced Google Play
Protect
– comprehensive security services that are always at work to protect
your device from harm. Google Play continues to be one of the safest places for
Android users to download their apps, with the majority of Potentially Harmful
Apps (PHAs) originating from third-party sources.

A common strategy employed by PHA authors is to deliver their apps via a hostile
downloader. For example, a gaming app might not contain malicious code but
instead might notify the user to install a PHA that masquerades as an important
security update. (You can read more about hostile downloaders in the Android
Security 2016 Year in Review
). Users who have enabled the installation of
apps from unknown sources leave themselves vulnerable to this deceptive
behavior.

Left (pre-Android O): The install screen for a PHA masquerading as a system
update.
Right (Android O): Before the PHA is installed, the user must first grant
permission to the app that triggered the install.

In Android O, the Install unknown apps permission makes it
safer to install apps from unknown sources. This permission is tied to the app
that prompts the install— just like other runtime permissions—and ensures that
the user grants permission to use the install source before it can prompt the
user to install an app. When used on a device running Android O and higher,
hostile downloaders cannot trick the user into installing an app without having
first been given the go-ahead.

This new permission provides users with transparency, control, and a streamlined
process to enable installs from trusted sources. The Settings app shows the list
of apps that the user has approved for installing unknown apps. Users can
revoke the permission for a particular app at any time.

At any time, users can review the apps that they’ve allowed for installing
unknown apps. To make the permission-granting process easier, app developers can
choose to direct users to their permission screen as part of the setup
flow.

Developer changes

To take advantage of this new behavior, developers of apps that require the
ability to download and install other apps via the Package Installer may need to
make some changes. If an app uses a targetSdkLevel of 26 or above
and prompts the user to install other apps, the manifest file needs to include
the REQUEST_INSTALL_PACKAGES
permission:

<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />

Apps that haven’t declared this permission cannot install other apps, a handy
security protection for apps that have no intention of doing so. You can choose
to pre-emptively direct your users to the Install unknown apps
permission screen using the ACTION_MANAGE_UNKNOWN_APP_SOURCES
Intent action. You can also query the state of this permission using the
PackageManager canRequestPackageInstalls()
API.

Remember that Play policies
still apply to apps distributed on Google Play if those apps can install and
update other apps. In the majority of cases, such behavior is inappropriate; you
should instead provide a deep
link
to the app’s listing on the Play Store.

Be sure to check out the updated publishing
guide
that provides more information about installing unknown apps, and stay
tuned for more posts on security hardening in Android O.

Read More
instant articles

Showing Publisher Logos in Trending and Search

By: Andrew Anker, Product Manager Today, we will begin introducing publisher logos next to articles in Trending and Search surfaces on Facebook, as part of our ongoing efforts to enhance people’s recognition of the sources of news distributed on our…

Read More
android 8.0

Introducing Android 8.0 Oreo

Posted By: Dave Burke, VP of Engineering

After more than a year of development and months of testing by developers and early adopters (thank you!), we’re now ready to officially launch Android 8.0 Oreo to the world. Android 8.0 brings a ton of great features such as picture-in-picture, autofill, integrated Instant Apps, Google Play Protect, faster boot time, and much more.

We’re pushing the sources to Android Open Source Project (AOSP) for everyone to access today. Pixel and Nexus 5X/6P builds have entered carrier testing and we expect to start rolling out in phases over the next several weeks, alongside Pixel C and Nexus Player. Android Beta users will receive the update to the final version today and images are available to download and flash manually. We’ve been working closely with our partners over the last many months, and by the end of this year, hardware makers like Essential, General Mobile, HMD Global Home of Nokia Phones, Huawei, HTC, Kyocera, LG, Motorola, OnePlus, Samsung, Sharp and Sony are scheduled to be launching or upgrading new devices to Android 8.0 Oreo.

What’s in Android Oreo?

In Android 8.0 Oreo we focused on creating fluid experiences that make Android even more powerful and easy to use, such as:

  • Picture-in-picture lets users manage two tasks simultaneously on any size screen, and it’s easy for apps to support it. (Shown at right)
  • Notification dots extend the reach of notifications and offer a new way to surface activity in your apps. Dots work with zero effort for most apps — we even extract the color of the dot from your icon.
  • Autofill framework simplifies how users set up a new device and synchronize their passwords. Apps using form data can optimize their apps for Autofill, and password manager apps can use the new APIs to make their services available to users in their favorite apps. Autofill will roll out fully over the next few weeks as part of an update to Google Play Services.

We also invested in Android Vitals, a project focused on optimizing battery life, startup time, graphics rendering, and stability, while giving developers better visibility over the health of their apps:

  • System optimizations: We worked across the system to help apps run faster and smoother — for example, in the runtime we added a new concurrent compacting garbage collection, code locality, and more.
  • Background limits: We added new limits on background location and wi-fi scans and changes in the way apps run in the background. These boundaries prevent unintentional overuse of battery and memory and apply to all apps — make sure you understand and account for these in your apps.
  • Complementary Android Vitals dashboards and IDE profilers: In the Play Console you can now see aggregate data about your app to help you pinpoint common issues – excessive crash rate, ANR rate, frozen frames, slow rendering, excessive wakeups, and more. You’ll also find new performance profilers in Android Studio 3.0, and new instrumentation in the platform.
In Android 8.0 your app can directly pin a specific app shortcut in the launcher to drive engagement (left). Notification dots keep users active in your app and let them jump directly to the app’s core functions (right).

For developers, Android Oreo includes many new capabilities to help you build better, more efficient apps. Here are just a few:

  • Autosizing textview: Use autosizing TextView to automatically fill a TextView with text, regardless of the amount. You can create an array of preset text sizes, or set min and max sizes with a step granularity, and the text will grow and shrink to fill the available TextView space.
  • Fonts in XML: Fonts are now a fully supported resource type. You can now use fonts in XML layouts and define font families in XML.
  • Downloadable fonts and emoji: With downloadable fonts you can load fonts from a shared provider instead of including them in your APK. The provider and support library manage the download of fonts and shares them across apps. The same implementation also supports downloadable emoji, so you can get updated emoji without being limited to the emoji built into the device.
  • Adaptive icons: You can now create adaptive icons that the system displays in different shapes, based on a mask selected by a device manufacturer. The system also animates interactions with the icons, and uses them in the launcher, shortcuts, settings, sharing dialogs, and in the overview screen.
Adaptive icons display in a variety of shapes across different device models.
  • Shortcut pinning: App shortcuts and homescreen widgets are great for engaging users and now you can let users add and pin shortcuts and widgets to the launcher from within your app. There’s also a new option to add a specialized activity to help users create shortcuts. The activity is complete with custom options and confirmation.
  • Wide-gamut color for apps: Imaging apps can now take full advantage of new devices that have a wide-gamut color capable display. To display wide gamut images, apps enable a flag in their manifest files (per activity) and load bitmaps with an embedded wide color profile (AdobeRGB, Pro Photo RGB, DCI-P3, etc.).
  • WebView enhancements: In Android Oreo, we’ve enabled WebView multiprocess mode by default and added an API to let your app handle errors and crashes. You can also opt in your app’s WebView objects to verify URLs through Google Safe Browsing.
  • Java 8 Language APIs and runtime optimizations: Android now supports several new Java Language APIs, including the new java.time API. In addition, the Android Runtime is faster than ever before, with improvements of up to 2x on some application benchmarks.

Learn more about these and other new features by visiting the Android 8.0 Oreo site on developer.android.com. Also check out the What’s New in Android Oreo? video for an overview of new features for developers.

Make sure your apps are ready

If haven’t already, take a few moments today to test your apps and make sure they offer the experience you want for users upgrading to Android Oreo.

Just install your current app from Google Play onto a device or emulator running Android Oreo and test the user flows. The app should run and look great, and handle the Android Oreo behavior changes properly. In particular, pay attention to background location limits, notification channels, and changes in networking, security, and identifiers.

Once you’ve resolved any issues, publish your app updates to Google Play in your alpha, beta, or production channels so that they’re available as users start to receive Android 8.0 Oreo.

Speed your development with Android Studio

When you’re ready to build with new APIs in Android Oreo, we recommend updating to the latest version of Android Studio 3.0, available for download from the beta channel. Aside from improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 makes it easier to develop with Instant Apps, XML Fonts, downloadable fonts, and adaptive icons.

Android Studio 3.0 includes tools for developing with Android Oreo features, such as previewing XML font resources in your app.

We also recommend updating to the Android Support Library 26.0.2, available now from Google’s Maven repository, and to the latest SDK, tools, and emulator system images, available in the SDK Manager.

If you’re just getting started building for Android Oreo, read the migration guide first. It gives you an overview of the process and the configuration changes you’ll need to make.

To compile against the official Android 8.0 APIs, update your project’s compileSdkVersion to API 26. We also recommend updating your app’s targetSdkVersion to API 26 to opt-in and test your app with Android Oreo specific behavior changes. See the migration guide for details on how to set up your environment to build with Android Oreo.

Publish your updates to Google Play

Google Play is open for apps compiled against or targeting API 26. When you’re ready, you can publish your APK updates in your alpha, beta, or production channels.

Make sure that your updated app runs well on Android Oreo as well as older versions. We recommend using Google Play’s beta testing feature to get early feedback from a small group of users, then do a staged rollout. We’re looking forward to seeing your app updates!

What’s next for Android Oreo?

We’ll soon be closing the Developer Preview issue tracker, but please keep the feedback coming! You can file a new issue against Android 8.0 in the AOSP issue tracker.

Thanks again to the many developers and early adopters who participated in the Android O Developer Preview and public beta. You gave us great feedback, and filed hundreds of issues that helped us to make the Android Oreo platform great for consumers and developers.

Read More
#io17

Google releases source for Google I/O 2017 for Android

Posted by Shailen Tuli

Today we’re releasing the source
code
for the official Google
I/O 2017
for Android app.

This year’s app substantially modifies existing functionality and adds several
new features. It also expands the tech stack to use Firebase.
In this post, we’ll highlight several notable changes to the app as well as
their design considerations.

The most prominent new feature for 2017 is the event
reservation system, designed to help save in-person attendees’
time and provide a streamlined conference experience. Registered attendees could
reserve sessions and join waitlists prior to and during the conference; a
reservation provided expedited entry to sessions without having to wait in long
lines. Reservation data was synced with attendees’ conference badges, allowing
event staff to verify reservations using NFC-enabled phones. Not only was the
reservation feature incredibly popular, but the reservation data helped event
staff change the size of session rooms both before and during I/O to adjust for
actual demand for seats.

The reservation feature was implemented using Firebase Realtime
Database
(RTDB) and Cloud Functions for
Firebase
. RTDB provided easy sync across user devices — we just had to
implement a listener in our code to receive database updates. RTDB also provided
out-of-the-box offline support, allowing conference data to be available even in
the face of intermittent network connectivity while traveling. A Cloud Function
processed reservation requests in the background for the user, using
transactions to ensure correctness of state (preventing mischievous users from
grabbing too many seats!) and communicating with the event badging system.

As in previous years, we used a ContentProvider as an abstraction layer over all
app data, which meant we had to figure out how to integrate RTDB data with the
ContentProvider. We needed to negotiate between having two local caches for
data: 1) the extant local SQLite database accessed via the ContentProvider, and
2) the local cache created by RTDB to facilitate offline access. We decided to
integrate all app data under the ContentProvider: whenever reservation data for
the user changed in RTDB, we updated the ContentProvider, making it the single
source of truth for app data at all times. This meant that we needed to keep
open connections to RTDB only on a single screen, the Session Detail Activity,
where users might be actively managing their reservations. Reservation data
displayed in other parts of the app was backed by the ContentProvider. In
offline mode, or in case of a flaky or delayed connection to RTDB, we could just
get the last known state of the user’s reservations from the ContentProvider.

We also had to figure out good patterns for integrating RTDB into the overall
sync logic of IOSched, especially since RTDB comes with a very different sync
model than the ping-and-fetch approach we were using in the app. We decided to
continue using Cloud Endpoints
to synchronize user data across devices and with the web and iOS clients (the
data itself was stored in Datastore).
While RTDB provides out-of-the-box data syncing, we wanted to make sure that a
user’s reservation data was current across all devices, even when the app
was not in the foreground.
We used a Cloud Function to integrate RTDB
reservation data into the sync flow: once reservation data for a user changed in
RTDB, the function updated the endpoint, which triggered a Firebase Cloud
Messaging
downstream message to all the user’s devices, which then scheduled
data syncs.

This year’s app also featured a Feed to apprise users about
hour-by-hour developments at I/O (most of the app’s users were remote, and the
Feed was a window into the conference for them). The Feed was also powered by
RTDB, with data pushed to the server using a simple CMS. We used a Cloud
Function to monitor RTDB feed data; when feed data was updated on the server,
the Function sent a Cloud Messaging downstream message to clients, which
visually surfaced the presence of new feed items to the user.

In 2015 and 2016, we had adopted an MVP architecture for IOSched, and we
continued using that this year. This architecture provides us with good
separation of concerns, facilitates testing, and in general makes our code
cleaner and easier to maintain. For the Feed feature, we decided to experiment
with a more lightweight MVP implementation inspired by Android
Architecture Blueprints
, which provided the necessary modularity while being
very easy to conceptualize. The goal here was both pedagogical and practical: we
wanted to showcase an alternate MVP pattern for developers; we also wanted to
showcase an architecture that was an appropriate fit for our needs for this
feature.

For the first time, IOSched made heavy use of Firebase Remote
Config
. In the past, we had found ourselves unable to inform users when
non-session data – wifi information, shuttle schedule, discount codes for
ridesharing, etc. – changed just before or during the conference. Forcing an app
update was not feasible; we just wanted in-app default values to be updatable.
Using remote config easily solved this problem for us.

In the end, we ended up with a three-tier system of informing users about
changes:

  1. Conference data and user data changes were communicated via Cloud Messaging
    and data syncs (ping and fetch model).
  2. Feed data changes were controlled via RTDB.
  3. Changes to in-app constants were controlled via Remote Config.

Future plans

Even though we’re releasing the 2017 code, we still have work ahead of us for
the coming months. We’ll be updating the code to follow modern patterns for
background processing (and making our app “O” compliant), and in the future
we’ll be adopting Android’s Architecture
Components
to simplify the overall design of the app. Developers can follow
changes to the code on GitHub.

Read More
android developers

500 million devices now supported for Android Instant Apps

Posted by Jonathan Karmel

Since our public launch at Google I/O this year, we’ve been hard at work expanding the number of supported devices and the availability of instant apps, so that users can run your apps instantly, without installation. We’re excited to announce that 500 million Android users now have access to instant apps across countries where Google Play operates.

A number of Google Play apps and games businesses across a range of industries have already started building with instant apps. Following the launch of their instant apps, they have seen strong results in engagement, acquisition and retention.

Vimeo: WIth more than 50M creators and 240M viewers worldwide, Vimeo has built a platform whereby people can easily share videos with friends. The company wanted to implement Android Instant Apps to enable their audience to easily immerse themselves in content through a native app experience. Vimeo increased session duration by 130% with their instant app. Discover how Vimeo drove increased engagement with their instant app.
Jet: Based in the US, Jet provides a shopping platform, using a real-time savings engine to surface opportunities for customers to pay less. The company wanted to expand the reach of their existing app, and updated their app in order to support instant apps. Following the launch of their instant app, Jet found that their conversion rate increased by 27%. Learn about how Jet launched their instant app.
NYTimes Crosswords: The NYTimes Crosswords instant app provides users with crossword puzzles as printed in the New York Times daily newspaper. Their aim was to create a more native experience for their audience, increasing app engagement. Instant apps have 2x the number of sessions per user. Based on early results, they are also seeing more effective acquisition, conversion, and long term retention. Learn more about how NYTimes increased app sessions.
dotloop: dotloop is a real estate transaction platform which makes it easier for real estate professionals to interact with home buyers and sellers, and for them to be able to sign documents anytime, anywhere. Their aim for instant apps was to provide more users a native app experience for the signing process of documents. dotloop increased their key metric with a 62% increase in users who sign a document. Discover how dotloop supported Android Instant Apps and increased engagement.
Onefootball: Based in Berlin, the app provides news, live scores, fixtures, results, tables and stats for over 230 leagues and 15 languages. Onefootball built an instant app by reducing its APK size alongside other updates. The number of users who read news and share content increased 55% in their instant app. Find out more about how Onefootball increased engagement following their launch.
Realtor.com: A leading online real estate destination that attracts nearly 60 million unique visitors each month to its desktop and mobile platforms. Realtor.com enabled Android Instant Apps support by modularizing its 12 MB app into instant app modules. With Instant Apps, Realtor.com increased their key conversion metrics having doubled the number of leads per property listing details pageview. Find out how Realtor.com reduced its instant app APK size.

Learn more best practices for managing your download size with Android Instant Apps, and also visit g.co/instantapps for more information on building instant apps and get started today!

How useful did you find this blogpost?

Read More
android developers

Android Instant Apps: Best practices for managing download size

Posted by Dmitry Malykhanov, Developer Relations Partner, Google Play
Android Instant Apps provides rich, native experiences at the tap of a web link. People can experience your app without upfront installation, enabling a higher level and quality of engagement.
However, to provide comparable latency of loading a mobile webpage, an instant app needs to be lean and well structured, so it can be downloaded and run quickly in response to a URL tap. In light of that, we encourage that the binary loaded in response any entry-point URL is as small as possible, with a maximum of 4MB. The smaller the binaries, the faster the instant app will load and the smoother the user experience.
This document will propose best practices for managing the application structure and binary size to enable a smooth instant app experience. These practices will also benefit your installable app.

Refactoring your codebase

The biggest binary size benefit comes from refactoring your app into multiple feature modules. Even if your current size and feature set don’t require multiple features, we recommend designing for it, so you can quickly add more features in the future without affecting the binary size of existing features. We also highly recommend having a unified modular codebase to produce both installable and instant application binaries, as this will reduce the burden of maintaining separate projects and code and provide a cleaner project structure across both. Based on the experience of our early access partners, we believe this will have the largest impact to the binary size at download. However, it also requires the most investment.
To get to that end, you can start with a single (base) module and then refactor code by moving relevant portions to feature module(s). Note that you do not need to worry about the binary size while developing your instant app, as the size limit does not apply for locally built binaries. You can also publish your binary through the Play Developers Console to the Development track (special track for quick deployment of your instant app during development), where the size limit is 10MB. [1, 2] The 4MB restriction is applied once your binary graduate out of the Development track.
Each feature module can have one (or more) entry points – activities – that correspond to a given URL. When splitting a single code base into multiple modules, you will have different entry points for different features, and the platform will load the relevant feature as needed. Remember, the total binary to be downloaded for any given entry point should be under 4MB, so the combined size of any feature module and the base module must be below 4MB.

It is advised to define the feature–activity–entry point mappings first, and then structure the refactoring effort towards reducing the binary size for each entrypoint..
Also consider how your libraries are included. If a specific feature module requires certain libraries they should be included in the feature module only, instead of being added in the base APK. This will reduce the size of the base module. For example, let’s say you have an application that depends on libraries X, Y, and Z. Initially, you may pack all the libraries in the base module by placing all the dependencies in the base gradle.build file. But if only the code in the feature module requires library Z, it makes sense to move that dependency from the base module to the feature module.This works as long as no other feature modules depend on the same library. If multiple feature modules use the same library it definitely makes sense to keep it in the base module.

Lint checks

Many apps tend to acquire a lot of resources, and over a period of time, some of them are no longer used. Android Studio has useful built in lint check for unused resources. Press Alt+Ctrl+Shift+I (Cmd+Alt+Shift+I on Mac OS), type “unused resources” and start “Unused resources Android|Lint|Performance” inspection. It helps to reduce the size of the installable APK as well.

String resources

Similar to resources, pay attention to strings, not all of them may be in use, and typically the application size can be reduced significantly by removing unused string resources. If application supports multiple languages, you may want to reduce the number of localized resources, as it typically removes large chunks of the resources assets. This is especially important if the app supports only a few languages but uses AppCompat library, which includes messages in multiple languages. Use resConfig to select specific resources configurations only. Hint: typically you can use “auto” to restrict configurations pulled from third-party libraries to match the set of configurations defined in your project.

Switch to WebP

Significant reduction of the drawable resources size may be achieved by switching to WebP images instead of PNGs. Android Instant Apps supports all features of the WebP format (transparency, lossless, etc.) so there will be no loss in functionality. Keep in mind that application launcher icons must use PNG format, but it should not be a problem since projects normally keep those in mipmap- directories. If a backward compatible solution is required, you need to include the original PNG images in the APK module and it will override WebP resources automatically (main source set overrides all resources from AAR/feature module). [4]

Of course, going with vector drawables may let you save even more of the precious space, but using vector drawables will require a code change while the above mentioned trick with WebP images for the instant app and PNG images for the installable APK requires no code modifications.

Download assets at runtime

Finally, remember that technically there is no need to pack all the resources in the instant app APKs, as the application can download additional assets at run time. This approach also enables the app to download the required assets only. These modifications may require significant changes to the code base, but will also help you to reduce the size of the installable APK.
If shrinking resources does not bring your app feature modules size under the limit, it is time to look for the ways to reduce the code size.

Review native libraries

Some third-party libraries may include native code, which may not be used in the instant app at all. So the first step is to review the native libraries packaged within the APK and make sure the instant app has only those that are actually used. Remember to look into the compiled APK using APK Analyzer (Build -> APK Analyzer…) [5]

Review external libraries

Next review the list of all external libraries linked with the app’s code. You may find some unexpected surprises courtesy of transitive dependencies. Transitive dependencies occur when the library your project relies upon depends on another library, which in turn may depend on yet another library. Sometimes those transitive dependencies may contain unexpected surprises such as libraries you do not need at all (i.e. a JSON processing library you never use in your code.) Please see “Excluding transitive dependencies” section in the Gradle User Guide for further details.
Android Studio has several useful tools for analyzing the external dependencies for the project. It always helps to start with the Project view:

The “Project” view shows a section called “External libraries”, where you can see all the libraries used by the project including any transitive dependencies:

In order to further reduce the base feature size you may need to pay attention to the code dependencies and external libraries. Check the “Project” view and look for unused libraries that might be transitive dependencies the project does not need. Also look for libraries that provide the same functionality (e.g. multiple libraries for image loading/caching). [4]
You can also compare different builds with APK Analyzer tool, and it works with instant APKs, too.

Finally, review the list of transitive dependencies and exclude the ones you do not need. Use the following command to review the dependencies graph: gradle -q :MODULE:dependencies --configuration compile. Further details can be found in the Gradle documentation.

Other tips

Android Studio 3.0 includes the App Links Assistant tool, which can help to generate the necessary intent filters, and help in splitting the project into several modules. [3]

Once you got the instant app bundles under the size limit, it is the time to make sure the building process is up to date. Check that the application package and instant app APKs are signed using the “APK Signature Scheme v2“. If you sign the APKs using the latest version of the SDK tools, everything should be done automatically. However, if you manually sign the build artifacts you need to avoid using jarsigner and switch to apksigner instead.
And a few useful tips for adapting the app’s code to the instant runtime environment. Keep in mind that having a small branches of code for instant/installable applications, based on the InstantApps.isInstantApp(…), should be fine and typically does not make the source code unreadable (unless you abuse it, of course). Also, when using share intents make sure the code does not explicitly enumerate applications installed on the device, instant app security model does not allow that. Simply use regular Intent.createChooser() to present the list of all possible actions to the user.
The level of effort of developing an instant app for an existing Android application varies across developers and is heavily dependent on how your application is organized today. For some, it will be easy as your project is already organized as multiple modules. However, for some, the focus will be on reducing the code and resource assets size, and we have introduced tools and Android platform features above to help you with that.

Hear from other developers using Android Instant Apps

Finally, check out these great posts by developers that have already built an instant app:

Visit the Android Developers website to get started with Android Instant Apps and check out more instant apps success stories from other developers.

Read More
Android

Playdemic drives user engagement and revenue with live game operations on Google Play

Posted by Adriana Puchianu, Developer Marketing, Google Play

Based in the UK, Playdemic is a free-to-play mobile games developer. Their leading game Golf Clash is designed to provide a short and fun, competitive experience. It uses a simple and accessible game mechanics based on one-thumb gaming which has generated substantial user engagement, with an average of 44 minutes played over three sessions a day. Golf Clash is now played by more than 1.5 million players every day whilst the average revenue per user is equal to other platforms.

Watch Paul Gouge, CEO & Co-founder, and Gareth Jones, Head of Production, discuss how Playdemic uses live game operations (“live ops”) to continuously engage players and grow their business on Google Play. Live ops are also referred to as “running games as a service”; they include the strategic distribution of content and interactions with players that are limited in time and are designed to increase engagement and monetization.

Watch more developer stories and learn about other features and best practices you can use to succeed on Google Play with the updated Playbook app.

How useful did you find this blogpost?

Read More
android developers

Build a subscriptions business on Google Play with these new features and best practices

Posted by Tom Grinsted, Product Manager

Subscriptions can be a sustainable source of revenue, allowing you to invest in your long-term business growth with confidence. Subscription apps are growing rapidly on Google Play; the number of subscribers doubled in the last year and spend on subscriptions has increased 10-times over the past three years. To help the growing number of subscription businesses we’re seeing, we introduced the subscriptions dashboard in the Google Play Console at I/O 2017. Today, we’re adding three new subscription reports covering acquisition, retention, and cancellations to help you understand your data and make informed business decisions. Find information below on the new features, our updated best practices to help you grow your subscriptions business, and stories from other developers succeeding on Google Play.

New subscription reports now available in the Google Play Console

Three new subscription reports in the Google Play Console

The acquisition report enables you to evaluate different acquisition channels, including Adwords and UTM-tagged campaigns. This can help you identify which channels and campaigns are the most successful in acquiring new subscribers.

The retention report displays the lifetime retention of a customized cohort of your subscribers. It allows you to easily compare different subscription products, plots key events such as the end of a free trial, and provides forecasts to enable you to make decisions faster.

Finally, the cancellations report. This detailed cancellation data shows when a user cancels, either voluntarily (such as when they choose to cancel) or involuntarily (for example, when there is payment failure). You can also see whether the cancellation was accompanied by the person uninstalling.

We’re continually working to improve the Google Play Console. If you have ideas or feedback on how we can improve the subscriptions features, please let us know.

Take advantage of the new Google Play Billing Library

To benefit from these features, you need to be using Google Play Billing as the payment method for subscriptions in your app. Implementing Play Billing is easy with the new Google Play Billing Library. We’ve also updated Play Billing so the billing permission will be enforced when the buyer tries to initiate a purchase rather than when you publish your app. This means you can publish a single APK in both Play Billing supported and non-supported countries (rather than maintaining a separate APK that does not use the Billing permission for non-supported countries). Remember to check first if billing is supported before trying to offer any in-app purchases.

Become a ‘subscriptions first’ company and succeed on Google Play

As developers become more sophisticated with their subscriptions offerings on Google Play, our most successful partners have learned a lot about what does and doesn’t work well. Niko Schröer, a partner manager with expert knowledge of subscription apps, has a new post on Medium to help you become a successful subscriptions company. In the post, you’ll find a link to our detailed user research on Android subscribers [PDF] published in June 2017, which offers helpful insights into what users look for in a subscription product. We’ve also published some new best practices on subscriptions, which you can read along with other tips to succeed on Google Play in the Playbook app.

How other developers are succeeding with subscriptions on Play

Viki, a Singapore based video app, uses subscriptions to build a sustainable and predictable revenue stream, allowing them to invest in original content and provide better premium experiences for their users. Total revenue from subscriptions grew over 200% over the year, and by 700% in emerging markets like the Middle East and Latin America. Watch Alex Chan, Senior VP of Product and Engineering at Viki, tell the story.

The developer of Anghami, a popular music service in the Middle East and North Africa, increased the number of subscribers in their app with user interface experiments and introductory pricing. During one promotional period, Anghami used introductory pricing to increase new sign-ups by 400% compared to their average daily sign-ups. Find out more about how Anghami achieves subscription success.

How useful did you find this blogpost?

Read More
Scroll Up