Android studio application does not launch on the emulator. We assemble and launch the project

Description

• #include - connect the log, for which we even added the library ( ldLibs "log")
• #include - for std::string, which we use to check for the presence of STL.
  #include "myapp.h" - we include our header file.
  JNIEXPORT jstring JNICALL Java_com_example_markedone_myapp_FullscreenActivity_stringFromJNI(JNIEnv* env, jclass clazz) ( ... ) - implement the function declared in "myapp.h".
  std::string tag("GREETING"); std::string message("Hello from C++!"); - create lines for output to the log.
  __android_log_print(ANDROID_LOG_INFO, tag.c_str(), "%s", message.c_str()); - output to log. Please note that you need to specify 4 parameters: the type of message in the log, the tag, the string format, and, finally, the message itself.
  std::string jniMessage("Hello from JNI!"); - the string that we will pass to Java.
  return env->NewStringUTF(jniMessage.c_str()); - return value, using JNIEnv we create a jstring from a C-string. Note that we don't need a construct like (*env)-> since we're writing in C++, not C.

7. Add a native function call from Java

File contents

package com.example.markedone.myapp; import com.example.markedone.myapp.util.SystemUiHider; import android.annotation.TargetApi; import android.app.Activity; import android.os.Build; import android.os.Bundle; import android.os.Handler; import android.view.MotionEvent; import android.view.View; /** * An example full-screen activity that shows and hides the system UI (i.e. * status bar and navigation/system bar) with user interaction. * * @see SystemUiHider */ public class FullscreenActivity extends Activity ( /** * Whether or not the system UI should be auto-hidden after * (@link #AUTO_HIDE_DELAY_MILLIS) milliseconds. */ private static final boolean AUTO_HIDE = true; /* * * If (@link #AUTO_HIDE) is set, the number of milliseconds to wait after * user interaction before hiding the system UI. */ private static final int AUTO_HIDE_DELAY_MILLIS = 3000; /** * If set, will toggle the system UI visibility upon interaction. Otherwise, * will show the system UI visibility upon interaction. */ private static final boolean TOGGLE_ON_CLICK = true; /** * The flags to pass to (@link SystemUiHider#getInstance). */ private static final int HIDER_FLAGS = SystemUiHider.FLAG_HIDE_NAVIGATION; /** * The instance of the (@link SystemUiHider) for this activity. */ private SystemUiHider mSystemUiHider; @Override protected void onCreate(Bundle savedInstanceState) ( super.onCreate(savedInstanceState); setContentView(R.layout .activity_fullscreen); final View controlsView = findViewById(R.id.fullscreen_content_controls); final View contentView = findViewById(R.id.fullscreen_content); // Set up an instance of SystemUiHider to control the system UI for // this activity. mSystemUiHider = SystemUiHider.getInstance(this, contentView, HIDER_FLAGS); mSystemUiHider.setup(); mSystemUiHider .setOnVisibilityChangeListener(new SystemUiHider.OnVisibilityChangeListener() ( // Cached values. int mControlsHeight; int mShortAnimTime; @Override @TargetApi(Build.VERSION_CODES.HONEYCOMB_MR2) public void onVisibilityChange(boolean visible) ( if (Build.VERSION.SDK_INT > = Build.VERSION_CODES.HONEYCOMB_MR2) ( // If the ViewPropertyAnimator API is available // (Honeycomb MR2 and later), use it to animate the // in-layout UI controls at the bottom of the // screen. if (mControlsHeight == 0) ( mControlsHeight = controlsView.getHeight(); ) if (mShortAnimTime == 0) ( mShortAnimTime = getResources().getInteger(android.R.integer.config_shortAnimTime); ) controlsView.animate() .translationY(visible ? 0: mControlsHeight).setDuration(mShortAnimTime); ) else ( // If the ViewPropertyAnimator APIs aren't // available, simply show or hide the in-layout UI // controls. controlsView.setVisibility(visible ? View.VISIBLE: View.GONE); ) if (visible && AUTO_HIDE ) ( // Schedule a hide(). delayedHide(AUTO_HIDE_DELAY_MILLIS); ) ) )); // Set up the user interaction to manually show or hide the system UI. contentView.setOnClickListener(new View.OnClickListener() ( @Override public void onClick(View view) ( if (TOGGLE_ON_CLICK) ( mSystemUiHider.toggle(); ) else ( mSystemUiHider.show(); ) ) ); // Upon interacting with UI controls, delay any scheduled hide() // operations to prevent the jarring behavior of controls going away // while interacting with the UI. findViewById(R.id.dummy_button).setOnTouchListener(mDelayHideTouchListener); ) @Override protected void onPostCreate(Bundle savedInstanceState) ( super.onPostCreate(savedInstanceState); // Trigger the initial hide() shortly after the activity has been // created, to briefly hint to the user that UI controls // are available. delayedHide(100); ) /** * Touch listener to use for in-layout UI controls to delay hiding the * system UI. This is to prevent the jarring behavior of controls going away * while interacting with activity UI. */ View.OnTouchListener mDelayHideTouchListener = new View.OnTouchListener() ( @Override public boolean onTouch(View view, MotionEvent motionEvent) ( if (AUTO_HIDE) ( delayedHide(AUTO_HIDE_DELAY_MILLIS); ) return false; ) ); Handler mHideHandler = new Handler(); Runnable mHideRunnable = new Runnable() ( @Override public void run() ( mSystemUiHider.hide(); ) ); /** * Schedules a call to hide() in milliseconds, canceling any * previously scheduled calls. */ private void delayedHide(int delayMillis) ( mHideHandler.removeCallbacks(mHideRunnable); mHideHandler.postDelayed(mHideRunnable, delayMillis); ) )

Now we, in general, can already call our function. If you, like me, chose FullscreenActivity, then we have a Dummy Button that essentially does nothing. And we even already have a touch listener, although not the best (it will be called many times while the finger is on the screen), but in order not to produce unnecessary code, we use it.

First, let's add to the import list:
import android.widget.Button;
so that you can work normally with the button.

Let's find the following code:
View.OnTouchListener mDelayHideTouchListener = new View.OnTouchListener() ( @Override public boolean onTouch(View view, MotionEvent motionEvent) ( if (AUTO_HIDE) ( delayedHide(AUTO_HIDE_DELAY_MILLIS); ) return false; ) );
and add a few lines before return false .
View.OnTouchListener mDelayHideTouchListener = new View.OnTouchListener() ( @Override public boolean onTouch(View view, MotionEvent motionEvent) ( if (AUTO_HIDE) ( delayedHide(AUTO_HIDE_DELAY_MILLIS); ) final String message = stringFromJNI(); final Button button = (Button )findViewById(R.id.dummy_button); final String actualText = button.getText().toString(); if(message.equals(actualText)) ( button.setText("Dummy Button"); ) else ( button.setText (message); ) return false; ) );

Description of the added code

• final String message = stringFromJNI(); - we get a string from C++. Calling a native method is what it all started for.
• final Button button = (Button)findViewById(R.id.dummy_button); - find the button object.
• final String actualText = button.getText().toString(); - pull out the current button text.
• if(message.equals(actualText)) - compare the string obtained from C++ with the text of the button.
  • button.setText("Dummy Button"); - if they are the same, change the text of the button to Dummy Button.
  • button.setText(message); - if they differ, then we change them to text obtained from C++.

Full class listing of the modified class

package com.example.markedone.myapp; import com.example.markedone.myapp.util.SystemUiHider; import android.annotation.TargetApi; import android.app.Activity; import android.os.Build; import android.os.Bundle; import android.os.Handler; import android.view.MotionEvent; import android.view.View; import android.widget.Button; /** * An example full-screen activity that shows and hides the system UI (i.e. * status bar and navigation/system bar) with user interaction. * * @see SystemUiHider */ public class FullscreenActivity extends Activity ( static ( System.loadLibrary("myapp"); ) private static native String stringFromJNI(); /** * Whether or not the system UI should be auto-hidden after * (@link #AUTO_HIDE_DELAY_MILLIS) milliseconds. */ private static final boolean AUTO_HIDE = true; /** * If (@link #AUTO_HIDE) is set, the number of milliseconds to wait after * user interaction before hiding the system UI. */ private static final int AUTO_HIDE_DELAY_MILLIS = 3000; /** * If set, will toggle the system UI visibility upon interaction. Otherwise, * will show the system UI visibility upon interaction. */ private static final boolean TOGGLE_ON_CLICK = true; /** * The flags to pass to (@link SystemUiHider#getInstance). */ private static final int HIDER_FLAGS = SystemUiHider.FLAG_HIDE_NAVIGATION; /** * The instance of the (@link SystemUiHider) for this activity. */ private SystemUiHider mSystemUiHider; @Override protected void onCreate(Bundle savedInstanceState) ( super.onCreate(savedInstanceState); setContentView(R.layout.activity_fullscreen); final View controlsView = findViewById(R.id.fullscreen_content_controls); final View contentView = findViewById(R.id.fullscreen_content); // Set up an instance of SystemUiHider to control the system UI for // this activity. mSystemUiHider = SystemUiHider.getInstance(this, contentView, HIDER_FLAGS); mSystemUiHider.setup(); mSystemUiHider .setOnVisibilityChangeListener(new SystemUiHider.OnVisibilityChangeListener() ( // Cached values. int mControlsHeight; int mShortAnimTime; @Override @TargetApi(Build.VERSION_CODES.HONEYCOMB_MR2) public void onVisibilityChange(boolean visible) ( if (Build.VERSION.SDK_INT > = Build.VERSION_CODES.HONEYCOMB_MR2) ( // If the ViewPropertyAnimator API is available // (Honeycomb MR2 and later), use it to animate the // in-layout UI controls at the bottom of the // screen. if (mControlsHeight == 0) ( mControlsHeight = controlsView.getHeight(); ) if (mShortAnimTime == 0) ( mShortAnimTime = getResources().getInteger(android. R.integer.config_shortAnimTime); ) controlsView.animate() .translationY(visible ? 0: mControlsHeight) .setDuration(mShortAnimTime); ) else ( // If the ViewPropertyAnimator APIs aren't // available, simply show or hide the in-layout UI // controls. controlsView.setVisibility(visible ? View.VISIBLE: View.GONE); ) if (visible && AUTO_HIDE ) ( // Schedule a hide(). delayedHide(AUTO_HIDE_DELAY_MILLIS); ) ) )); // Set up the user interaction to manually show or hide the system UI. contentView.setOnClickListener(new View.OnClickListener() ( @Override public void onClick(View view) ( if (TOGGLE_ON_CLICK) ( mSystemUiHider.toggle(); ) else ( mSystemUiHider.show(); ) ) ); // Upon interacting with UI controls, delay any scheduled hide() // operations to prevent the jarring behavior of controls going away // while interacting with the UI. findViewById(R.id.dummy_button).setOnTouchListener(mDelayHideTouchListener); ) @Override protected void onPostCreate(Bundle savedInstanceState) ( super.onPostCreate(savedInstanceState); // Trigger the initial hide() shortly after the activity has been // created, to briefly hint to the user that UI controls // are available. delayedHide(100); ) /** * Touch listener to use for in-layout UI controls to delay hiding the * system UI. This is to prevent the jarring behavior of controls going away * while interacting with activity UI. */ View.OnTouchListener mDelayHideTouchListener = new View.OnTouchListener() ( @Override public boolean onTouch(View view, MotionEvent motionEvent) ( if (AUTO_HIDE) ( delayedHide(AUTO_HIDE_DELAY_MILLIS); ) final String message = stringFromJNI(); final Button button = (Button)findViewById(R.id.dummy_button); final String actualText = button.getText().toString(); if(message.equals(actualText)) ( button.setText("Dummy Button"); ) else ( button .setText(message); ) return false; ) ); Handler mHideHandler = new Handler(); Runnable mHideRunnable = new Runnable() ( @Override public void run() ( mSystemUiHider.hide(); ) ); /** * Schedules a call to hide() in milliseconds, canceling any * previously scheduled calls. */ private void delayedHide(int delayMillis) ( mHideHandler.removeCallbacks(mHideRunnable); mHideHandler.postDelayed(mHideRunnable, delayMillis); ) )

17. We assemble and launch the project

Working on a real device

Outputting a message to the log

Conclusion

It is also clear that support for NDK is still damp, but there is movement in this direction. I really hope that they will eventually provide full support for C++ development.

P.S. No C++ code debug has been found yet.

Tags:

• android studio
• gradle
• android ndk
• android

Android - free operating system, based on Linux with a Java programming interface.

If you have a desire to develop applications for phones under Android control, then you need to carefully prepare and install all the necessary tools for the job.

Installing Android Studio

Articles are often reworked as some things quickly become outdated. But I can’t keep track of everything, so you’ll have to figure things out on your own if you encounter differences.

It is important to understand that the application itself is written in Java (and now also in Kotlin), and the development environment is chosen to suit your taste. What can be done in Android Studio (or its big brother IntelliJ IDEA), can be done in Eclipse and other editors. Although since 2016 official support Eclipse has stopped.

You can download the installation package for the studio from the page https://developer.android.com/studio/index.html

The installation itself should not cause any problems. Installation package includes the required minimum. Sometimes you need to launch Android SDK Manager and check for new SDK versions through the menu Tools | Android | SDK Manager:

Over time, you will figure out for yourself what you need to install and what is not necessary. At first, agree to the terms that the manager offers you by default.

A user from Bulgaria wrote that Win64 requires administrator rights when installing or updating. Keep in mind. On a clean system it didn’t ask me anything.

In studio version 2.3 (maybe earlier) the OpenJDK package is installed, which is an alternative to the JDK from Oracle. There is a note in the studio settings that OpenJDK is the recommended option, although you can specify the path to the standard JDK. In any case, you will have Java 8 no matter which option you choose.

Creating emulators

To debug applications, we use a phone emulator - a virtual machine on which our application will run. You can also use a real device.

Now, at the time of installation, the studio creates one device for the emulator. If this is not the case, you can always install manually. You can also add other devices under different versions Android, screen resolutions, etc.

To create a phone emulator, select from the menu Tools | Android | AVD Manager. When you launch it for the first time, a wizard dialog box will appear.

Press the button Create a virtual device and in a new window we see a set of possible emulators, including for watches. Download the necessary emulators. For starters, one emulator is quite suitable.

Enter any friendly name, for example, Android4. Choose the required version Android, screen size, etc.

If necessary, you can create emulators for each OS version and check the program for functionality. The remaining settings can be left unchanged. You can always go back to the settings and edit again. It is often recommended to use the option Use Host GPU to take advantage of opportunities GPU. This increases the speed of the emulator. Press the button OK.

Added emulators will be stored in the emulator manager.

If you have created several emulators, then select the one you need and press the button with a green triangle to launch the emulator. The pencil icon allows you to edit settings. But usually the emulator is not launched separately. When you launch the application, the studio itself will offer to launch the emulator.

remember, that virtual machines by default they are saved in the user's folder, and the folder paths should not contain Russian characters to avoid problems.

If you still fall into this trap, then I will give a link to change the user folder to English: http://www.cherneenet.ru/lokalnaj_zapis.html (thanks to reader Evgeny Stepanov for the hint). You can also correct the ini file and write the path to the virtual device in such a way that there are no Russian letters in the path (accordingly, the *.avd file itself also needs to be moved to another location).

Depending on the power of your computer, you may need to wait a little while for the emulator to load first. The Intel emulator loads much faster. You can also use a real phone. I usually use old phone and an emulator for new versions of Android.

Testing on a real device

It is advisable to test the final version of the application on a real device. Starting with Android 4.4, you need to activate developer mode on your device (tablet, phone, watch). To do this, go to Settings, open the “About phone” page and click seven times on the line with the build number Build number. After this, a new item will appear in the settings For developers or something like that if the manufacturer uses its own shell.

Once you open the developer page, you need to enable USB debugging. I also include the option Don't turn off the screen. Some devices require a separate driver to be installed; look for information on the manufacturer's website.

Working in terminal mode

Studio also allows you to run command line commands in separate window. For convenience, you should slightly customize the system for yourself.

I have a non-localized one installed Windows version, so some of the points will be given in English.

For Windows 7/8 open Control Panel | System, press the button Advanced System Settings. In the new window, click the button Environment Variables.

Find the variable Path on the list System variables

Click on the button Edit to edit a variable. Add a semicolon at the end of the line and then specify the folder paths platform-tools And tools, which are included in the SDK. In my case it turned out like this:

;D:\Android\SDK\platform-tools;D:\Android\SDK\tools

Close all windows (better to reboot). Check if everything is working correctly. Run command line and enter the command:

Echo %path%

You should see a line listing all the paths included in the variable Path, including yours.

For the following check, enter the command:

A list of command parameters will appear.

Also try the command:

The SDK Manager window will open.

If you wrote something wrong, the commands will not be recognized and you need to correct the error in writing the path.

Now let's do these operations in the studio itself. Launch studio and open the project (see next lesson). There is a tab at the bottom of the status bar. Switch to it. In a terminal window, enter either of the previous two commands.

Documentation

The latest documentation can always be found at developer.android.com. If you have problems with the Internet, then in the subfolder /docs in your folder installed Android SDK, you can find its local copy (if you did not refuse to install it).

Cat installation

This point is not mandatory, but as practice shows, having a cat allows you to achieve quick results V learning Android. You can pick up a cat on the street, adopt it from a shelter, or buy it through an advertisement. Any kind will do - red, striped, black. The cat should be washed, fed and placed nearby. Your karma is growing at this time and the process of mastering the material will go faster.

Preparations for development have been completed. Now the next step is creating the first application.

Sit back and fasten your seat belts - an exciting journey into the world of Android application development awaits us.

When you begin to master development for any platform, you are sure to immediately come across many pitfalls that are invisible at first glance. Most of them will be related to the coding process itself: inconsistencies in the API, hidden functions, limitations, special programming style for the platform. There are also stones that lie a little further away: testing and automatic optimization, creating clipart and icons, receiving automatic crash reports. Inexperienced Android developers run the risk of getting both their feet cut.

In this article, we'll look at Android development issues in the context of utilities and tools. We will get rid of the need to connect the smartphone using a cable during testing and debugging on the device, we will split the application into Lite versions and Pro, we will build into it a mechanism for automatically generating and sending crash reports to the server, automate testing, obfuscate and optimize the code, and also create an icon and all the necessary resources for the application in a few minutes. Go.

1. Slow emulator

So, you've sketched out your first application, and it's time to launch it and test its functionality. For this purpose, the Android SDK includes an emulator. For a long time he was reproached for being slow, but with the release of Android Studio 2.0 the situation has improved significantly - the x86 version of the emulator received hardware acceleration, so now it works faster than real devices. In addition, it has a convenient graphical interface with which you can simulate calls, SMS, change GPS data and network failures, that is, everything for which you previously had to use command line tools.

Therefore, if you haven't upgraded yet, I highly recommend doing so, not to mention switching from Eclipse. And be sure to select the x86 version of the emulator in the AVD manager; the ARM version does not support hardware acceleration.

2. Smartphone on a leash

The second stage is testing on a real device. Everything is simple here: you connect your smartphone via USB, install the drivers, enable debugging mode in the developer settings, after which the device appears in the list of applications available for installation (next to the emulator). The only problem is that in this case the device must be kept connected to the PC using a cable, and if this is your main smartphone that receives calls and messages, then there is no need to talk about convenience.

Luckily, Android Studio (more specifically, the ADB utility it uses to communicate with the device) supports networking. But this function still needs to be activated. If you have a rooted smartphone, then you're in luck: you can enable network debugging using the WiFi ADB application. Sequencing:

1. Install WiFi ADB, launch it, enable network mode using the switch and remember the IP address.
2. Launch Android Studio.
3. Open the console, go to the directory with the installed SDK, then go to platform-tools and run next command:

   $ adb connect IP address

Now, if you try to build and launch the application, you will also see your smartphone in the list of devices. Those who are not root can restart ADB in network mode, after connecting it with a cable. This is done like this:

1. We connect the smartphone and install drivers.
2. Enable debugging mode in the developer settings.
3. Open the console, go to the SDK/platform-tools directory and run the following command:

   $ adb tcpip 5555

4. Connect to the smartphone via the network:

   $ adb connect IP address

The IP address can be found through the settings: “About phone (About tablet) → General information", item "IP address".

3. Libraries

Okay, your hack that you threw together in half an hour seems to be working, and it’s time to turn it into a real application with a beautiful interface and widgets for your desktop. At this stage, you will probably need external libraries that implement various interface concepts, programming patterns and communication with external services. And if everything is clear with the latter (you need an SDK for Dropbox - you open the portal for developers and follow the instructions), then with the rest it is already more difficult. Where to look for them and which libraries are better?

The most comprehensive library catalog is Android Arsenal. There you will find almost everything you need. Available convenient search and sorting by rating, for each library there are instructions on how to connect it to your project, including using the standard Gradle build system for Android: just add the repository to the project’s build.gradle file and specify the library in the list of dependencies.

You can find an excellent list of must-have libraries on this page. On my own behalf, I’ll add that in the first stages you should immediately study Dagger 2, RxJava And Retrofit. As you become an advanced developer, you will come to use these libraries one way or another.

4. Icons and clipart

Finally, after days or weeks, a full-fledged application begins to emerge. But there is still no graphic material: the icon is standard, in the shape of a green robot, instead of clipart there are placeholders. Obviously, without graphics there is no point in going to the markets, but paying for an icon for your first application is also stupid. What to do?

In fact, the icon can be generated. There is a wonderful web service Android Asset Studio, with which in just a couple of minutes you will get a beautiful icon in all possible resolutions. As a basis, you can take a picture you prepared, simply write text, or, best of all, choose from the clipart provided by the service. You can also set the icon style (round, square, etc.) iOS style...), color, adjust shadows and other parameters. As a result, you will have the archive ic_launcher.zip at your disposal, which must be deployed to the AndroidstudioProjects/APP_NAME/app/src/main/res directory. Be sure to create a web icon by clicking on the “Generate web icon” button. You'll need it.

The same service allows you to create icons for the ActionBar and status bar. The principle is approximately the same, I will only say that icons with an indentation of 15% from the edges look best in the status bar.

In addition, you will need the so-called Feature Image. This is a special picture that Play Market and other application stores are used as a bar at the top of the screen (when you open the application page on a smartphone). It can be generated using another service. To take screenshots, you can use the official service from Google. It creates a smartphone frame around the screenshot.

5. Crash reports

The application is ready, there is an icon, the interface is convenient, the code is high-quality. It's time for testing, and the first thing you do is send the application to your friends and acquaintances. But here’s the problem: for some of them the application crashes, but for you everything works fine, and you cannot repeat the actions that led to the crash. What should you do, ask your friends to send you a logcat listing?

No, we need a crash reporting system. There are a huge number of them, and they all implement the same principle of operation: a small library is connected to the application, which, at the moment of the fall, records the stack trace and other data about the fall and sends it to the server, and then a special web interface creates beautiful images based on them and visual reports.

One of the most popular such systems is Fabric, but I recommend looking towards Splunk MINT: it is free, simple and easily integrated into the application (just add one line of code). To start using it, you need to connect the SDK to the project; this can be done using the same Gradle. Open the build.gradle file (the one that applies to the application, not the entire project) and add the following lines:

Repositories ( maven ( url "https://mint.splunk.com/gradle/" ) ) dependencies ( compile "com.splunk.mint:mint:5.0.0" )

After this, Splunk MINT will show you the line of code that needs to be inserted into the code:

Continuation is available only to subscribers

Option 1. Subscribe to Hacker to read all materials on the site

Subscription will allow you to read ALL paid materials on the site within the specified period. We accept payment bank cards, electronic money and transfers from mobile operator accounts.

Let's create an android emulator for testing while writing applications. Last time we configured the SDK in the Android Studio environment, updated versions and Android OS packages. However, you can use a real device: phone, tablet.

Creating an Android emulator, setting up an Android emulator

Sometimes this is justified, for example if you are creating android apk for myself. On the phone, enable developer mode in the menu, connect the device via USB cable to the computer, and during assembly the application will be installed on the smartphone, test for health. You can test via WIFI, via adb, I personally installed it on my phone A.D.B. Wireless Pro 1.9.2,

when starting I chose the type wifi connections, and on the computer in total commander, in the plugins section I launched A.D.B. ,

specified ip and port,

and connected.

Further Android Studio I installed the tested apk on my phone via wifi. It is possible through the console, but “this is not our method.” Why is it needed? Android emulator , you ask? And then, there’s just a whole zoo of Android versions and device models, and there are more and more every day. Imagine if you need to write for an “old” model of phone or tablet, but you don’t have it in stock, don’t buy it. This method is suitable for large companies professionally developing applications for Android, with a budget tending to infinity. We, from simple, small-scale households, will use an emulator; to a certain extent, it provides the opportunity to select versions and models of androids, although it eats up a lot of memory..

Let's launch Android Studio , V top menu click Tools->Android->AVD Manager,

in it, click the button at the bottom with the green plus Create Virtual Device...

New virtual device

In Category, select Phone, it seems to be the default there, for example emulator we will create in the image and likeness of Galaxy Nexus, click Next

Android Studio , based on the images installed on my system, Marshmallow version 6.0 was recommended to me,

since I haven’t downloaded Android N 7.0, however, this is enough for tests

on the third tab Other Images, you can select a different version, you can experiment if you want) click Next

In the next step you can rename our virtual device , change screen size, android version,

although you can leave it that way.

Of greater interest is the button additional settings Show Advanced Settings

by clicking on which the camera and network settings elements will be shown, you can adjust the volume random access memory, the size of the SD CARD is especially important regarding memory, I left 1 GB, you can put 512 MB if the RAM on your PC is not enough.

Click Finish, after some thought when creating a new one AVD , you will see something new in the manager virtual device .

In the right corner there are three buttons: a green arrow - start the emulator, a green pencil - change device properties, and a black down arrow opens an additional drop-down menu where you can clean, clone and delete the device.

Since we are writing for Android, to run applications we will need a smartphone running it, but, of course, there is an emulator and you have already downloaded it along with Android Studio. True, it does not work right out of the box and you will have to configure it a little. In this article we will do just that.

Virtual Android devices

Virtual Android devices are necessary for testing applications without installing them on real devices; for short they are called AVD (from English Android Virtual Device). They can be configured to emulate various hardware characteristics such as different sizes screen, memory capacity, presence or absence of cameras, support GPS navigation or accelerometer. At standard installation Android Studio installs a set of default device templates, mainly Nexus phones, which allow you to create your own AVDs based on them. You can also download additional templates or create your own to match any Android device in terms of processor type, memory size, pixel density and screen size.

When launched, the AVD appears as a window emulating the device. For example, photo below.

Creating an AVD

New AVDs are created and managed in Android Virtual Device Manager, which can be worked with both in the command line and in a convenient graphical interface. You can launch the manager from Android Studio by selecting the menu option Tools -> Android -> AVD Manager. In this article, we will not consider working through the command line.

After launching AVD Manager, click the "Create a virtual device" button, the virtual device configuration window will appear.

For example, let's create a Nexus S emulator. We choose it because it has a fairly small screen, which means that when the virtual device starts, the processor will be less loaded. We don't need it at all big screen for Hello World, later you, of course, can create your own instance and work with configurations that are closer to reality.

As you can see, there are several tabs for different categories of devices, we need a second one called Phone. On it, select the first line, Nexus S, click Next and wait for the installation to complete. After this, the settings window will appear:

Here you can set the name and various settings. Let's not touch anything and just click Finish. This completes the creation of the new AVD.

Launching the AVD

To launch the emulator, simply click on the green triangle opposite its name on the main page of AVD Manager. The launch, especially the first one, takes quite a long time. To speed up subsequent startups, uncheck "Use Host GPU" and check "Store a snapshot for faster startup".

Snapshot is something like a snapshot of the emulator state, which is loaded when the virtual device starts and allows you to reduce startup time to a few seconds. You can enable this feature only if you disable the "Use Host GPU" option.

Also, to speed up development, you can not turn off the emulator when working in Android Studio, so that every time you launch the application there is no need to wait for it to launch; the studio will understand that it needs to be launched already in a running emulator.

Conclusion

Now we have everything we need to write our first Android application. In the next article we will launch it.