✨ 2025 Year review
👉 Learn more
Sign in
Sign in

Android Development

Android Development, Genymotion, Genymotion Cloud, Genymotion Cloud (AWS-GCP)

Access internal web services from Android devices running in the cloud using adb reverse

/

It can be pretty common for your project to have some security and confidentiality problematics?. In some cases, your application may need to access an internal web service: It is a private business application accessing confidential internal information. It is an application accessing some web services currently under development and those services must remain private until finished.   Accessing those private backends while automating your tests in the cloud can be tricky. You could do it with a VPN, but it can be cumbersome. Adb reverse is another solution, easier to set up. Luckily for you, we managed to make it work with Genymotion Cloud ?. Let’s dig in and see how it works! In this article, we study the case of an app running automated tests from Genymotion Cloud, but accessing web services running on a private network.   TL;DR 1. On your CI server, run a local proxy (such as Squid, running on port 3128). 2. Start a Genymotion Cloud device using the gmsaas CLI: uuid=$(gmsaas instances start 143eb44a-1d3a-4f27-bcac-3c40124e2836 pixel3) gmsaas instances adbconnect $uuid This gives you access to the device through ADB. 3. Configure the proxy settings in the device using ADB: adb shell settings put global http_proxy localhost:3333 4. Bind your local proxy to the device proxy configuration using command: adb reverse tcp:3333 tcp:3128 5. Make sure your app handles Proxy System Settings. 6. Run your tests as usual. You can also go further by using different URLs depending on the build type… Everything is explained below ? Let’s start with a diagram of the situation: You can see a Genymotion Cloud device located on our datacenter launched by a continuous integration server running on your internal network. This is done through gmsaas,  the Genymotion command line tool. An ADB tunnel is created between the server and the virtual device, allowing to use `adb` on the device, as if it was running locally. On the other hand, your internal web service is not exposed and therefore cannot be accessed from the virtual device. How to overcome this, without exposing your internal web service to the Internet? ADB reverse to the rescue! ?   Accessing the infrastructure Run a local proxy on your CI server This piece of software is aimed to expose your internal web service located in your infrastructure to a local network connection occurring on your CI server. ADB is running on your CI server, and it is the only one that will connect to the proxy. You must run a single proxy server for all the devices needing access to your internal web service. There are plenty of ways to start a proxy on your server. Here is for example how to launch a Squid proxy using docker : First, make sure folder /opt/squid/cache is created. Also, you must set up a configuration file /opt/squid/squid.conf. You can use this simple configuration: # Squid proxy port declaration http_port 3128 # Allow local connections, including Docker’s host acl localnet src 10.0.0.0/8     # RFC1918 possible internal network acl localnet src 172.16.0.0/12  # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl localnet src fc00::/7       # RFC 4193 local private network range acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines http_access allow localnet http_access allow localhost http_access deny all Then run the following docker command: docker run –name squid \ –publish 127.0.0.1:3128:3128 \ –volume /opt/squid/squid.conf:/etc/squid3/squid.conf \ –volume /opt/squid/cache:/var/spool/squid3 \ –volume /opt/squid/cache:/var/log/squid3 \ sameersbn/squid:3.3.8-12   Start the virtual device Before each test run, the CI server starts one or several cloud devices using gmsaas. Start a device using: uuid=$(gmsaas instances start 143eb44a-1d3a-4f27-bcac-3c40124e2836 pixel3) This command starts a new Pie virtual device on Genymotion Cloud. Once this command is finished, connect to the device with adb : gmsaas instances adbconnect $uuid, you can interact with it using `adb` commands, through the ADB tunnel. Configure the device to use a proxy Today, Genymotion Cloud virtual devices are disposable. It means they are deleted when you stop them and all their configuration and files are lost. You must configure them each time you start them. You can set the proxy configuration from the command line : adb shell settings put global http_proxy localhost:3333 Note: If you need a more precise configuration (configuring the proxy exclusion list for example), we recommend configuring a Genymotion Cloud virtual device through the Wifi Settings application and to share it on Genymotion Cloud with all your team as explained in the documentation. Bind the device’s configuration to your CI server’s proxy Now on one side, we have a Squid proxy running on the CI server bound to local port 3128 and on the other side, we have a device looking for a proxy server on its own local port 3333. ADB allows us to bind those two remote ports thanks to the `adb reverse` command. Run command: adb reverse tcp:3333 tcp:3128 This command redirects all the network traffic inside the device going to localhost:3333 to your computer localhost:3128. Once everything is set up, here is how your infrastructure behaves: All the network traffic of the cloud device goes through the ADBtunnel, arrives to the ADB server running on your CI computer and is redirected to the Squid proxy, exposing your internal web service to the remote virtual device. Your internal web service is then accessible from your app, as soon as you make sure it observes the proxy system settings. Note: The `adb reverse` command is supported on Android since Android 5.0 only, so make sure you select the right version.   Use the proxy system settings in your app You must be careful that your HTTP client observes the proxy settings that have been set up. If you are using OKHttp library, this is handled directly by the client, there is nothing to do from your part. If not using OKHttp library, you must set the proxy from your app source code, depending on your HTTP client.   Conclusion You did it! A simple setup where you decide to

