Yuzi download

Android Developer Story Video editing app WeVideo increases user engagement with material design

WeVideo is a video editing platform founded on a vision to make video creation accessible to anyone, anywhere. They first launched the popular WeVideo Video Editor app for Android, and since the latest update to the app, revenue on the platform has doubled every two months. In fact, almost 85% of their mobile users are on Android devices.

Watch Krishna Menon, President & CTO, and Oleg Tsaregorodtsev, Head of Mobile Development at WeVideo, explain how relaunching their app with material design increased user engagement by 100%. They also share how WeVideo improved monetization and installs using ratings & reviews, store listing experiments, and other features on Google Play.

Find out more about material design principles, and, learn how to find success on Google Play.

Available link for download

Google Play Developer Console introduces Universal App Campaigns and User Acquisition performance reporting

Posted by Frederic Mayot, Google Play team

At Google I/O in May, we previewed some new and powerful tools to help you further grow your business and improve decision making based on smarter insights on Google Play. We are happy to announce that, today, these features are live in the Developer Console.

User Acquisition: AdWords Campaigns

With just a few simple steps, universal app campaigns lets you easily set up ad campaigns from within the Google Play Developer Console and promote your app across Google Play, Google Search, YouTube and the Google Display Network. You will now be able to more effectively find and grow your install base with the help of Google’s unparalleled reach.

Universal app campaigns automatically pull in images, video, and descriptions from your Google Play store listing to generate ad formats that look great wherever they are placed. From there, our systems automatically optimize your campaigns and experiment with different creatives and bids to maximize app install volume as close as possible to your target cost-per-install.

To get started with your first campaign, select the User Acquisition tab for your app in the Developer Console and choose ‘AdWords Campaigns.’

User Acquisition: Performance report

When you’re growing an audience for your app, you’ll want to understand where your most valuable users are coming from. The new performance report on the User Acquisition tab in the Developer Console lets you see how people are finding your Play Store listing, how many install your app, and how many go on to make purchases.

The performance report also tracks marketing links tagged with UTM tags, so you’ll be able to get more granular detail on how well your promotion is doing. Once you’ve got visitors to your Play Store listing, you’ll want to start thinking of ways to increase the number of visitors turning into installers. The new Store Listing Experiments feature can help you run A/B tests to do just that.

How to get started in the Developer Console

To learn how to take advantage of these new features in the Developer Console, watch the DevByte video below in which I explain how to set up your first universal app campaign and how to view the new data offered on the performance tab.

We hope you’ll use these user acquisition tools to grow a valuable audience for your app or game. We continue to improve our features for developers based on your feedback – like the recent improvements to beta testing and Store Listing Experiments – in order to help you grow your app or game business globally on Google Play.

Available link for download

Marshmallow and User Data

Posted by Joanna Smith, Developer Advocate and Giles Hogben, Google Privacy Team

Marshmallow introduced several changes that were designed to help your app look after user data. The goal was to make it easier for developers to do the right thing. So as Android 6.0, Marshmallow, gains traction, we challenge you to do just that.

This post highlights the key considerations for user trust when it comes to runtime permissions and hardware identifiers, and points you to new best practices documentation to clarify what to aim for in your own app.

Permission Changes

With Marshmallow, permissions have moved from install-time to runtime. This is a mandatory change for SDK 23+, meaning it will affect all developers and all applications targeting Android 6.0. Your app will need to be updated anyway, so your challenge is to do so thoughtfully.

Runtime permissions mean that your app can now request access to sensitive information in the context that it will be used. This gives you a chance to explain the need for the permission, without scaring users with a long list of requests.

Permissions are also now organized into groups, so that users can make an informed decision without needing to understand technical jargon. By allowing your users to make a decision, they may decide not to grant a permission or to revoke a previously-granted permission. So, your app needs to be thoughtful when handling API calls requiring permissions that may have been denied, and about building in graceful failure-handling so that your users can still interact with the rest of your app.

Identifier Changes

