Expert Android Studio. Dundar Onur. Читать онлайн. Newlib. NEWLIB.NET

Автор: Dundar Onur
Издательство: John Wiley & Sons Limited
Серия:
Жанр произведения: Зарубежная образовательная литература
Год издания: 0
isbn: 9781119110736
Скачать книгу
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. – >

      <manifest xmlns: android="http://schemas.android.com/apk/res/android"

      package="com.example.android.camera2basic"> <uses-permission android: name="android.permission.CAMERA"/> <uses-feature android: name="android.hardware.camera"/> <uses-feature android: name="android.hardware.camera.autofocus"/>

      <application android: allowBackup="true"

      android: label="@string/app_name"

      android: icon="@drawable/ic_launcher"

      android: theme="@style/MaterialTheme"> <activity

      android: name=".CameraActivity"

      android: label="@string/app_name"> <intent-filter>

      <action android: name="android.intent.action.MAIN"/>

      <category android: name="android.intent.category.LAUNCHER"/>

      </intent-filter>

      </activity>

      </application>

      </manifest>

      Our manifest file starts with the manifest declaration, which also declares the main package. This declaration enables us to refer to subpackages and classes by using only the suffix after the root package.

      Next, the manifest declares the permissions, followed by the uses-feature tag to declare the hardware requirements of the application.

      Every activity and service component that resides in an Android project must be listed under the application tag. The sample project consists of only one activity, which is used as the entry point of the sample app, so the activity is listed as .CameraActivity, only with the full path and name after the root package and with the LAUNCHER intent. This activity will be used for launching the application presented in the Android manifest.

      Building and Running a Project

The sample project is a complete and ready-to-run application, so we can move on to building and running the application. Android Studio offers different ways to compile and run projects. To simply build a project, select Build from the toolbar and then the Make Project option, as shown in Figure 2.13.

Display of Build menu list.

Figure 2.13 Build menu list

Although this option will compile and package your app, it will not execute your app on either a device or the emulator. To run the sample project, select Run from the toolbar and then the Run Application option, as shown in Figure 2.14.

Display of Run menu items in Android Studio.

Figure 2.14 Run menu items in Android Studio

Alternatively, you can click the green Play icon (or Control+R on Mac, Ctrl+R in Windows), as shown in Figure 2.15.

Display of Android Studio Run &#8216;Application&#8217; button screen.

Figure 2.15 Android Studio Run ‘Application’ button

      Depending on your computer's hardware, Android Studio will spend some time to build the application and later will ask for a target device, which can also be an emulator, to run the application on. You haven't either created a virtual device or connected a real device yet, so you'll do that in the next section.

ANDROID EMULATOR

      Android Emulator is a great tool that is bundled with Android Studio. It enables your computer to emulate Android hardware and operating system to run your apps and provide a preview of how it would behave on a real device. The Android emulator enables you to test your application on a variety of screen sizes, hardware configurations, Android versions, and even different CPU architectures.

      However, the Android emulator has a bad reputation for being very slow. Developers used to make fun of it by saying, “If you optimize your app for the emulator, it will run smoothly on any device.” This may sound exaggerated but was almost true in the past.

      The main performance problem behind the emulation resulted from the ARM CPU emulation on personal computers, which mostly run on x86 CPU architecture. In 2011, Intel introduced HAXM and Google started providing x86-based Android system images, which boosted the emulator performance by using the host CPU instead of emulating a different CPU architecture.

      Installing HAXM

      To start using the emulator, you need to install HAXM and the x86 image of the desired version of Android. HAXM requires a minimum version of Android SDK 17. In most cases, HAXM installation is pretty straightforward. If you already installed the SDK (see Chapter 1), you can start creating your virtual device. If you didn't install it, you can set it up with the SDK Manager, as discussed in the “Android SDK Configuration Inside Android Studio” sidebar earlier in this chapter.

      1. Click Launch Standalone SDK Manager (refer to Figure 2.5) to open the Standalone SDK Manager shown in Figure 2.6.

      2. Scroll down to Extras and select Intel x86 HAXM Emulator Accelerator (HAXM Installer), as in Figure 2.16.

Screenshot of Intel HAXM selection in Windows.

Figure 2.16 Intel HAXM selection in Windows

      3. Once the download of HAXM is complete, you need to manually trigger its installer, from

      sdk\extras\intel\Hardware_Accelerated_Execution_Manager\ on

      Windows, or

      sdk/extras/intel/Hardware_Accelerated_Execution_Manager/ on Mac.

      Creating a New Android Virtual Device

It is very easy to create a new Android device. AVD (Android Virtual Device) Manager is the next icon. It's to the left of the SDK Manager, as shown in Figure 2.17.

Screenshot of Android Studio AVD Manager button.

Figure 2.17 Android Studio AVD Manager button

      1. Click the AVD Manager button. Because you haven't created a virtual device before, AVD Manager is currently empty (see Figure 2.18).

      2. Click the Create Virtual Device button, shown in Figure 2.18, to start creating a virtual Android device.

Screenshot of AVD Manager&#8217;s initial appearance.

Figure 2.18 AVD Manager's initial appearance

A list of available devices appears, as shown in Figure 2.19. At the top of the list are Nexus devices, which are the reference devices released by Google. The rest of the list contains common screen sizes and device properties. You are free to modify any device from the list or even create your own for testing purposes. Creating your own device might be a good idea for testing devices that you don't have access to. In addition to creating virtual devices to simulate phones, AVD Manager also supports tablets, wear, and TV.

Display of List of virtual device hardware.

Figure