Android Development, Resource

Open Source Project: Scrcpy now works wirelessly!

/

Last week, we introduced our new open source project: scrcpy. The feedbacks were amazing, many people were interested in the application. ? This was very motivating, and a lot of work has been done in the last few days to fix important issues.? For example, mouse clicks now work on LG devices, a memory leak and a segfault on copy/paste have been fixed. For convenience, we also added some mouse shortcuts?: • middle-click presses the HOME button, • right-click presses the BACK button (on turn the screen on), • double-click on black borders resize the window to fit the device screen. But a specific feature was much requested: make it work over Wi-Fi.   Wireless The application communicates with the device over adb, so it should be easy to make it work wirelessly: Connect to a device over Wi-Fi. It was not counting on an adb bug preventing adb reverse to work over a connection established by adb connect. Therefore, we implemented a workaround to fallback using adb forward (and reversing the client/server roles) when adb reverse fails.   How to run scrcpy wirelessly? Here are the steps: 1. Connect the device to the same Wi-Fi as your computer 2. Get your device IP address (in Settings → About phone → Status) 3. Enable adb over TCP/IP on your device: adb tcpip 5555 4. Connect to your device: adb connect DEVICE_IP:5555 (replace DEVICE_IP) 5. Unplug your device 6. Run scrcpy as usual To switch back to USB mode: adb usb. As expected, the performances are not the same as over USB. The default scrcpy bit-rate is 8Mbps, which is probably too much for a Wi-Fi connection. Depending on the use case, decreasing the bit-rate and the resolution may be a good compromise: scrcpy –bit-rate 2M –max-size 800 For people in a hurry: scrcpy -b2M -m800 Note that while it now works over TCP/IP, this is not an optimal solution for streaming a video wirelessly, since the raw stream is still sent over TCP, where a packet loss is very bad for latency, due to head-of-line blocking. But it’s better than nothing! Under good conditions, it may work pretty well: On the video, scrcpy is started over USB on the laptop with Debian (on the right), and over Wi-Fi on the Mac (on the left). You can now build, install and run the new version! Enjoy!

Android Development, Application Development, Dev Tips

4 Tips That Will Help You Create Your First Android App

/

