The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
Now, let us get you set up with the pieces and parts necessary to build an Android app.
NOTE: The instructions presented here are accurate as of the time of this writing. However, the tools change rapidly, and so these instructions may be out of date by the time you read this. Please refer to the Android Developers Web site for current instructions, using this as a base guideline of what to expect.
The Android tools include an emulator, a piece of software that pretends to be an Android device. This is very useful for development — not only does it mean you can get started on Android without a device, but the emulator can help test device configurations that you do not own.
There are two types of emulator: x86 and ARM. These are the two major types of CPUs used for Android devices. You really want to be able to use the x86 emulator, as the ARM emulator is extremely slow.
However, to use the x86 emulator, your development machine must have things set up properly first. Linux users need KVM, while Mac and Windows users need the “Intel Hardware Accelerated Execution Manager” (a.k.a., HAXM).
Also, this only works for certain CPU architectures, ones that support virtualization in hardware:
Those virtualization extensions must also be enabled in your device’s BIOS, and other OS-specific modifications may be required.
Also, at least for newer API levels, your CPU must support SSSE3 extensions, though the details of this requirement are not documented as of October 2017.
Part of the Android Studio installation process will try to set you up to be able to use the x86 emulator. Make note of any messages that you see in the installation wizard regarding “HAXM” (or, if you are running Linux, KVM), as those will be important later.
Compiling and building an Android application, on its own, can be a hardware-intensive process, particularly for larger projects. Beyond that, your IDE and the Android emulator will stress your development machine further. Of the two, the emulator poses the bigger problem.
The more RAM you have, the better. 8GB or higher is a very good idea if you intend to use an IDE and the emulator together. If you can get an SSD for your data storage, instead of a conventional hard drive, that too can dramatically improve the IDE performance.
A faster CPU is also a good idea. The Android SDK emulator, as of 2016, supports CPUs with multiple cores — previously, it only supported a single core. However, other processes on your development machine will be competing with the emulator for CPU time, and so the faster your CPU is, the better off you will be. Ideally, your CPU has 2 to 4 cores, each 2.5GHz or faster at their base speed.
Beyond that, to use the x86 emulator — the emulator that runs well — you need a CPU with certain features:
|Development OS||CPU Requirements|
|Windows||an Intel CPU with support for VT-x, EM64T, and “Execute Disable” (XD)|
|Linux||an Intel CPU with support for VT-x, EM64T, and “Execute Disable” (XD), or an AMD CPU with support for AMD-V|
If your CPU does not meet those requirements, you will want to have 1+ Android devices available to you, so that you can test on hardware.
Also, if you are running Windows or Linux, you need to ensure that your computer’s BIOS is set up to support Intel’s virtualization extensions. Unfortunately, many PC manufacturers disable this by default. The details of how to get into your BIOS settings will vary by PC, but usually it involves rebooting your computer and pressing some function key on the initial boot screen. In the BIOS settings, you are looking for references to “virtualization” or “VT-x”. Enable them if they are not already enabled. macOS machines come with virtualization extensions pre-enabled.
The preview of this section may contain nuts.
The preview of this section was whisked away by a shark-infested tornado.
The preview of this section is in an invisible, microscopic font.
The preview of this section was fed to a gremlin, after midnight.