The other aspect of user trust is doing the right thing with user data. With Marshmallow, we are turning off access to some kinds of data in order to direct developers down this path.

Most notably, Local WiFi and Bluetooth MAC addresses are no longer available. The getMacAddress() method of a WifiInfo object and the BluetoothAdapter.getDefaultAdapter().getAddress() method will both return 02:00:00:00:00:00 from now on.

However, Google Play Services now provides Instance IDs, which identify an application instance running on a device. Instance IDs provide a reliable alternative to non-resettable, device-scoped hardware IDs, as they will not persist across a factory reset and are scoped to an app instance. See the Google Developers What is Instance ID? help article for more information.

What’s Next

User trust depends largely on what users see and how they feel. Mishandling permissions and identifiers increases the risk of unwanted/unintended tracking, and can result in users feeling that your app doesn’t actually care about the user. So to help you get it right, we’ve created new documentation that should enable developers to be certain that their app is doing the right thing for their users.

• Understand how permissions and user data are linked
• Learn more about the best practices for permissions
• Discover the best practices for unique identifiers, with clarity based on changes in Marshmallow.

So happy developing! May your apps make users happy, and may your reviews reflect that. :)

Available link for download

Fragments 101 building better user interfaces

Android is an exciting platform to develop for, but it does have one major limitation: you can only display a single Activity onscreen at any one time (true, the upcoming Multi-Window mode does seem set to shake things up a bit, but well get to that shortly).

Thats where fragments come in.

Ever since Android 3.0, fragments have given developers a way of dividing their apps user interface into multiple, self-contained blocks, and then displaying these blocks in the way that makes sense for the users current screen configuration.

When you include fragments in your application, your app can either display these fragments:

• One at a time in separate activities, in whats known as single-pane mode.
• Side-by-side in a single Activity, in whats known as multi-pane mode.

For example, if you use fragments your app may choose to display a single fragment on a handset thats held in portrait mode, and then display two fragments side-by-side on a tablet-sized device – or, it may even switch to multi-pane mode when the user tilts that aforementioned handset from portrait mode, into landscape mode.

This is where the real value of fragments lie: they give you a way of designing a single UI thats flexible enough to adapt to a wide range of different screen configurations. Thanks to the magic of fragments, you can sleep soundly at night knowing that your app is providing a good user experience, regardless of the kind of device it winds up on.

So what is a fragment, exactly?

Lets look at an example. Imagine you have a single Activity (the imaginatively-titled Activity A) and two fragments (Fragment 1 and Fragment 2).

Fragment 1 displays a list of nearby tourist attractions the user might want to visit. When the user selects an item from this list, Fragment B displays information about the currently-selected attraction.

Depending on the current screen configuration, your app may display these fragments in the following ways:

• If the users screen is large enough, Activity A will display Fragment 1 and Fragment 2 side-by-side, in a multi-pane layout.
• If there isnt enough room to accommodate both fragments, the app displays each fragment separately. In this scenario, Activity A displays Fragment 1 only. When the user selects an item from Fragment 1, the app creates a new Activity (lets call it Activity B) whose sole purpose in life is to host Fragment B.

Where does Multi-Window mode fit into all of this?

At this point you may be wondering: whats the difference between fragments and Nougats Multi-Window mode?

Android 7.0 seems set to address some of the platforms one-Activity-at-a-time limitations, but theres a crucial difference between fragments and Multi-Window:

• Multi-Window will allow Android users to view Activities from different applications side-by-side.
• Fragments give developers a way of displaying different content within a single application, depending on the users current screen configuration.

What you need to know before using fragments

When used correctly, fragments are a powerful tool in the Android developers arsenal, but if youre going to get the most out of fragments theres a couple of things you need to bear in mind:

1. A fragment is closely tied to its host Activity

A fragment may have its own behaviour, user interface and (to a certain extent) its own lifecycle, but it can only ever exist inside a host Activity. In fact, let me clarify that point about a fragments lifecycle: you can only add and remove fragments when the host Activity is in its resumed state. This means that even though a fragment does have a distinct lifecycle, that lifecycle is dependent on the lifecycle of its host Activity.