There are many people out there with excellent app ideas. However they often encounter the same problem: they don’t know where to start! If you have found yourself in this situation, here is some good news: you’re not the only one. Even better, you’ve come to the right place! We’ve made this noob-friendly guide that can come in handy ? Tip 1: Learn the basics of coding The truth is hard to accept, but if you want to dive into Android app development you’ll have to learn the basics of coding . There is indeed a bunch of code-free mobile app development solutions around but you’ll quickly figure out that, sooner or later, you’ll have to get your hands dirty to make your app behave the way you want it to behave. Learn Java Java is a key pillar of Android and is used by the SDK (Software Development Kit) for every single application. You simply cannot miss that step (life ain’t easy) but there are many platforms that can help you get going! Codecademy or Sololearn are good places to start. Learn Android “Well… Obviously! Duh!” Hold on, we’re talking about Android core app concepts here: activities, services, providers, receivers, intents… Not so smart now huh? ? Take a look at “Application Fundamentals” from the official Android documentation to get started. Be a sponge The more you learn, the easier it becomes. Whether you’d like to know the basics of a new language or to dive into a very specific concept of Android, we recommend following this path: YouTube tutorials → books → conferences. Start with the Android Dev official channel, you won’t regret it. Tip 2: Thinking smart to make things smooth If you’re reading this guide, you probably already have an idea of what your Android app will be about. But don’t rush to creation too early! Be sure your idea is the right one and above all that it’s feasible considering you have few to no skills or experiences in Android app development. Start small A cool app doesn’t have to be complicated. Apps that get most of the downloads are not necessarily the most intricate. Also, going with a clean and simple user interface which requires very little input from your users will make things much easier when it comes to code. Start here or take a look Android’s official samples. Draw what you’d like to see Remember that thing called “pen”? Grab it! All along your Android app project you’ll quickly find that putting things on paper first will help, whether you go for wireframes or simple UI ideas. Draw every single step to remember it and to make sure each one makes sense overall. Tip 3: Success relies on good organization For more convenience, we recommend you tear down basic Android application development projects according to a pre-defined timeline. In this case, we’re talking about a 30-day project. But no matter how much time it is, it usually goes by these 5 steps: Ideation (Day 1 – 2) Remember “Tip 2” right above? This is where you put it to work ! Take as much time as necessary to find the perfect idea. We recommend 2 days. Don’t rush as it will define your whole project! Preparation (Day 3) This is where you choose your IDE (Integrated Development Environment), in other words the all-in-one software that will provide everything you need to develop your app. We recommend using Android Studio. This is where you’ll also gather what we call “media assets”. Simply put, they are all the files that will be found in your app: images, logos, audio files, video files… anything! The good news is you don’t necessary have to create these from scratch! There are already awesome ones existing at Android development resources. Creation (Day 4 – 21) We’re not going to lie. This step is the toughest, especially if you’re new to Android development. Here you have to build your app layout and most particularly write the code that will bring it to life. If you choose to implement specific design elements, make sure it is compliant with Google’s Material Design guidelines. Once you’re done, compile your source code into an APK file. Testing & adjustments (Day 22 – 28) Don’t consider your project over until you’ve personally tried and tested every single part of it! As a first step, install your APK file and run it on your own Android hardware device. Then include an Android emulator in your mobile testing strategy and perform advanced tests targeted on specific devices and Android versions. Publication (Day 29 – 30) After you are done, you can ship your app to Google’s Play Store! This step is optional but recommended: it allows you to deliver your app through a reliable source visited by a good amount of people. Head up to “Get Started with Publishing” from the official Android documentation for more info on this. Tip 4: Patience is the name of the game During your Android app development project, don’t be too harsh on yourself, whatever the problem is. Being an Android developer is a full-time job that requires a lot of hard and soft skills. By the way, patience and dedication are definitely part of them ? Don’t fear failure Failure is good. Failure is what will make you learn and evolve all along your project. Don’t reject it, embrace it and accept it to finally witness how much wiser you become when your app is done. Be patient Building an app is time-consuming. As explained above being an Android developer is a full-time job, so don’t expect it to happen overnight. If you’re looking for fast positive results then you might want to consider something else. Seek help There’s absolutely no shame in it! If nobody around is able to help, you might want to consider Stack Overflow. In any case there’s absolutely no problem in contacting us. We don’t bite! Be patient Again. Bottom line Android app

Android Development, Droidcon, Event

Join us at Droidcon SF 2016 ($100 off)

