/app/App_Resources/Android folder
/app/App_Resources/iOS folder
package.json
"nativescript-angular": "1.2.0", "nativescript-camera": "^0.0.8", "nativescript-iqkeyboardmanager": "^1.0.1", "nativescript-plugin-firebase": "^3.8.4", "nativescript-theme-core": "^1.0.2",
platforms
tns run ios
tns run android.
tns livesync ios --watch
tns livesync android --watch
app/main.ts
// this import should be first in order to load some required settings (like globals and reflect-metadata) import { platformNativeScriptDynamic } from "nativescript-angular/platform"; import { AppModule } from "./app.module"; import { BackendService } from "./services/backend.service"; import firebase = require("nativescript-plugin-firebase"); firebase.init({ //persist should be set to false as otherwise numbers aren't returned during livesync persist: false, storageBucket: 'gs://giftler-f48c4.appspot.com', onAuthStateChanged: (data: any) => { console.log(JSON.stringify(data)) if (data.loggedIn) { BackendService.token = data.user.uid; } else { BackendService.token = ""; } } }).then( function (instance) { console.log("firebase.init done"); }, function (error) { console.log("firebase.init error: " + error); } ); platformNativeScriptDynamic().bootstrapModule(AppModule);
app/login/login.component.ts
user@nativescript.org
onAuthStateChanged
onAuthStateChanged: (data: any) => { console.log(JSON.stringify(data)) if (data.loggedIn) { BackendService.token = data.user.uid; } else { BackendService.token = ""; } }
loggedIn
token
app/services/backend.service.ts
app/auth-guard.service.ts
export class AuthGuard implements CanActivate { constructor(private router: Router) { } canActivate() { if (BackendService.isLoggedIn()) { return true; } else { this.router.navigate(["/login"]); return false; } }
const listRoutes: Routes = [ { path: "", component: ListComponent, canActivate: [AuthGuard] }, ];
app/list/list.html
app/list/list.component.ts
public gifts$: Observable;
ngOnInit(){ this.gifts$ = this.firebaseService.getMyWishList(); }
getMyWishList(): Observable { return new Observable((observer: any) => { let path = 'Gifts'; let onValueEvent = (snapshot: any) => { this.ngZone.run(() => { let results = this.handleSnapshot(snapshot.value); console.log(JSON.stringify(results)) observer.next(results); }); }; firebase.addValueEventListener(onValueEvent, `/${path}`); }).share(); }
handleSnapshot
handleSnapshot(data: any) { //empty array, then refill and filter this._allItems = []; if (data) { for (let id in data) { let result = (Object).assign({id: id}, data[id]); if(BackendService.token === result.UID){ this._allItems.push(result); } } this.publishUpdates(); } return this._allItems; }
publishUpdates() { // here, we sort must emit a *new* value (immutability!) this._allItems.sort(function(a, b){ if(a.date < b.date) return -1; if(a.date > b.date) return 1; return 0; }) this.items.next([...this._allItems]); }
<Label class="gold card" textWrap="true" [text]="message$ | async"></Label>
message$
ngOnInit(){ this.message$ = this.firebaseService.getMyMessage(); }
(app/services/firebase.service.ts
getMyMessage(): Observable{ return new Observable((observer:any) => { firebase.getRemoteConfig({ developerMode: false, cacheExpirationSeconds: 300, properties: [{ key: "message", default: "Happy Holidays!" }] }).then( function (result) { console.log("Fetched at " + result.lastFetch + (result.throttled ? " (throttled)" : "")); for (let entry in result.properties) { observer.next(result.properties[entry]); } } ); }).share(); }
app/list-detail/list-detail.component.ts
ngOnInit() { camera.requestPermissions(); ... }
takePhoto() { let options = { width: 300, height: 300, keepAspectRatio: true, saveToGallery: true }; camera.takePicture(options) .then(imageAsset => { imageSource.fromAsset(imageAsset).then(res => { this.image = res; //save the source image to a file, then send that file path to firebase this.saveToFile(this.image); }) }).catch(function (err) { console.log("Error -> " + err.message); }); }
saveToFile(res){ let imgsrc = res; this.imagePath = this.utilsService.documentsPath(`photo-${Date.now()}.png`); imgsrc.saveToFile(this.imagePath, enums.ImageFormat.png); }
/Gifts
editGift(id: string){ if(this.image){ //upload the file, then save all this.firebaseService.uploadFile(this.imagePath).then((uploadedFile: any) => { this.uploadedImageName = uploadedFile.name; //get downloadURL and store it as a full path; this.firebaseService.getDownloadUrl(this.uploadedImageName).then((downloadUrl: string) => { this.firebaseService.editGift(id,this.description,downloadUrl).then((result:any) => { alert(result) }, (error: any) => { alert(error); }); }) }, (error: any) => { alert('File upload error: ' + error); }); } else { //just edit the description this.firebaseService.editDescription(id,this.description).then((result:any) => { alert(result) }, (error: any) => { alert(error); }); } }
uploadFile(localPath: string, file?: any): Promise { let filename = this.utils.getFilename(localPath); let remotePath = `${filename}`; return firebase.uploadFile({ remoteFullPath: remotePath, localFullPath: localPath, onProgress: function(status) { console.log("Uploaded fraction: " + status.fractionCompleted); console.log("Percentage complete: " + status.percentageCompleted); } }); } getDownloadUrl(remoteFilePath: string): Promise { return firebase.getDownloadUrl({ remoteFullPath: remoteFilePath}) .then( function (url:string) { return url; }, function (errorMessage:any) { console.log(errorMessage); }); } editGift(id:string, description: string, imagepath: string){ this.publishUpdates(); return firebase.update("/Gifts/"+id+"",{ description: description, imagepath: imagepath}) .then( function (result:any) { return 'You have successfully edited this gift!'; }, function (errorMessage:any) { console.log(errorMessage); }); }
The Santa Tracker app for Android is a Google holiday tradition. Every year, millions of people around the world use the app to play games with elves and reindeer and, of course, track Santa, as he flies around the world on December 24th. While the app is live for a few months each year, about 90% of our usage occurs in the last two weeks of December. In order to turn around improvements to Santa Tracker quickly over this time, it's critical that we can monitor and adjust the Santa Tracker app remotely. This year, we decided to go all-in with Firebase as our monitoring solution. In this blog post, I'll talk about how we use a combination Analytics, Crash Reporting, and Remote Config to maintain a high level of quality, without ever having to republish the app.
As users navigate through the app we use Firebase Analytics events to record their behavior. Most of the mini-games in the app live in their own Activity classes, so we can use Firebase Analytics' automatic screen tracking feature to record these events without writing any code.
For events within games we use custom events to record important user actions. For example after the user finishes playing the "Penguin Swim" game, we record the event swimming_game_end with custom parameters score and num_stars. In the first week of December we noticed that 85% of users were getting zero stars when playing the Penguin Swim game. Clearly, the game is too hard, we were hoping that only 60-70% of users would get a score this low! We were able to correct this using Remote Config, which I'll talk about later.
swimming_game_end
score
num_stars
The other feature of Analytics that we put to use is user properties. At the start of each Santa Tracker session, we use user properties to record some information about the user's device. These properties are then attached to every analytics event. Since Santa Tracker is used all over the world, we get a lot of diversity in the devices people use. These user properties help us to make sense of our analytics data. Some examples are:
API_LEVEL
DEVICE_BRAND
DEVICE_BOARD
The combination of our custom events and user properties with Firebase Analytics' automatically tracked events enables us to get a good understanding of what our users are doing in the app by looking at the Firebase console.
Despite our best efforts, the Santa Tracker app is not perfect. With millions of users on hundreds of device types in dozens of countries we are constantly discovering new bugs in the wild. Firebase Crash Reporting lets us see all of the fatal errors in our app within a minute of their occurrence. Since Firebase Analytics events show up in Firebase Crash Reporting logs we can see the progression of events before the crash which was very helpful in diagnosing some issues.
For example there's an OutOfMemoryError crash which seems to happen during the "Penguin Swim" game on some low-RAM devices. We did not see this error during our testing, but the Firebase Analytics data in Crash Reporting tells us that this occurs when playing the game repeatedly.
OutOfMemoryError
This integration is invaluable in helping us to reproduce issues that our normal QA setup does not find. We can get the exact device model and then use the analytics log to recreate the crash conditions.
Once we have analyzed the data from Analytics and Crash Reporting, we need to make changes in the app to improve the user experience. Due to the short active life span of this app there's no time to go through the full development lifecycle of the app to publish changes, and we don't get a second chance at Santa's big day!
Santa Tracker uses Firebase Remote Config to gate access to various features, and to provide remote fine-tuning for experiences in the mini game. For example, in the "Penguin Swim" game, there are two key variables we store in Remote Config:
SwimmingObstacleDensity
DisableSwimmingGame
As mentioned earlier, users were having a hard time getting a score higher than zero stars in the game. In order to make the game more fun, we changed SwimmingObstacleDensity from 1.5 to 1.1, which made it much easier for users to dodge obstacles. By making the game easier in this way, the percentage of users getting 0 stars went down from about 85% to 70%. This change took place instantly over the air, with no need to publish a new version of the app!
Right now the OutOfMemoryError in the swimming game happens for <1% of users. But if this issue became rampant, we could use the DisableSwimmingGame flag to immediately hide the game from affected users whilst we resolve the issue. By taking advantage of the fact that Analytics user properties can be referenced in Remote Config, we can even disable the game only for certain device types! For example, let's say the Penguin Swim stopped working on all KitKat devices (API level 19).
First, we add a condition based on user properties:
Next, we disable the game only for users who match the condition:
Now the game will only appear for users who will have a stable experience, which will lead to fewer crashes for our users and more positive app ratings for us.
Adding deep Firebase integration to Santa Tracker gives us the ability to monitor and fine-tune the app over time without releasing app updates. As developers, it's invaluable to have a clear picture of what our users are really doing and how we can improve the app. Throughout December we knew we could rely on Firebase to give Santa Tracker users a magical holiday experience.
If you've been working with Firebase on Android, you may have noticed that you don't normally have to write any lines of code to initialize a feature. You just grab the singleton object for that feature, and start using it right away. And, in the case of Firebase Crash Reporting, you don't even have to write any code at all for it to start capturing crashes! This question pops up from time to time, and I talked about it a bit at Google I/O 2016, but I'd also like to break it down in detail here.
The problem
Many SDKs need an Android Context to be able to do their work. This Context is the hook into the Android runtime that lets the SDK access app resources and assets, use system services, and register BroadcastReceivers. Many SDKs ask you to pass a Context into a static init method once, so they can hold and use that reference as long as the app process is alive. In order to get that Context at the time the app starts up, it's common for the developers of the SDK to ask you to pass that in a custom Application subclass like this:
public class MyApplication extends Application { @Override public void onCreate() { super.onCreate(); SomeSdk.init(this); // init some SDK, MyApplication is the Context } }
And if you hadn't already registered a custom subclass in your app, you'd also have to add that to your manifest in the application tag's android:name attribute:
<application android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:name="package.of.MyApplication" ... >
All this is fine, but Firebase SDKs make this a lot easier for its users!
The solution
There is a little trick that the Firebase SDKs for Android use to install a hook early in the process of an application launch cycle. It introduces a ContentProvider to implement both the timing and Context needed to initialize an SDK, but without requiring the app developer to write any code. A ContentProvider is a convenient choice for two reasons:
Let's investigate those two properties.
ContentProvider initializes early
When an Android app process is first started, there is well-defined order of operations:
When a ContentProvider is created, Android will call its onCreate method. This is where the Firebase SDK can get a hold of a Context, which it does by calling the getContext method. This Context is safe to hold on to indefinitely.
This is also a place that can be used to set up things that need to be active throughout the app's lifetime, such as ActivityLifecycleCallbacks (which are used by Firebase Analytics), or a UncaughtExceptionHandler (which is used by Firebase Crash Reporting). You might also initialize a dependency injection framework here.
ContentProviders participate in manifest merger
Manifest merge is a process that happens at build time when the Android build tools need to figure out the contents of the final manifest that defines your app. In your app's AndroidManifest.xml file, you declare all your application components, permissions, hardware requirements, and so on. But the final manifest that gets built into the APK contains all of those elements from all of the Android library projects that your app depends on.
It turns out that ContentProviders are merged into the final manifest as well. As a result, any Android library project can simply declare a ContentProvider in its own manifest, and that entry will end up in the app's final manifest. So, when you declare a dependency on Firebase Crash Reporting, the ContentProvider from its manifest is merged in your own app's manifest. This ensures that its onCreate is executed, without you having to write any code.
FirebaseInitProvider (surprise!) initializes your app
All apps using Firebase in some way will have a dependency on the firebase-common library. This library exposes FirebaseInitProvider, whose responsibility is to call FirebaseApp.initializeApp in order to initialize the default FirebaseApp instance using the configurations from the project's google-services.json file. (Those configurations are injected into the build as Android resources by the Google Services plugin.) However, If you're referencing multiple Firebase projects in one app, you'll have to write code to initialize other FirebaseApp instances, as discussed in an earlier blog post.
Some drawbacks with ContentProvider init
If you choose to use a ContentProvider to initialize your app or library, there's a couple things you need to keep in mind.
First, there can be only one ContentProvider on an Android device with a given "authority" string. So, if your library is used in more than one app on a device, you have to make sure that they get added with two different authority strings, or the second app will be rejected for installation. That string is defined for the ContentProvider in the manifest XML, which means it's effectively hard-coded. But there is a trick you can use with the Android build tools to make sure that each app build declares a different authority.
There is a feature of Android Gradle builds call manifest placeholders that lets you declare and insert a placeholder value that get inserted into manifest strings. The app's unique application ID is automatically available as a placeholder, so you can declare your ContentProvider like this:
<provider android:authorities="${applicationId}.yourcontentprovider" android:name=".YourContentProvider" android:exported="false" />
The other thing to know about about ContentProviders is that they are only run in the main process of an app. For a vast majority of apps, this isn't a problem, as there is only one process by default. But the moment you declare that one of the Android components in your app must run in another process, that process won't create any ContentProviders, which means your ContentProvider onCreate will never get invoked. In this case, the app will have to either avoid calling anything that requires the initialization, or safely initialize another way. Note that this behavior is different than a custom Application subclass, which does get invoked in every process for that app.
But why misuse ContentProvider like this?
Yes, it's true, this particular application of ContentProvider seems really weird, since it's not actually providing any content. And you have to provide implementations of all the other ContentProvider required methods by returning null. But, it turns out that this is the most reliable way to automatically initialize without requiring extra code. I think the convenience for developers using Firebase more than makes up for this strangeness of this use of a ContentProvider. Firebase is all about being easy to use, and there's nothing easier than no code at all!
Firebase provides a bunch of features to use together in your app, provided by a project that you create at the Firebase console. Normally, it's sufficient to have all your app's resources provided by a single project, but there are times when you want a single app to be able to access data from multiple projects. For example, you may need to access data from two different databases, and be able to authenticate users to access each one. I'll show you how that's done in this post.
GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN) .requestIdToken(getString(R.string.default_web_client_id)) .requestEmail() .build();
google-services.json
FirebaseDatabase database = FirebaseDatabase.getInstance();
FirebaseOptions options = new FirebaseOptions.Builder() .setApplicationId("1:530266078999:android:481c4ecf3253701e") // Required for Analytics. .setApiKey("AIzaSyBRxOyIj5dJkKgAVPXRLYFkdZwh2Xxq51k") // Required for Auth. .setDatabaseUrl("https://project-1765055333176374514.firebaseio.com/") // Required for RTDB. .build(); FirebaseApp.initializeApp(this /* Context */, options, "secondary");
FirebaseApp
FirebaseDatabase.getInstance()
// Retrieve my other app. FirebaseApp app = FirebaseApp.getInstance("secondary"); // Get the database for the other app. FirebaseDatabase secondaryDatabase = FirebaseDatabase.getInstance(app);
.requestIdToken(getString(R.string.default_web_client_id))
{ "client_id": "56865680640-e8mr503bun5eaevqctn4u807q4hpi44s.apps.googleusercontent.com", "client_type": 3 },
AuthCredential credential = GoogleAuthProvider.getCredential(account.getIdToken(), null); FirebaseAuth.getInstance().signInWithCredential(credential); FirebaseApp app = FirebaseApp.getInstance("secondary"); FirebaseAuth.getInstance(app).signInWithCredential(credential);
Default Auth UID: 0960868722032022577213DA4EA8B7A1683D92B405DD Secondary Auth UID: 7h6XOeSxmkNsSseFJ1jU31WZHDP2
firebaseAuth.getCurrentUser().getToken(false /* forceRefresh */) .addOnCompleteListener(new OnCompleteListener() { @Override public void onComplete(@NonNull Task task) { String token = task.getResult().getToken(); // Send this to the server. } });
FirebaseOptions options = new FirebaseOptions.Builder() .setServiceAccount(new FileInputStream("default-service-account.json")) .build(); FirebaseApp.initializeApp(options); FirebaseOptions secondaryOptions = new FirebaseOptions.Builder() .setServiceAccount(new FileInputStream("secondary-service-account.json")) .build(); FirebaseApp.initializeApp(secondaryOptions, "secondary");
// Verify the ID token using the default app. FirebaseAuth.getInstance().verifyIdToken(idToken) .addOnSuccessListener(new OnSuccessListener() { @Override public void onSuccess(FirebaseToken decodedToken) { String uid = decodedToken.getUid(); System.out.println("User " + uid + " verified"); FirebaseApp app = FirebaseApp.getInstance("secondary"); String customToken = FirebaseAuth.getInstance(app).createCustomToken(uid); // TODO: Send the token back to the client! } });
FirebaseApp app = FirebaseApp.getInstance("secondary"); FirebaseAuth.getInstance(app).signInWithCustomToken(token);
Default Auth UID: 0960868722032022577213DA4EA8B7A1683D92B405DD Secondary Auth UID: 0960868722032022577213DA4EA8B7A1683D92B405DD
var config = { apiKey: "", authDomain: ".firebaseapp.com", databaseURL: "https://.firebaseio.com", storageBucket: ".appspot.com", messagingSenderId: "", }; var secondary = firebase.initializeApp(otherAppConfig, "secondary"); var secondaryDatabase = secondary.database();
// Alt: load from plist using |FIROptions(contentsOfFile:)| let options = FIROptions(googleAppID: googleAppID, bundleID: bundleID, GCMSenderID: GCMSenderID, APIKey: nil, clientID: nil, trackingID: nil, androidClientID: nil, databaseURL: databaseURL, storageBucket: nil, deepLinkURLScheme: nil) FIRApp.configure(withName: "secondary", options: fileopts) guard let secondary = FIRApp.init(named: "secondary") else { assert(false, "Could not retrieve secondary app") } let secondaryDatabase = FIRDatabase.database(app: secondary);
Version 10.0.0 of the Google Play services client libraries, as well as the Firebase client libraries for Android, will be the last version of these libraries that support Android API level 9 (Android 2.3, Gingerbread). The next scheduled release of these libraries, version 10.2.0, will increase the minimum supported API level from 9 to 14 (Android 4.0.1, Ice Cream Sandwich). This change will happen in early 2017.
The Gingerbread platform is almost six years old. Many Android developers have already discontinued support for Gingerbread in their apps. This helps them build better apps that make use of the newer capabilities of the Android platform. For us, the situation is the same. By making this change, we will be able to provide a more robust collection of tools for Android developers with greater speed.
You may use version 10.0.0 of Google Play services and Firebase as you are currently. It will continue to work with Gingerbread devices as it has in the past.
When you choose to upgrade to the future version 10.2.0, and if your app minimally supports API level 14 or greater (typically specified as "minSdkVersion" in your build.gradle), you will not encounter any versioning problems. However, if your app supports lower than API level 14, you will encounter a problem at build time with an error that looks like this:
Error:Execution failed for task ':app:processDebugManifest'. > Manifest merger failed : uses-sdk:minSdkVersion 9 cannot be smaller than version 14 declared in library [com.google.android.gms:play-services:10.2.0] Suggestion: use tools:overrideLibrary="com.google.android.gms:play_services" to force usage
Unfortunately, the stated suggestion will not help you successfully run your app on older devices. In order to use Google Play services 10.2.0 and later, you can choose one of the following options:
This is the recommended course of action. To discontinue support for API levels that will no longer receive Google Play services updates, simply increase the minSdkVersion value in your app's build.gradle to at least 14. If you update your app in this way and publish it to the Play Store, users of devices with less than that level of support will not be able to see or download the update. However, they will still be able to download and use the most recently published version of the app that does target their device.
A very small percentage of all Android devices are using API levels less than 14. You can read more about the current distribution of Android devices. We believe that many of these old devices are not actively being used.
If your app still has a significant number of users on older devices, you can use multiple APK support in Google Play to deliver an APK that uses Google Play services 10.0.0. This is described below.
Along with some configuration and code management, you can build multiple APKs that support different minimum API levels, with different versions of Google Play services. You can accomplish this with build variants in Gradle. First, define build flavors for legacy and newer versions of your app. For example, in your build.gradle, define two different product flavors, with two different compile dependencies for the components of Play Services you're using:
productFlavors { legacy { minSdkVersion 9 versionCode 901 // Min API level 9, v01 } current { minSdkVersion 14 versionCode 1401 // Min API level 14, v01 } } dependencies { legacyCompile 'com.google.android.gms:play-services:10.0.0' currentCompile 'com.google.android.gms:play-services:10.2.0' }
In the above situation, there are two product flavors being built against two different versions of the Google Play services client libraries. This will work fine if only APIs are called that are available in the 10.0.0 library. If you need to call newer APIs made available with 10.2.0, you will have to create a compatibility library for the newer API calls so that they are only built into the version of the application that can use them:
After building a release APK for each flavor, you then publish them both to the Play Store, and the device will update with the most appropriate version for that device. Read more about multiple APK support in the Play Store.
Developer feedback continues to be a critical medium for us to ensure Firebase meets the needs of the community. Since we launched the expansion of Firebase at Google I/O in May, we received a clear message that many of you would like to try Firebase Test Lab without having to enter a credit card number and upgrade to the paid Blaze plan. We agree, and we're proud to introduce Firebase Test Lab for Android for the Firebase Spark and Flame plans. Here's how it works.
For Firebase projects on the Spark or Flame plan, you may run up to five tests on physical devices and up to ten tests on virtual devices on a daily basis. This means you have a total budget of fifteen tests to use throughout the day. For each test run, you may target up to four different devices, and you can mix physical and virtual devices as needed. For example, you could execute five runs targeting three devices each run, using your full budget of fifteen tests for the day. Or, each of your fifteen tests could be executed on a single device in fifteen individual runs.
For projects on the Spark plan, there is no billing information required to make use of your daily quota of tests.
For both plans, the daily quota of physical and virtual device tests refreshes at 12am PST, so you can use that to schedule your daily allotment of tests. The maximum duration for tests on virtual devices is one hour, and the maximum on physical devices is thirty minutes. You can also split your allotment of tests between Robo tests, which will test your application automatically, and instrumentation tests, which allow you to script your application with Espresso, UI Automator 2.0, and Robotium.
For projects on the Blaze plan, nothing changes. You continue to run tests for $5 per device-hour on physical devices. Virtual devices can be used at no cost till the end of December (12/31/2016) then at $1 per device-hour starting 2017.
Also available now is the ability to run tests against virtual devices with Nougat MR1 at API level 25. The Firebase Test Lab team is committed to making sure you have access to the latest versions of Android, so you can spot incompatibilities early during your development.
Improving the quality of your applications is easier with Firebase. Please let us know how you're using Firebase Test Lab for Android on our support channels, including the firebase-talk mailing list, and the #test-lab channel on the Firebase Slack.
At Google, we understand how important the quality of your application is in order to grow your user base, increase customer satisfaction and boost your revenues. When we took a closer look at data from 1-star reviews on Google Play, we observed that more than 50% of these reviews are related to bugs and crashes in the app.
For many developers, finding and resolving these problems prior to release can be very challenging. As the Android ecosystem continues to grow rapidly, it can be a daunting task to maintain a high quality, performant app that scales well for your users. As your user base grows, you may only have access to a handful of devices to use for testing. Accessing devices that are unavailable in your country is also difficult. Moreover, setting up a proper testing infrastructure that facilitates pre-release testing is a very expensive and time-consuming process that requires continual maintenance.
To help streamline the testing of mobile applications, we’re introducing Firebase Test Lab for Android, a platform where you can automate testing with the same tools that Google uses to test its own products. With a few easy steps, you can launch your tests on our physical devices to help ensure the best possible quality for your applications.
Testing Android applications normally involves writing instrumentation tests to script the interactions with the app. If you’ve already written tests using Espresso, UI Automator 2.0, or Robotium, you can begin running those tests today on devices hosted by Firebase Test Lab.
Authoring instrumentation tests is easier now with Android Studio 2.2 (or newer) using the new Espresso Test Recorder tool. All you have to do is launch your app in recording mode, and the test recorder will observe and remember all your interactions with the app, then generate test code in Espresso that duplicates those interactions. You can then turn around and run these tests in Firebase Test Lab.
Even if you’re not writing your own tests, you can still use Firebase Test Lab. We have a fully automated, intelligent test called a Robo test that will crawl your app by performing interactions with your app’s user interface. You don’t have to write a single line of code to gain the benefits of this automated coverage.
With each test you run, you will select from a variety of device manufacturers and models, Android versions, and configurations (Virtual devices are also now available as a beta offering). Firebase Test Lab will then run your tests on multiple devices simultaneously to satisfy your selections as quickly as possible. When the tests are complete, the results from the test will be stored in your Firebase project.
Testing works best when it happens throughout the development process, not just before you publish your app on Google Play. To simplify this process, Firebase Test Lab gives you the ability to invoke tests directly from within the tools you’re already using, such as Android Studio and the Firebase Console. Our command-line interface allows you to run your tests through your continuous integration setup. Additionally, after you opt-in to receive the pre-launch report in the Google Play Developer Console, every new version of an app you publish to an Alpha or Beta channel will receive a free, five minute Robo test. These test results will become visible in the Play Store Developer Console.
The Play pre-launch report generated from running the Robo tests is currently available at no cost! For more customized testing using Firebase Test Lab, customers on the Blaze Billing Plan will be charged $5 per physical device hour, and after October 1st, 2016, $1 per virtual device hour. Prior to that, virtual devices are available at no charge. See our pricing page for details.
Running your first test on Firebase Test Lab is easy. You can follow our step-by-step codelab which walks you through various scenarios for running your first test. You can refer to our full documentation here. If you have questions or encounter any issues, please ask in the Firebase Google group.
Happy testing!