For the sake of keeping this tutorial (relatively) punchy, Im only going to look at how to add a fragment to an Activity declaratively, as this is the quickest and easiest way of getting started with fragments. The downside to this particular method, is that you wont be able to add and remove this fragment at runtime – if this is your end goal, then youll need to delve into your applications code (and the official Android docs has lots of useful info on this).

2. Backwards compatibility

If you want your app to connect with the largest possible audience (and who wouldnt want that?) then it has to be compatible with as many different versions of the Android operating system as possible. The good news is that, even though fragments didnt find their way into Android until Honeycomb, you can use fragments in your project while remaining backwards compatible with Android 1.6 and higher, thanks to the Android Support Library v4.

To add this Support Library to your project, launch the Android SDK Manager, select the SDK Tools tab and download the Android Support Repository.

Next, add the library to your project by opening its module-level build.gradle file and adding the following to its dependencies section:

 dependencies { ……… ……… ……… compile com.android.support:appcompat-v7:24.0.0 } 

This is all you need to do for now, but just be aware that when you come to create your host Activity youll need to do the following:

• Extend FragmentActivity, instead of the usual Activity class.
• Import the android.support.v4.app.Fragment class.

Ill come back to both of these points when were looking at how to create your first Android fragment – which conveniently, just-so-happens to be the subject of our next section.

Creating a Fragment

Although you can create invisible fragments that contribute background behaviour but dont contribute a UI component, most fragments do have a user interface, so Im going to kick things off by defining my fragments UI.

In Android Studio, create a new layout file by opening your projects app/res folder, and then right-clicking the layout folder and selecting New, followed by Layout resource file.

Give your layout resource file a name (Im going to use list_fragment) and select the root element you want to use, such as LinearLayout or RelativeLayout.

Click OK and Android Studio will go ahead and create your layout resource file. At this point you can add whatever UI elements you want to include in your fragment. Im going to use the following:

 <?xml version="1.0" encoding="utf-8"?> <LinearLayout  android_orientation="vertical" android_layout_width="match_parent" android_layout_height="wrap_content" android_background="#CCCCCC"> <TextView android_layout_width="wrap_content" android_layout_height="wrap_content" android_textSize="30sp" android_textStyle="bold" android_textColor="#ffffff" android_text="This is the contents of my list_fragment.xml" android_id="@+id/textView2" android_layout_gravity="center_horizontal" /> </LinearLayout> 

As well as a UI component, you need to have a class associated with your fragment. To create a new class, open your projects app/Java folder, right-click its package name and select New, followed by Java Class.

Give your new class a name (Im going to use ListFragment), then open your new class file and make the following changes:

 import android.os.Bundle; //If you want your app to be compatible with devices running Android 1.6 and earlier, //you need to import the fragment class from the v4 support library// import android.support.v4.app.Fragment; import android.view.LayoutInflater; import android.view.View; import android.view.ViewGroup; //Since Im targeting devices running Android 1.6 and higher, //Im going to extend FragmentActivity, rather than the usual Activity class// public class ListFragment extends FragmentActivity { @Override //onCreateView() must return a View, which is the root of your fragments layout// public View onCreateView(LayoutInflater inflater, ViewGroup container, //If the fragment is being resumed, savedInstanceState will pass data //about the previous instance of the fragment// Bundle savedInstanceState) { //Inflate the fragments layout resource file// return inflater.inflate(R.layout.list_fragment, container, false); } } 

The final step is adding this fragment to your Activity. As already mentioned, there are two ways of doing this, but in this article Im only going to look at adding the fragment declaratively by embedding it in the host Activitys layout resource file.