/

  We are proud to announce that we will soon attend the #1 Android Developer conference in America! At Droidcon SF (March 17, 9:00 AM – March 18, 6:00 PM), our teams will be happy to share with you insights on our flagship product Genymotion – the best-in-class Android emulator for developers – and a few tips on what we plan for the future… (☁️) Sponsoring an event has its advantages: As official sponsor of the event, we take this opportunity to share with you a $100 discount (yep). → Simply enter the code Genymobile ← You can use it whenever you want (before the event of course) and it’s usable for Regular & Last Minute tickets. See you at Booth 12! REGISTER NOW Location

Android Development, Dev Tips, Genymotion, Gradle Plugin

The build.gradle ubiquity

/

How to manage your build configuration, from the developer platform to the CI Before starting this article, I want to thank Mark Vieira, Gradle core developer, and the publishing teams from Gradle and Genymobile for their review and assistance. TL;DR The syntax apply from: allows you to inject Gradle scripts from files. You can check the current defined environment variables to know the current build environment (developer platform or continuous integration server) and apply the corresponding files. All parameters you don’t want to write in clear can be defined outside your Gradle files using Gradle Properties (via gradle.properties files, environment variables or command line arguments) and used as variables into Gradle files. Some of these methods can be controlled directly from the continuous integration management interface.   Introduction Two years ago, at Genymobile, we were all very enthusiastic about one of Google I/O announcements: Gradle is going to be the future-new-official-but-still-young build system for Android. A few weeks later, when we measured its potential power, all Android app developers were waiting impatiently for a stable and fully usable duet “Android Studio & Gradle”. Our first observation after adopting Gradle was that we were living a real professionalization of the tools provided by Google. In short, Gradle was as powerful as the well-known Maven, with a very light boilerplate for the configuration and the customization of the build. It also had this very nice wrapper that really made the adoption enjoyable. Gradle led to a better industrialization of the Android development, with an official support by the Android SDK team. Now we all implement automated tests, don’t we? We take seriously into account static analysis tools, right? And we run all of them on our continuous integration server, sure! Thanks to the build.gradle files of our projects, we can now control all tasks we run automatically. But sometimes, some tasks must behave differently whether they are run on our development environment or on a continuous integration server (also named CI).   An example of the problem At Genymobile, we develop Genymotion, an Android emulator. We worked hard to make it the perfect emulator for Android developers and we recently released a Gradle plugin. This plugin allows us to declare, in the build.gradle script, the Genymotion devices to launch before running the tests. Let’s imagine that on our computer, we want to run tests on an emulated phone (Nexus 5) and an emulated tablet (Nexus 9). Then we add this block to the build.gradle file: genymotion {    devices {        Nexus5 {            template “Google Nexus 5 – 5.1.0 – API 22 – 1080×1920”        }        Nexus9 {            template “Google Nexus 9 – 5.1.0 – API 22 – 2048×1536”        }    } } On the CI server side, we want to test more devices. So we add a Galaxy S3, an S4, a Nexus 7 and a Nexus 10, with different Android versions: genymotion { devices {        Nexus5 {            template “Google Nexus 5 – 5.1.0 – API 22 – 1080×1920”        }        Nexus9 {            template “Google Nexus 9 – 5.1.0 – API 22 – 2048×1536”        }        S4 {            template “Samsung Galaxy S4 – 4.3 – API 18 – 1080×1920”        }        S3 {            template “Samsung Galaxy S3 – 4.2.2 – API 17 – 720×1280”        }        Nexus7 {            template “Google Nexus 7 – 4.1.1 – API 16 – 800×1280”        }        Nexus10 {            template “Google Nexus 10 – 4.4.4 – API 19 – 2560×1600”        }    } } Those additional configurations offer a better coverage for the instrumented tests and they will all be run automatically. Now, we have two pieces of script, supposed to be in the same file at the same time. Let’s see how we can handle this problem.   Apply From a File The best way to solve this is to put both scripts into separate files: genymotion-dev.gradle will be applied when the build will be running on the developer’s computer; genymotion-ci.gradle will run on the CI. They can be both be applied using the apply from: syntax, as shown below: build.gradle apply from: “$rootDir/genymotion-dev.gradle” But how can the build system decide what files to apply? For this, it needs to know whether the build is running on the CI or on a dev environment, and it is pretty simple. Each time your continuous integration server launches a job, it opens a worker and it injects some environment variables. These can be used by the running scripts to get information about the context of the build. They are also convenient to know whether the Gradle script is executed on a CI or not. You can get the list of these default values on each CI documentation. Here are examples for Jenkins and Teamcity. Some people would prefer to avoid the build system configuration to depend on the CI installed, allowing to switch easily from a server to another. To solve this, you can define an environment variable yourself for all your jobs instead of using the one from your server. On Jenkins, you can do this using EnvInject plugin. On TeamCity, you can use Build Parameters. We just need to test that this environment variable is set to determine whether the build is running on the CI and then apply the dedicated Gradle file: build.gradle def isCiServer = if(System.getenv().containsKey(“IS_CI_JOB”)) if(isCiServer) apply from: “$rootDir/genymotion-ci.gradle” else apply from: “$rootDir/genymotion-dev.gradle”   The path as a URL As a bonus, Gradle adds a nice feature to the  apply from  instruction: we can use a URL. Instead of storing the file in a specific place on the CI server or on the repository, we can put it behind a HTTP server like this: apply from: “http://ci.mycompagny/genymotion-ci.gradle”   Managing Local Parameters Now that the build setup is defined, we are almost done for the build system configuration. However, in most cases, you still need to configure settings related to the computer running the build. These settings can be related to a specific local path, credentials, or any other specificity of the

