Com android builder testing api

com.android.builder.testing.api.DeviceException: No connected devices! #9959

Comments

thanhdx0 commented Sep 17, 2016

Error

I’ve just try to use react native to build android applications.
I followed this instruction https://facebook.github.io/react-native/docs/getting-started.html#content, installed all tools, then build AwesomeProject. After running command, react-native run-android, I got the error notice No connected devices as the title. But I ran the Android Emulator before (I use Genymotion).
In the terminal, the line after Starting JS server. says /bin/sh: 1: adb: not found.
How can I fix it?

Additional Information

• React Native version: 0.33.0
• Platform(s) (iOS, Android, or both?): Android
• Operating System (macOS, Linux, or Windows?): Ubuntu 16.04 LTS

The text was updated successfully, but these errors were encountered:

nihgwu commented Sep 17, 2016

exec adb devices to check if the emulator is online

thanhdx0 commented Sep 17, 2016

@nihgwu it says adb server version (32) doesn’t match this client (36); killing. daemon started successfully
But when I start genymontion before command react-native run-android then it notices failed to start daemon after line «Starting JS Sever. «.
When I power off genymotion then run the command, seem like it starts daemon successfully but still have the error «No devices connected» at the end.

nihgwu commented Sep 17, 2016

thanhdx0 commented Sep 17, 2016

Thanks. I forgot to search before ask.

gilcierweb commented Dec 16, 2016

hramos commented Jul 21, 2017 •

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we’re automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

• Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
• If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
• Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

Источник

Failed run android simulator : com.android.builder.testing.api.DeviceException: Timeout getting device list. #8073

Comments

kumartarun commented Jun 12, 2016

FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ‘:app:installDebug’.

com.android.builder.testing.api.DeviceException: Timeout getting device list.

Try:
Run with —stacktrace option to get the stack trace. Run with —info or —debug
option to get more log output.

Total time: 1 mins 42.749 secs
Could not install the app on the device, read the error above for details.
Make sure you have an Android emulator running or a device connected and have
set up your Android development environment:
https://facebook.github.io/react-native/docs/android-setup.html

spent lot of time in setting up environment but now i am stuck here , My emulator working fine appropriate build tools installed
Help !!

The text was updated successfully, but these errors were encountered:

stanhe commented Jul 7, 2016 •

i think it’s maybe the gradle script problem,i have’t check this code .but you can follow this:
1.start your genymotion launch page,where you can creat your virtual devices.
Settings —> ADB —> Use custom Android SDK tools ,set the location you used before
2.restart genymotion and run adb devices,you will get the right devices,run react-native run-android
intresting! nothing changed yet,yes. you are right.then?
3.go to the project you just creat «AwesomeProject»,goto app/build/outputs/apk,drag the app-debug.apk to the genymotion.now it works ,you can edit the index.android.js file,and double R on the genymotion to start work ,but now the react-native run-android still get Error when install app.
4.restart computer update genymotion to the lastest and add a genymotion 6.0-API23 simulator run-android,it resolved.

mkonicek commented Oct 27, 2016

Hi there! This issue is being closed because it has been inactive for a while.

Product Pains has been very useful in highlighting the top bugs and feature requests:
https://productpains.com/product/react-native?tab=top

Also, if this issue is a bug, please consider sending a pull request with a fix.

Источник

Unit testing API requests on Android

Mar 11, 2017 · 8 min read

In this article I want to show you a tutorial on how I decided to test the API Request layer using RxAndroid, Retrofit, Mockito and the Model View Presenter (MVP) architecture. We will build an Android app using the free Star Wars API that displays characters data from the movie.

This tutorial requires a previous knowledge of Android development, Unit Tests and Reactive programming. If you want to see the entire code it’s at this github repository.

Project Setup

On Android Studio (I’m u sing the version 2.2.3 currently) start a basic project with an empty activity. I will personally choose the minimum API of Android 4.0.3 (15) for this tutorial.

Following below are all the external dependencies needed at the build.gradle file and a brief description of each one:

• RxAndroid: library that brings Reactive Extensions to Android
• Retrofit: the HTTP Rest Client we will use to perform the API requests. I have chosen Retrofit because of its RxJava adapter that makes it easier to convert an HTTP response into an Observable.
• Gson: the JSON deserializer we will use to transform the HTTP response into java models.
• Junit: Java unit test framework. We will use some of its annotations and assertion methods.
• Mockito: besides its mocking feature, this framework will be used to verify interactions (i.e.: method calls) of classes.

Creating Model Classes

The next step will be the creation of our models that will represent the response returned from the characters request.

My suggestion is to use immutable models, given its advantages. For now, I will make all attributes as public and final instead of creating getter methods for each of them, because I intend to write a second part of this article where I explain how to validate models using reflection. Therefore, all values are set at object instantiation by its constructor.

API Request

Now that we have our project configured and our models created we will implement the API Request feature.

First, add the permission to access the internet in you manifest file:

As mentioned above, we will perform a request to obtain a list of Star Wars characters, then it will be required to add this endpoint description as described in Retrofit documentation in a form of a Java interface. As we’re going to see next, interface are easier to test since we can mock it using Mockito.

Below it’s the implementation of the interface described above, basically it instantiates Retrofit with its RxJava Adapter, performs and HTTP request and converts the response into an Observable.

Contract between Presenter and View Layer

Next we will create an interface defining the communication between the presenter and the view. The interface is necessary to maintain each class uncoupled and to make them easier to mock in the tests.

The view interface will have the following methods:

• onFetchDataStarted: notify the view that a request is about to start. Useful for giving user a feedback like displaying a progress bar.
• onFetchDataCompleted: notify the view that no more data will be returned.
• onFetchDataSuccess: return the requested data as its parameter, in the model type we have defined above.
• onFetchDataError: an error has occurred during the request. Could be a connection failure, for example.

The presenter interface will have the following methods:

• loadData: will tell the presenter to start fetching data.
• subscribe: notify the presenter that its view has become active. This can be used to trigger the API request.
• unsubscribe: notify the presenter that its view has become inactive. This can be used to cancel any previous request that hasn’t returned yet.
• onDestroy: notify the presenter that its view instance is about to be destroyed. In this tutorial the view will instantiate the presenter and they will maintain a reference to each other by private properties, so we should clear this reference on the presenter when the view is going through the onDestroy lifecycle otherwise this will lead to memory leaks .

Presentation Layer

Next we create our presenter implementing the interface defined above. This layer is the most complex layer in our application, so I will explain with more details.

In this tutorial, all the dependencies will be injected in the constructor and these will be defined by whoever instantiates the presenter. We could use a tool to handle the DI (like Dagger), but it’s not the focus of this article. For now, we just need a simple dependency injection to help our unit tests.

Following there is a brief description of each dependency of our presenter:

• charactersDataSource: the Retrofit description of the Star Wars characters endpoint.
• backgroundScheduler: the Scheduler on which our API request Observable will operate.
• mainScheduler: the Scheduler on which we want our observer to wait for the API request Observable callbacks.
• view: any instance (can be a mock) that implements the view interface defined above.

In the constructor method we also have to initialize our CompositeSubscription instance, an object that will hold all Subscriptions generated by Observables. This object will be used to unsubscribe the Observers when the response is not needed anymore (ex.: app goes to the background state).

This is the initial implementation of the presenter, including its attributes and the constructor :

Apart from loadData method of the presenter, the implementation of the others interface methods are simple and self-explanatory:

Finally, we implement the loadData method, that will use the CharactersDataSource instance to perform the API request and notify the view in case of success or error.

Presenter tests

Even without the view implementation (the Activity in this case) we can already test the presenter. In this tutorial, we will focus only on two test cases:

• Given the presenter has requested data and its data source has returned the characters data successfully, I want to verify if the view receives it.
• Given the presenter has requested data and somehow the data source has returned error, I want to verify if the view receives the proper feedback.

In the default Android Studio project creation, there is already a package that includes a simple unit test class called ExampleUnitTest.java. This package is usually named by your applicationId followed by test. We will create in this package a class called MainPresenterTest.java.

At our test class, we will first declare our mock objects needed by the object under test (the presenter) as class attributes. The two dependencies needed to be mocked are the view and the data source.

The “ @Mock” annotation is from the Mockito dependency we have declared at our build.gradle, and that means the library will be responsible to create a mock instance.

To make sure a new mock is created for each new test and therefore all tests are independent, we will initialize the mocks at the “ @Before” step of this test class.

Every test case we will write will be represented by a public void method with the JUnit “@Test” annotation. You can run this test by clicking the green icon located next to the method name. The test below should pass since there is no implementation.

We will now implement this test case starting by defining the behavior of the data source mock. Since we want the unit test to be fast and to not rely on internet connection, we will tell the data source to return a fixed response.

The code above means that whenever the method getCharacters() is called return the CharactersResponseModel instance declared.

Now we should instantiate the presenter passing the mocks as dependencies:

One trick here is to “ Schedulers. immediate()” as both background and main schedulers so there won’t be a delay when fetching the characters data.

Next we call the loadData method of our presenter interface which will allow us to write the test assertions. This is the current state of our test case:

In brief, these are the view assertions that will be tested after loadData is called in this sequence:

1. onFetchDataStartedmethod should be called once
2. onFetchDataSuccess method should be called once and return the same exact model returned by CharactersDataSource.
3. onFetchDataCompleted method should be called.

Now we write a similar test case, but to the error case:

Conclusion

The MVP Architecture along with Mockito and Reactive Extensions make unit tests very simple to write. We have written just basic test cases for a one-screen application but the improvements in software quality and development speed will be more noticed when the application starts to grow.

Besides the advantage of automating the manual test, and therefore catching bugs earlier, I personally like the idea that unit tests give me confidence of the code I have written, allowing it to be refactored without introducing bugs.

Источник