To add a fragment to an Activity, simply open that Activitys corresponding layout resource file and declare the fragment you want to use, in exactly the same way youd declare a View. So you have no problems distinguishing between the portion of the finished UI thats contributed by the activity_main.xml file, and the portion thats contributed by the fragment, Im going to set activity_main to display an image:

 <?xml version="1.0" encoding="utf-8"?> <RelativeLayout   android_layout_width="match_parent" android_layout_height="match_parent" android_background="@drawable/background" tools_context="com.fragmentsexample.jessicathornsby.myapplication.MainActivity"> //Add your fragment// <fragment android_name="com.fragmentsexample.jessicathornsby.myapplication.ListFragment" android_id="@+id/list_fragment" android_layout_width="match_parent" android_layout_height="wrap_content" /> </RelativeLayoutLayout> 

Wrap-up

And thats it! The full source code for the demo app can be found on GitHub. How have you used fragments in your own Android app projects? Let us know in the comments.

Available link for download

Android Developer Story SGN game ‘Cookie Jam’ increases user conversions with Store Listing Experiments

Posted by Lily Sheringham, Google Play team

Founded in 2010, SGN is a Los Angeles based mobile game developer with hit titles including Cookie Jam, Panda Pop, Juice Jam and Book of Life: Sugar Smash. They now have more than 200 employees and are one of the fastest growing cross-platform gaming developers.

SGN used Store Listing experiments to test multiple variants across their portfolio of games. For Cookie Jam, they saw an 8 percent increase in conversions simply by changing the background color of their app icon. They also saw increased installs following tests with the Panda Pop app icon and by changing the character in their Book of Life: Sugar Smash app icon.

Watch Josh Yguado, Co-founder and President of SGN, and Matthew Casertano, SVP of Game Operations, talk about how using Store Listing Experiments helped SGN improve their ROI, conversion rates and gamer retention.

Find out more about how to run tests on your Store Listing to increase installs and achieve success with the new guide to ‘Secrets to App Success on Google Play’.

Available link for download

Improving the Security and User Experience of your Google Sign In Implementation

Posted by Isabella Chen, Software Engineer

We launched a fully revamped Sign-In API with Google Play services 8.3 providing a much more streamlined user experience and enabling easy server authentication and authorization. We’ve heard from many developers that they’ve found these APIs simple and less error prone to use. But when we look at applications in the Play Store, we see many that are still using legacy Plus.API / GoogleAuthUtil.getToken and do not follow best practices for authentication and authorization. Not following best practices can make your apps easily vulnerable to attack.
It’s also worth noting that developers who don’t want to worry about managing the security implications of different API flows or keeping up to date with the latest  APIs can use Firebase Authentication to manage the entire authentication lifecycle.

Ensuring your apps are secure

Developers should ensure that their apps are not open to the following vulnerabilities:

• Email or user ID substitution attack After signing in with Google on Android, some apps directly send email or user ID in plain text to their backend server as the identity credential. These server endpoints enable a malicious attacker to easily forge a request and gain access to any user’s account by guessing their email / user ID.
  
  Figure 1. Email / User ID Substitution Attack
  We see a number of developers implement this anti-pattern by using getAccountName or getId from the Plus.API and sending it to their backend.
  
  Problematic implementations, DO NOT COPY
  

• Access token substitution attack After signing in with Google on Android, many apps send an access token obtained via GoogleAuthUtil.getToken to their backend server as the identity assertion. Access tokens are bearer tokens and backend servers cannot easily check if the token is issued to them. A malicious attacker can phish the user to sign-in on another application and use that different access token to forge a request to your backend.
  
  Figure 2. Access Token Substitution Attack
  Many developers implement this anti-pattern by using GoogleAuthUtil to retrieve an access token and sending it to their server to authenticate like in the following example:
  
  Problematic implementation, DO NOT COPY

Solution

1. Many developers who have built the above anti-patterns into their apps simply call our tokenInfo (www.googleapis.com/oauth2/v3/tokeninfo) which is debug-only or unnecessarily call the G+ (www.googleapis.com/plus/v1/people/me) endpoint for user’s profile information. These apps should instead implement our recommended ID token flow explained in this blog post. Check out migration guide to move to a both secure and efficient pattern.
2. If your server needs access to other Google services, e.g. Drive, you should use server auth code flow. You can also check out this blogpost. Worth mentioning, you can also get an ID token using server auth code flow, from which you can retrieve user id / email / name / profile url without additional network call. Check out the migration guide.