Scroll to Top

Select Product Portal

SaaS Platform

Access to our SaaS solution and use virtual machines in the cloud on any web browsers.

sign in saas

Or

Or

Desktop Platform

Access to manage your Genymotion Desktop licenses, your invoices and account information.

sign in desktop

How to get a quote for multiple Business Licenses?

  1. You need a Genymotion Desktop account. If you haven’t one yet, you can create it here.
  2. After creation and activation, or if you already have an account, follow this link.
  3. Add the number of desired licenses to your shopping cart and click “Continue to Billing”
  4. Add a shipping address, or select one if you already created one.
  5.  In the next page, click “Get a quote”:
    Payment details
  6. A quote will be automatically generated in PDF format.

Genymotion Device Image for Cloud providers
- Private Offer -

Genymotion Device On-premise
- Contact Us -

Genymotion SaaS
- Increase Maximum Simultaneous devices -

Genymotion SaaS Enterprise Plan
- Get a Quote -

Genymotion SaaS Premium Plan
- Get a Quote -

Personal Use - Free

Genymotion Desktop for personal use is not suitable for trial or POC: you will not get any assistance and some features will be disabled. If you have already selected “personal use” and wish to get a trial license, please contact our Sales at [email protected].

Technical support is not available with Genymotion Desktop free edition for personal use. For more details, please refer to Genymotion conditions of use (Personal Use).

The following features are not available in personal use mode:

  • Latest available Android version
  • Quick boot
  • Camera and Media injection widgets
  • Network profiles
  • gmtool full commands
  • GPS route simulation

Follow these steps to get Genymotion Desktop and activate personal use mode:

  1. Go to the Download page and get the latest version for your system.
  2. Follow the instructions from Genymotion Desktop quickstart guide to install Genymotion Desktop.
  3. Launch Genymotion and click CREATE to create an account. You should receive an activation email within an hour. If not, make sure to check your spam.
  4. After activating your account, return to Genymotion and log in with your credentials.
  5. Select personal use when prompted.
  6. Read Genymotion Desktop quickstart guide carefully to setup Genymotion for your needs.

Indie Plan Application Form

This plan is strictly reserved to individual workers (freelancers, self-employed).

Contact Sales
- Premium Plan -

Educational Plan Application Form

The Educational plan is restricted to:

  • schools, teachers or students who wish to use Genymotion Desktop for tuition
  • students who wish to use Genymotion Desktop for a school project

It is subject to valid proof (student card, teacher card, etc.)

Select a Cloud provider Marketplace