Improving the user experience and performance of your apps

There are still many apps using GoogleAuthUtil for server auth and their users are losing out the improved user experience while the developers of those apps need to maintain a significantly more complicated implementation.
Here are some of the common problems that we see:

Requesting unnecessary permissions and displaying redundant user experience

Many apps request GET_ACCOUNTS permission and draw their own customized picker with all email addresses. After getting the email address, the app calls either GoogleAuthUtil or Plus.API to do OAuth consent for basic sign in. For those apps, users will see redundant user experience like:

Figure 3. GET_ACCOUNTS runtime permission and redundant user experience

The worst thing is the GET_ACCOUNTS permission. On Marshmallow and above, this permission is displayed to the user as ‘Contacts’. Many users are unwilling to grant access to this runtime permission.

Solution

Switch to our new Auth.GOOGLE_SIGN_IN_API for a streamlined user consent experience by providing an intuitive one-tap interface to provide your app with the user’s name, email address and profile picture. Your app receives an OAuth grant when the user selects an account, making it easier to sign the user in on other devices. Learn more

Figure 4. New streamlined, one-tap sign-in experience

Getting ID Token from GoogleAuthUtil for your backend

Before we released revamped Sign-In API, GoogleAuthUtil.getToken was the previously recommended way to retrieve an ID token via a “magic string.”

Wrong pattern, DO NOT COPY

GoogleAuthUtil.getToken needs to take an email address, which usually leads to the undesirable user experience in Figure 3. Also, user’s profile information like name, profile picture url is valuable information to store in your server. The ID token obtained via Auth.GOOGLE_SIGN_IN_API will contain profile information and your server won’t need additional network calls to retrieve them.
Solution Switch to the ID token flow using the new Auth.GOOGLE_SIGN_IN_API and get the one-tap experience. You can also check out this blogpost and the migration guide for more details.

Getting auth code from GoogleAuthUtil for your backend

We once recommended using GoogleAuthUtil.getToken to retrieve a server auth code via another “magic string.”

Wrong pattern, DO NOT COPY

In addition to the possible redundant user experience in Figure 3, another problem with this implementation was that if a user had signed in to your application in the past and then switched to a new device, they would likely see this confusing dialog:

Figure 5. Confusing consent dialog for returned user if using GoogleAuthUtil.getToken for auth code
Solution

To easily avoid this “Have offline access” consent dialog, you should switch to server auth code flow using the new Auth.GOOGLE_SIGN_IN_API . We will issue you an auth code silently for a previously signed-in user. You can also check out this blogpost and migration guide for more info.

Should I ever use GoogleAuthUtil.getToken?

In general, you should NOT use GoogleAuthUtil.getToken, unless you are making REST API call on Android client. Use Auth.GOOGLE_SIGN_IN_API instead. Whenever possible, use native Android API in Google Play services SDK. You can check out those APIs at Google APIs for Android.
And starting from Google Play services SDK 9.0, you will need to include -auth SDK split to use GoogleAuthUtil.getToken and related classes
AccountChangeEvent/AccountChangeEventsRequest/AccountChangeEventsResponse.
dependencies { compile com.google.android.gms:play-services-auth:9.0.0 }

Available link for download

Android Developer Story Travel app Wego increases monthly user retention by 300 with material design

Headquartered in Singapore, Wego is a popular online travel marketplace for flights and hotels for users in South East Asia and the Middle East. They launched their Android app in early 2014, and today, more than 62 percent of Wego app users are on Android. Wego recently redesigned their app using material design principles to provide their users a more native Android experience for consistency and easier navigation.

Watch Ross Veitch, co-founder and CEO, and the Wego team talk about how they increased monthly user retention by 300 percent and reduced uninstall rates by up to 25 percent with material design.

Learn more about material design, how to use Android Studio, and how to find success on Google Play with the new guide ‘Secrets to App Success on Google Play.’

Available link for download