Meet Android Studio

안드로이드 스튜디오는 안드로이드앱 개발을 위한 IntelliJ IDEA 을 기반으로 하는 통합 개발환경이다. IntelliJ의 강력한 에디터와 개발 툴 상에 안드로이드 스튜디오는 안드로이드 앱을 생성할 때 더욱 생산성을 향상시켜주는 특성들을 제공한다. 다음과 같은:

• 유연한 Gradle 기반의 빌드 시스템
• 빠르고 기능이 풍부한 에뮬레이터
• 모든 안드로이드 장치들을 개발할 수 있는 통합 환경
• 새로운 APK를 빌드하지 않고 실행하는 앱에 변경사항을 밀어 넣는 즉각적인 실행
• 공통 앱 기능들을 빌드하고 샘플 코드를 불러오는데 도움을 주는 코드 템플릿과 GitHub 통합
• Code templates and GitHub integration to help you build common app features and import sample code
• 광범위한 테스팅 툴과 프레임워크
• 퍼포먼스, 사용성, 버전 호환성 과 다른 문제점들을 잡기 위한 Lint 툴들
• C++과 NDK 지원
• Google Cloud Messaging과 App Engine 통합을 쉽게 하기 위한 Google Cloud Platform 내장 지원

이 페이지는 기본적인 안드로이드 스튜디오 특성에 대한 소개를 제공한다. 최근 변경사항의 요약은 Android Studio Release Notes 을 봐주세요.

Project Structure

---

Figure 1. The project files in Android view.

안드로이드 스튜디오의 각 프로젝트들은 소스 코드 파일들과 리소스 파일들과 함께 하나 이상의 모듈들을포함한다. 모듈의 타입은 다음과 같다:

• 안드로이드 앱 모듈
• 라이브러리 모듈
• 구글 앱 엔진 모듈
• Google App Engine modules

기본으로 안드로이드 스튜디오는 그림1과 같이 안드로이드 프로젝트뷰에 프로젝트 파일들을보여준다. 이 뷰는 프로젝트의 주요 소스 파일들에 빠른 접근을 제공하는 모듈들로 구성된다.

모든 빌드 파일들은 Gradle Scripts 하위에 탑 레벨에 보여지고 각 앱 모듈들은 다음 폴더들을 포함한다

• manifests:  AndroidManifest.xml 파일을 포함한다.
• java: JUnit test 코드를 포함한 자바 소스 코드 파일들을 포함한다.
• res: XML 레이아웃, UI 스트링, 그리고 비트맵 이미지들과 같은 소스 코드가 아닌 리소스들을 포함한다.

디스크 상의 안드로이드 프로젝트의 구조는 이 평평해진 표현과는 틀리다. 프로젝트의 실제 파일 구조를 보려면 Project 드롭다운에서 Project를 선택해라(그림1에서는 Android로 보여주고 있다).

또한 프로젝트 뷰를 당신의 앱 개발의 특정 측면에 맞춰서 커스터마이징 할 수 있다. 예를 들어, 프로젝트의 Problems 뷰를 선택하면 레이아웃 파일에서 태그를 닫는 XML 요소를 빼먹는 것과 같이 코딩과 문법에러를 포함하고 있는 소스 파일로의 링크를 보여주도록하는것이다.

Figure 2. The project files in Problems view, showing a layout file with a problem.

For more information, see Managing Projects.

The User Interface

---

The Android Studio main window is made up of several logical areas identified in figure 3.

Figure 3. The Android Studio main window.

1. 툴바는 넓은 영역의 액션을 수행하게 해준다. 앱을 실행시키는 것과 안드로이드 툴을 실행하는 것을 포함해서
2. 네비게이션 바는 당신의 소스 수정을 위해 당신의 프로젝트를 탐색하고 파일을 오픈하는 것을 돕는다. 그리고 프로젝트 툴 윈도우에서 보여주는 더욱 간략한 구조 뷰를 제공한다.
3. 에디터 윈도우는 코드를 생성하고 변경하는 곳이다. 현재 파일타입에 따라 윈도우는 변할 수 있다. 예를 들어, 레이아웃파일을 볼때, 에디터 윈도우는 레이아웃 에디터를 보여주고 대응하는 XML 파일을 보여주는 옵션을 제공한다.
4. 툴 윈도우는 프로젝트 관리, 검색, 버전 컨트롤 그리고 그외에 대한 특정 업무에 대한 접근을 제공한다. 사용자는 툴 윈도우를 펼치고 닫을 수 있다.
5. 상태바는 경고 및 메시지뿐만 아니라 프로젝트와 IDE 자체의 상태를 보여준다. 

툴바와 툴 운도우를 숨기거나 옮겨서 더 많은 스크린 공간을 주기 위해 메인 윈도우를 구성할 수 있다. 또한 대부분의 IDE 기능에 액세스 할 수 있도록 키보드 단축키를 사용하 ㄹ수 있다.

언제든, 쉬프트키를 두번 누르거나 안드로이드 스튜디오 윈도우의 오른쪽 상단코너에 있는 돋보기를 클릭하여 당신의 소스 코드, 데이터 베이스, 액션, UI의 요소 등등을 가로질러 검색할 수 있다. 이는 상당히 유용할 수 있는데, 예를 들어 어떻게 작동시키는지 까먹은 특정 IDE 액션의 위치를 찾고자 할때이다.

Tool Windows

perspective를 제공하는 대신에, 안드로이드 스튜디오는 당신의 문맥을 따르고 자동적으로 당신이 일하는 것에 따라 관련 툴 윈도우를 불러온다. 기본으로, 대부분 공통적으로 사용되는 툴 윈도우는 애플리케이션 윈도우의 가장자리에 있는 툴 윈도우 바에 고정되어 있다.

• 툴 윈도우를 확장하고 닫기 위해서 툴 윈도우 바에 있는 툴 이름을 클릭한다. 또한 툴윈도우를 드래그하고, 고정, 고정해제, 붙이고 떼고 할 수 있다.
• 현재기본 툴윈도우 레이아웃으로 돌아가기 위해 Window > Restore Default Layout 를 클릭하거나 Window > Store Current Layout as Default 를 클릭해서 디폴트 레이아웃을 커스터마이징 하세요. 
• 전체 툴 윈도우 바를 보이거나 숨기기 위해 안드로이드 스튜디오 윈도우의 왼쪽 하단에 있는 윈도우 아이콘  을 클릭합니다.
• 특정 툴 윈도우를 위치시키기 위해 윈도우 아이콘 위에 마우스 커서를 두고 메뉴에서 툴 윈도우를 선택합니다.

툴 윈도우를 열기 위해 키보드 단축키를 사용할 수 있습니다. 표1에는 대부분의 일반 윈도우를 위한 단축키를 열거합니다.

Table 1. Keyboard shortcuts for some useful tool windows.

Tool Window	Windows and Linux	Mac
Project	Alt+1	Command+1
Version Control	Alt+9	Command+9
Run	Shift+F10	Control+R
Debug	Shift+F9	Control+D
Android Monitor	Alt+6	Command+6
Return to Editor	Esc	Esc
Hide All Tool Windows	Control+Shift+F12	Command+Shift+F12

만약 모든 툴바, 툴 윈도우 그리고 엗터 탭을 숨기고 싶다면 View > Enter Distraction Free Mode 를 클릭하세요. 이는 Distraction Free Mode 를 가능케 합니다. Distraction Free Mode를 빠져나갈려면 View > Exit Distraction Free Mode 를 클릭합니다.

윈도우 스튜디오에서 대부분의 툴 윈도우 내에서 서치와 필터에 대한 Speed Search 를 사용할 수 있습니다. Speed Search를 사용하려면 툴 윈도우를 선택하고 당신의 search query 를 타이핑합니다.

You can use Speed Search to search and filter within most tool windows in Android Studio. To use Speed Search, select the tool window and then type your search query.

Code Completion

안드로이드 스튜디오는 세가지 코드 자동완성 타입이 있습니다. 이는 키보드 단축키를사용하여 접근 가능합니다.

Table 2. Keyboard shortcuts for code completion.

Type	Description	Windows and Linux	Mac
Basic Completion	Displays basic suggestions for variables, types, methods, expressions, and so on. If you call basic completion twice in a row, you see more results, including private members and non-imported static members.	Control+Space	Control+Space
Smart Completion	Displays relevant options based on the context. Smart completion is aware of the expected type and data flows. If you call Smart Completion twice in a row, you see more results, including chains.	Control+Shift+Space	Control+Shift+Space
Statement Completion	Completes the current statement for you, adding missing parentheses, brackets, braces, formatting, etc.	Control+Shift+Enter	Shift+Command+Enter

또한 빠른 수정을 수행하고 Alt+Enter 을 눌러서 intention action들을 보이게 할 수 있습니다.

자동 완성에 대한 더 많은 정보는 Code Completion 참고하세요.

Navigation

안드로이드 스튜디오 주변을 이동하는데 도움이되는 팁이 있습니다.

• Recent Files 액션을 이용하여 최근에 접근한 파일들 사이를 스위칭하세요.
  최근 파일들 액션을 불러오기 위해서 Control+E (Command+E on a Mac) 를 누릅니다. 기본으로 최근 접근 파일이 선택되어 있습니다. 또한 이 액션의 왼쪽 컬럼을 통해 어느 툴윈도우든 접근할 수 있습니다.
•  File Structure 액션을 이용해서 현재 파일의 구조를 봅니다. File Structure 액션을 불러오기 위해 Control+F12 (Command+F12 on a Mac)을 누룹니다. 이 액션을 사용해서 현재 파일의 어느 부분으로든 빠르게 탐색할 수 있습니다.
• Navigate to Class 액션을 이용해 당신 프로젝트 내에서 특정 클래스를 검색하고 탐색하세요.  Control+N(Command+O on a Mac)을 눌러서 액션을 불러옵니다. Navigate to Class supports sophisticated expressions, including camel humps, paths, line navigate to, middle name matching, and many more. 만약 연속해서 두번 호출하면, 프로젝트 외부에서의 결과를 보여준다.
• Navigate to File 액션을 이용해 파일이나 폴더를 탐색해라. Navigate to File 애션은 Control+Shift+N (Command+Shift+O on a Mac)를 눌러서 불러온다. 파일 대신 폴더를 찾기 위해 당신의 표현 끝에 / 를 더해라.
• Navigate to Symbol 액션을 이용해서 이름으로 멤버나 필드를 탐색합니다. Control+Shift+Alt+N(Command+Shift+Alt+O on a Mac) 를 눌러서 Navigate to Symbol을 불러옵니다. 
• Alt+F7 을 눌러서 현재 커서 위치에서 클래스 메소드, 필드, 파라미터 또는 문장에 대한 코드 참조를 찾습니다. 

Style and Formatting

편집을 하면서, 안드로이드 스튜디오는 자동으로 당신의 코드 스타일 셋팅에 지정된데로 포매팅과 스타일을 적용합니다. 프로그래밍 언어별로 코드 스타일 셋팅을 커스터마이징 할수 있으며 이는 탭, 들여쓰기, 공백, wrapping 그리고 괄호, 빈 줄에 대한 규칙을 지정하는 것을 포함합니다. 당신의 코드 스타일 셋팅을 커스터마이징 하기 위해 File > Settings > Editor > Code Style (Android Studio > Preferences > Editor > Code Style on a Mac.)을 클릭합니다.

당신이 작업할 때 IDE가 포맷팅을 자동적으로 적용함에도, Control+Alt+L(Opt+Command+L on a Mac) 을 눌러서 명시적으로 Reformat Code 액션을 호출할 수 있습니다. 또는 Control+Alt+I (Alt+Option+I on a Mac). 를 눌러서 모든 라인에 auto-indent를 수행할 수 있습니다.

Figure 4. Code before formatting.

Figure 5. Code after formatting.

Version Control Basics

안드로이드 스튜디오는 다양한 버전 컨트롤 시스템(VCS's)을 지원한다. 여기는 Git, GitHub, CVS, Mercurial, Subversion 그리고 Google Cloud Source Repositories가 포함된다.

안드로이스 스튜디오에 앱을 임포팅한 이후에 희망하는 버전 컨트롤 시스템을 위한 VCS 지원을 가능하게 하기 위해 안드로이드 스튜디오 VCS 메뉴 옵션을 사용한다. repository를 생성하고 새로운 파일들을 버전 컨트롤에 임포트하고 그외 버전 컨트롤 작업을 수행한다:

1. 안드로이드 VCS 메뉴로부터 Enable Version Control Integration을 클릭한다.
2. 드롭다운 메뉴로부터 project root와 연관된 버전 컨트롤 시스템을 선택하고 OK를 클릭한다.

이제 VCS 메뉴는 당신이 선택한 시스템에 기반한 많은 버전 컨트롤 옵션을 보여준다.

Note: File > Settings > Version Control 메뉴를 선택해서 버전 컨트롤 셋팅을 셋업하고 변경할 수 있다.

Gradle Build System

---

안드로이드 스튜디오는 빌드 시스템 토대로 Gradle을 사용한다. 이는 Android Plugin for Gradle
이 제공하는 안드로이드만의 기능을 가지고 있다. 이 빌드 시스템은 안드로이드 스튜디오 메뉴에서 통합된 툴로써 실행되고 명령 라인에서는 독립적으로 실행된다. 당신은 다음의 빌드 시스템 특성을 사용할 수 있다 :

• 빌드 프로세스를 커스터마이즈하고 설정하고 확장한다.
• 동일한 프로젝트와 모듈을 사용하는 다른 특성들을 가진 다양한 APK들을 생성한다.
• 소스셋을 전체에 걸쳐 코드와 리소스를 재사용한다.

Gradle의 유연성을 채용하여 앱 코어 소스 파일들을 변경하지 않고 이 모든 것을 달성할 수 있다. 안드로이스 스튜디오 빌드 파일들은 build.gradle로 이름붙여져 있다. 파일들은 안드로이드 Gradle 플러그인에 의해 제공되는 요소들로 빌드를 설정하는 Groovy문법을 사용하는 평범한 텍스트 파일이다. 각 프로젝트는 최상위 레벨에 전체 프로젝트를 위한 하나의 빌드 파일을 가지고 있고 각 모듈별로 모듈레벨 빌드 파일들로 구분된다. 존재하는 프로젝트를 임포트하면 안드로이드 스튜디오는 자동으로 필요한 빌드 파일들을 생성한다.
빌드 시스템과 설정하는 방법에 대해 더 알고 싶으면  Configure Your Build를 참고해라. 

Build Variants

빌드 시스템은 하나의 프로젝트로부터 동일한 애플리케이션의 다양한 버전을 생성하는데 도움을 줄 수 있다. 당신이 앱의 무료버전과 유료버전을 동시에 가지고 싶거나 구글 플레이에 있는 다양한 환경을 위한 다수의 APK들을 배포하고자 할 때 유용하다.
build variants를 설정하는 더 많은 정보는 Configuring Gradle Builds를 참고해라. 

APK Splits

APK splits는 screen density 나 ABI에 기반한 다수의 APK들을 효율적으로 생성하게 해준다. 예를 들어 APK splits는 앱을 분리된 hdpi와 mdpi 버전으로 생성하면서 여전히 그들을 하나의 variant로 간주하고 그들이 test app, javc, dx 그리고 ProGuard 셋팅들을 공유할 수 있게 해준다. 

APK Splits에 대한 더 많은 정보는 APK Splits 를 참고해라. 

Resource Shrinking

안드로이드 스튜디오에서 Resource shrinking은 당신의 패키징된 앱과 라이브러리 의존성으로부터 사용되지 않는 리소스들을 자동으로 제거한다. 예를 들어 당신 앱이 구글 드라이브 기능에 접근하기 위해 Google Play services를 사용하고 현재 당신이 Google Sign-In을 사용하고 있지 않다면 Resource shrinking은 SignInButton 버튼을 위한 다양한 drawable assets을 제거할 것이다.

Note: Resource shrinking 은 ProGuard와 같은 code shrinking tool과 조합하여 동작한다.

코드와 리소스를 줄이기 위한 더 많은 정보는 Shrink Your Code and Resources를 보아라.

Managing Dependencies

프로젝트를 위한 의존성은 build.gradle 파일에 있는 이름으로 명세된다. Gradle은 주의를 기울여 당신 의존성을 찾아내고 당신의 빌드에서 사용가능하게 한다. 당신은 build.gradle파일에 모듈 의존성, remote binary dependencies, 그리고 ㅣlocal binary dependencies 를 선언할 수 있다. 안드로이드 스튜디오는 프로젝트가 Maven Central Repository를 디폴트로 사용하도록 설정한다.(이 설정은 프로젝트를 위한 최상위 빌드 파일에 포함된다.) 의존성 설정에 대한 더 많은 정보는 Configure Build Variants를 읽어라.

Debug and Profile Tools

---

안드로이드 스튜디오는 당신이 디버깅하고 코드의 성능을 개선하는 것을 보조한다. 여기는 인라인 디버깅과 퍼포먼스 분석 툴이 포함된다.

Inline debugging

refences, expressions, 그리고 변수 값의 inline verification을 가진 디버깅 뷰에서 당신 코드의 자세한 설명을 개선하기 위해 인라인 디버깅을 사용해라. 인라인 디버깅 정보는 다음을 포함한다:

• Inline variable values
• Referring objects that reference a selected object
• Method return values
• Lambda and operator expressions
• Tooltip values

Figure 6. An inline variable value.

인라인 디버깅을 활성화시기기 위해 Debug window 에서 Settings 을 클릭하고 Show Values Inline을 위한 체크박스를 선택한다.

Performance monitors

안드로이드 스튜디오는 쉽게 당신 앱의 메모리와 CPU 사용량을 추적하고 deallocated object를 찾고 메모리 릭을 찾고 그래픽 성능을 최적화하고 네트웍 요구사항을 분석할 수 있도록 퍼포먼스 모니터를 제공한다. 디바이스와 에뮬레이터 상에서 앱을 실행시키고 Android Monitortool 을 열어서 Monitors 탭을 클릭한다.
퍼포먼스 모니터의 더 많은 설명은 Android Monitor를 보아라. 

Heap dump

당신이 안드로이드 스튜디오에서 메모리 사용을 모니터링 할 때 동시에 가비지 컬렉션을 시작시키고 Android-specific HPROF bianry format 파일로 heap snapshot에 대한 자바 힙 덤프를 할 수 있다. HPROF 뷰어는 메모리 사용을 추적하고 메모리 릭을 찾는 것을 돕기 위해 클래스, 각 클래스의 인스턴스 그리고 참조 트리를 보여준다.
힙 덤프를 가지고 하는 작업에 대한 더 많은 정보는 Dumping and Analyzing the Java Heap을 보아라.

Allocation tracker

안드로이드 스튜디오는 메모리 사용을 모니터하면서 메모리 할당을 추적할 수 있게 해준다. 메모리 할당 추적은 특정 액션을 수행할 때 어디에 메모리가 할당되는지 모니터할 수 있게 해준다 이러한 할당을 아는 것은 이들 액션과 관련된 메소드 호출을 조절함으로써 당신 앱 성능과 메모리를 최적화할 수 있게 한다.
할당의 추적과 분석에 대한 정보는 Allocation Tracker를 보아라. 

Data file access

Systrace, logcat, 그리고 Traceview와 같은 안드로이드 SDK 툴은 자세한 앱 분석을 위한 퍼포먼스와 디버깅 데이터를 생성한다.
사용가능한 생성 데이터 파일을 보기 위해 Captures tool 윈도우를 연다. 생성된 파일 리스트에서 데이터를 보기 위해 더블 클릭한다. .hprof 파일에서 오른 버튼을 클릭해서 표준 .hprof 파일 포맷으로 변경할 수 있다.

Code inspections

프로그램을 컴파일할 때마다, 안드로이드 스튜디오는 당신이 쉽게 코드의 구조적인 질과 함께 문제를 인식하고 수정할 수 있도록 자동으로 설정된 Lint 과 다른  IDE inspections를 실행한다.

Lint 툴은 잠재적인 버그와 correctness, security, performance, usability, accessibility, 그리고 internationalization을 위한 최적화 개선을 위해 안드로이드 프로젝트 소스 파일을 체크한다.

Figure 7. The results of a Lint inspection in Android Studio.

Lint 체크와 더불어, 안드로이드 스튜디오는 IntelliJ 코드 검사를 수행하고 당신의 coding workflow 간소화하기 위한 annotation을 검증한다.
더 자세한 정보는 Improving Your Code with Lint와 lint tool 을 보아라.

Annotations in Android Studio

안드로이드 스튜디오는 버그, null pointer exception 그리고 리소스 타입 충돌 등의 수정을 도와주는 변수, 파라미터 그리고 결과값을 위한 annotation을 포함한다. Android SDK Manager는 안드로이드 스튜디오에서 사용할 수 있도록 Android Support Repository에 Support-Annotation library를 패키징하고 있다. 안드로이드 스튜디오는 코드를 점검하는 동안 설정된 annotation의 유효성을 검증한다.

Android annotation에 대한 더 자세한 사항은 Improving Code Inspection with Annotations 을 보아라. 

Log messages

안드로이드 스튜디오에서 앱을 실행할 때 adb 출력과 윈도우 하단에 있는 Android Monitor를 클릭하여 디바이스 로그메시지(logcat) 를 볼 수 있다.

만약 Android Device Monitor 에서 앱을디버깅하기 원한다면 Tools > Android > Android Device Monitor 를 클릭하여 Device Monitor를 띄울 수 있다. Device Monitor 에서 당신 앱을 프로파일링하고 device behavior를 제어하는 등의 작업을 하기 위한 DDMS툴 셋을 찾을 수 있다. 또한 레이아웃을 최적화하는데 도움을 주는 Hierarchy Viewer tool을 포함한다.

Getting Started with Testing

이전다음

Dependencies and prerequisites

• Android Studio 2.0, or later.
• The Android Support Repository (available from the SDK Manager)

This lesson teaches you to

1. Configure Your Project for Local Unit Tests
2. Configure Your Project for Instrumented Tests
3. Build and Run Your Tests
   1. Run Local Unit Tests
   2. Run Instrumented Tests
   3. Run Instrumented Tests with Cloud Test Lab

See also

• Testing Concepts
• Android Testing Samples
• Cloud Test Lab

test를 작성하고 실행하는 것은 안드로이드 앱 개발 사이틀에서 중요한 부분이다. 잘 작성한 테스트는 개발중에 일찍 버그를 잡을 수 있게 도와줄 수 있고 당신 코드에 자신감을 준다. 안드로이드 스튜디오를사용해서 다양한 물리 또는 가상 안드로이드 장치 상에서 local unit test나 instrumented test를 수행할 수 있다. 그러면 결과를 분석해서 개발환경을 벗어날 필요없이 당신의 코드에 수정작업을 할 수 있다.

Local unit tests 는 로컬 머신에서 실행하는 테스트이다. 이는 안드로이드 프레임워크나 안드로이드 장치에 접근할필요가 없다. local units tests를 작성하는지 배우려면 Building Local Unit Tests 를 보아라.

Instrumented tests 는 안드로이드 장치나 에뮬레이터상에서 실행하는 테스트이다. 테스트는 테스트 중에 앱의 Context 와 같은 Instrumentation information 에 접근한다. Instrumented tests는 unit, user interface(UI), 또는 app component integration testing에 사용될 수 있다. 구체적인 필요에 따라 어떻게 instrumented test를 개발하는지 알고 싶으면 다음의 추가적인 주제를 참조해라. :

• Building Instrumented Unit Tests - mock object를 이용하여 쉽게 채워질 수 없는 안드로이드 의존성을 갖는 좀더 복잡한 unit tests를 생성한다.
• Automating User Interface Tests - 싱글 앱 내에서 사용자 상호작용이나 여러 앱에 걸친 상호작용에 대해 정확히 사용자 인터페이스가 동작하는지 검증하는 테스트를 작성한다.
• Testing App Component Integrations - Service 나 Content Provider 와 같은 사용자가 직접 상호작용하지 않는 컴포넌트의 동작을 검증한다.

이 레슨은 어떻게 안드로이드 스튜디오를 이용해서 테스트를 구축하고 실행시키는지 알려준다. 만약 안드로이드 스튜디오를 사용하고 있지 않는다면 run your tests from the command-line 를 사용할 수 있다.

Configure Your Project for Local Unit Tests

안드로이드 스튜디오 프로젝트에서 명확한 소스 디렉토리(src/test/java) 안에 local unit test를 위한 소스 파일들을 저장해야 한다. 이는 당신의 unit tests를 하나의 소스 집합으로 그룹핑함으로써 프로젝트 조직을 새선한다.

생산 코드와 함께 specific flavor or build type 을 위한 local unit tests를 생성할 수 있다. 당신의 unit test를 당신의 생산 소스 트리에 대응하는 test source tree 위치에 유지해라. 다음과 같이:

Path to Production Class	Path to Local Unit Test Class
src/main/java/Foo.java	src/test/java/FooTest.java
src/debug/java/Foo.java	src/testDebug/java/FooTest.java
src/myFlavor/java/Foo.java	src/testMyFlavor/java/FooTest.java

JUnit 4 framework가 제공하는 표준 API들을 사용하는 당신의 프로젝트를 위해 테스팅 의존서을 설정할 필요가 있다. 테스트가 안드로이드 의존성과 상호작용할 필요가 있다면 Mockito 를 포함하여 당신의 local unit test를 단순화시켜라ㅏ. local unit tests에서 mock object를 사용하는 법은 Mocking Android dependencies 를 보아라.

당신 앱의 top-level build.gradle In에 의존성에 대해 이들 라이브러리를 명세할 필요가 있다. :

dependencies {
    // Required -- JUnit 4 framework
    testCompile 'junit:junit:4.12'
    // Optional -- Mockito framework
    testCompile 'org.mockito:mockito-core:1.10.19'
}

Configure Your Project for Instrumented Tests

안드로이드 스튜디오 프로젝트에서 특정 디렉토리(src/androidTest/java)에 당신의 instrumented tests를 위한 소스코드를 위치시켜야 한다.

 Android Testing Support Library Setup 를 다운르도 해라. 이는 당신의 앱을 위한 instrumented 테스트코드를 빠르게 구축하고 실행할 수 있도록 도와준다. Testing Support Library 는 JUnit4 test runner(AndroidJUnitRunner ) 와 기능적인 UI test(Espresso and UI Automator)를 위한 API들을 지원한다.

당신의 프로젝트가 Testing Support Library가 제공하는 test runner와 API 룰들을 사용할 수 있도록 Android testing dependencies 설정할 필요가 있다. 당신의 테스트 개발을 간단하게 하기 위해,우리는  Hamcrest라이브러리를 포함할 것을 추천한다. 이는 Harcrest matcher API들을 이용하여 좀더 유연한 assertions들을 생성할 수 있게 해준다.

당신앱의 top-level build.gradle 파일에, 의존성에 대한 이들 파일들을 명세할 필요가 있다.

dependencies {
    androidTestCompile 'com.android.support:support-annotations:23.0.1'
    androidTestCompile 'com.android.support.test:runner:0.4.1'
    androidTestCompile 'com.android.support.test:rules:0.4.1'
    // Optional -- Hamcrest library
    androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
    // Optional -- UI testing with Espresso
    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.1'
    // Optional -- UI testing with UI Automator
    androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.1'
}

To use JUnit 4 test classes, make sure to specify AndroidJUnitRunner as the default test instrumentation runner in your project by including the following setting in your app's module-level build.gradle file:

android {
    defaultConfig {
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
}

Work With Test Artifacts

Android Studio has two types of test artifacts: Android Instrumentation Tests and Unit Tests. Previously, you could work with just one test artifact at a time. Now, both test artifacts are enabled. The advantage of enabling both test artifacts is that any changes you make to the underlying code affect them both. For example, if you rename a class that both test artifacts access, both will know about the class name refactoring.

The figure shows what your project looks like with both test artifacts enabled. Notice the shading of both test artifacts.

Build and Run Your Tests

---

Android Studio provides all the tools you need to build, run, and analyze your tests within the development environment. You can also run instrumented tests on multiple device configurations, simultaneously, using Cloud Test Lab integration.

Note: While running or debugging instrumented tests, Android Studio does not inject the additional methods required for Instant Run and turns the feature off.

Run Local Unit Tests

To run your local unit tests:

1. In the Project window, right click on the project and synchronize your project.
2. In the Project window, navigate to your unit test class or method, then right-click it and select Run .
   • To run all tests in the unit test directory, right-click on the directory and select Run tests .

The Android Plugin for Gradle compiles the local unit test code located in the default directory (src/test/java), builds a test app, and executes it locally using the default test runner class. Android Studio then displays the results in the Run window.

Run Instrumented Tests

To run your instrumented tests:

• In the Project window, navigate to your instrumented test class or method, then right-click and run it using the Android Test configuration. To run all tests in the instrumented test directory, right-click the directory and select Run tests .

The Android Plugin for Gradle compiles the instrumented test code located in the default directory (src/androidTest/java), builds a test APK and production APK, installs both APKs on the connected device or emulator, and runs the tests. Android Studio then displays the results of the instrumented test execution in the Run window.

Run Instrumented Tests with Cloud Test Lab

Using Cloud Test Lab, you can simultaneously test your app on many popular Android devices, across multiple languages, screen orientations, and versions of the Android platform. These tests run on actual physical devices in remote Google data centers. You can also configure your instrumented tests to take screenshots while Cloud Test Lab runs its tests. You can deploy tests to Cloud Test Lab from the command line, or from Android Studio's integrated testing tools.

Android Studio allows you to connect to your Google Cloud Platform account, configure your tests, deploy them to Cloud Test Lab, and analyze the results all within the development environment. Cloud Test Lab in Android Studio supports the following Android test frameworks: Espresso, UI Automator 2.0, or Robotium. Test results provide test logs and include the details of any app failures.

Before you can start using Cloud Test Lab, you need to:

1. Create a Google Cloud Platform account to use with active billing.
2. Create a Google Cloud project for your app.
3. Set up an active billing account and associate it with the project you just created.

Configure a test matrix and run a test

Android Studio provides integrated tools that allow you to configure how you want to deploy your tests to Cloud Test Lab. After you have created a Google Cloud project with active billing, you can create a test configuration and run your tests:

1. Click Run > Edit Configurations from the main menu.
2. Click Add New Configuration (+) and select Android Tests.
3. In the Android Test configuration dialog:
   1. Enter or select the details of your test, such as the test name, module type, test type, and test class.
   2. From the Target drop-down menu under Deployment Target Options, select Cloud Test Lab Device Matrix.
   3. If you are not logged in, click Connect to Google Cloud Platform and allow Android Studio access to your account.
   4. Next to Cloud Project, click the  button and select your Google Cloud Platform project from the list.
4. Create and configure a test matrix:
   1. Next to the Matrix Configuration drop-down list, click Open Dialog .
   2. Click Add New Configuration (+).
   3. In the Name field, enter a name for your new configuration.
   4. Select the device(s), Android version(s), locale(s) and screen orientation(s) that you want to test your app with. Cloud Test Lab will test your app against every combination of your selections when generating test results.
   5. Click OK to save your configuration.
5. Click OK in the Run/Debug Configurations dialog to exit.
6. Run your tests by clicking Run .

Figure 1. Creating a test configuration for Cloud Test Lab.

Analyzing test results

When Cloud Test Lab completes running your tests, the Run window will open to show the results, as shown in figure 2. You may need to click Show Passed  to see all your executed tests.

Figure 2. Viewing the results of instrumented tests using Cloud Test Lab.

You can also analyze your tests on the web by following the link displayed at the beginning of the test execution log in the Run window, as shown in figure 3.

Figure 3. Click the link to view detailed test results on the web.

To learn more about interpreting web results, see Analyzing Cloud Test Lab Web Results.

이전 다음

3GPP TS 23.040 9.Protocols and protocol architecture

9. Protocols and protocol architecture
SMS의 프로토콜 레이어는 figure7에 보이는데로 구조화되어 있다.

현재 문서는 SM-TL, MS와 SC에서 SM-TL에 의해 제공되는 서비스 그리고 SC에서 SM-RL에 의해 제공되는 서비스에서 프로토콜을 명세한다.

일반적으로 SM-TL은 SM MO 인 경우 SC에서 종료된다. SMS-IWMSG는 SMS internetworking agreement의 존재를 체크하기 위해 SMS-SUBMIT에 있는 TP-DA를 조사할 것이다.(8.2.2 절을 보아라)
=========================================================
8.2.2 Functionality of the SMS-IWMSC
MSG 또는 SGSN("forwardShortMessage", 10절을 보아라) 으로부터 TPDU 단문 메시지를 수신했을 때, SMS-IWMSG는 다음 작업에 대해 책임이 있다.

- 단문 메시지 TPDU의 수신;
- 선택적으로, HRL에 문의(심문) 한다("sendRoutingInfoForShortMsg", 10절을 보아라); 지정
된 주소를 가진 링크를 성립하기 전에 SMS Interworking agreement가 존재하는지 체크하기 위해 받는이의 IMSI를 조회한다.

만약 HLR이 에러 정보를 리턴하면:
- MSG 나 SGSN에 failure report에 실어 적절한 에러 정보를 리턴한다("forwardShortMessage"의 부정적인 결과, 10절을 보아라);

만약 HLR에서 어떤 에러도 지정되지 않으면:
- IMSI 파라미터를 조사하고 다른 라우팅 정보를 무시한다

만약 수신된 파라미터가 SMS-IWMSC에 대해 수용할 수 없으면(SMS Interworking agreement가 없어서)
- SM Delivery Failure를 리턴한다. 다음 indication을 가진: invalid SME-address to the MSG 또는 SGSN

만약 SMS-IWMSC에 대해 파라미터를 수용할 수 있거나(SMS Interworking agreement가 있어서) SMS-IWMSC가 선택적인 HLR interrogation(문의, 심문)을 적용하지 않는다면
- 필요하면, 지정된 SC와 링크를 성립한다(5절을 보아라);
- SC로 단문 메시지 TPDU를 전송한다( 만약 주소가 유효하면);

만약 SC로부터 단문 메시지와 연관된 report를 수신받으면, SMS-IWMSG는 다음 작업에 책임이 있다:
- report를 MSG나 SGSN에 릴레이한다("forwardShortMessage"의 긍정적인 혹은 부정적인 결과, 10절을 보아라).

만약 timer가 만료되기 전에 SC로부터 단문 메시지와 연관된 report를 받지 못했거나 SC address가 유효하지 않으면 SMS-IWMSG는 다음 작업에 책임이 있다.
- 적절한 에러 정보를 failure report에 실어 MSC나 SGSN에 리턴한다("forwardShortMessage"의 부정적인 결과, 10절을 보아라).

타이머의 값은 SC와 SMS-IWMSC 사이의 프로토콜에 의존적이다.
=========================================================

9.1 Protocol element feature
9.1.1 Octet and Bit transmission order
옥텟은 그들 개개의 넘버링에 따라 전송된다; 가장 낮은 숫자의 넘버링을 가진 옥텟이 먼저 전송된다. 각 옥텟에 있는 비트들 또한 그들 개개의 넘버링에 따라 전송된다; 가장 낮은 내부 번호를 가진 비트들이 가장 먼저 전송된다.

9.1.2 Numeric and alphanumeric representation
TPDU 내에 있는 파라미터들의 경우 네가지의 숫자 표현방식을 갖는다: Integer representation, octet, semi-octet 그리고 alphanumeric representation.

9.1.2.1 Integer representation
많은 옥텟으로부터의 비트가 완전하게 혹은 부분적으로 integer로 표현된다. 해석은 다음을 따라 이루어진다:
1) 옥텟들 중: 가장 낮은 옥텟 수를 가진 옥텟들이 most significant bits를 자질 것이다, 즉 byte order는 big endian이 될 것이다.
2) 옥텟 내부: 가장 큰 비트 수를 가진 비트들이 most significant가 될 것이다.

아래의 옥텟 예제는 bit presentation과 integer presented field의 전송순서를 나타내고 있다.

옥텟 no 5의 오른쪽 두 비트, 옥텟 no 6과 7의 완전한 옥텟, 그리고 옥텟 no 8의 왼쪽 3 비트들이 figure8과 같이 하나의 integer를 표현하고 있다고 하자.

9.1.2.2 Octet representation

옥텟으로 표현되는 필드는 항상 많은 수의 완전한 옥텟으로 표현될 것이다. 각 필드 내에 있는 옥텟들은 하나의 10진수로 표현된다. 가장 낮은 옥텟 수를 가진 옥텟은 most siginificant 십진술르 포함할 것이다.

9.1.2.3 Semi-octet representation
세미 옥텟으로 표현되는 필드는 많은 완전한 옥텟들과 아마도 반 옥텟으로 구성될 것이다. 필드 내에 있는 각각의 반 옥텟들은 하나의 십진수이다.가장 낮은 옥텟 수를 가진 옥텟들은 most significant 십진수를 가질 것이다. 한 옥텟 내에서 0에서 3비트 자리를 가진 반옥텟은 most significant 수를 표현할 것이다.

세미옥텟으로 표현되는 필드가 홀수개의 수로 구성되는 경우, 마지막 옥텟에 있는 4에서 7번째 비트 자리 수는 항상 "1111"로 셋팅될 것이다.

만약 모바일이 세미 옥텟에서 "1111"(예를들어, 1110)이 아닌 어떤 integer 정보도 없는 주소 필드를 받는 다면 모바일은 세미옥텟을 "BCD number" 라고 불리는 GSM 44.008[12]에 주어진 표현대로 표시할 것이다. 즉 1010="*", 1011="a", 1101="b", 1110="c". 여기 따옴표로 묶인 값과 GSM 44.008[12]에 명세된 값의 불일치는 GSM 44.008[12] 값이 우선할 것이다. 만약 모바일이 마지막 세미옥텟 이전 위치에서 "1111"을 받는다면 처리는 다음 세미옥텟에서 시작할 것이고 중간에 개입된 세미옥텟은 무시될 것이다.

각 세미옥텟 내에서 가장 높은 비트 자리수의 비트가 most significant이다.

아래 주어진 예를 보자.

9.1.2.4 Alphanumeric representation
alphanumeric 표현을 사용하는 필드는 3GPP TS 23.038[9]에 정의된 기본 알파벳으로 표현되는 많은 7-bit 캐릭터들로 구성된다.

9.1.2.5 Address fields
SM-RL에 의해 사용되는 Address field들은 3GPP TS 24.011[13]과 3GPP TS 29.002[15]에 명세된다.

SM-TL의 각 address field는 다음의 하부 필드들로 구성된다: 하나의 옥텟의 Address-Length field, 하나의 옥텟의 Type-of-Address 필드, 그리고 하나의 가변 길이를 갖는 하나의 Address-Value field; 아래에 보이는 바와 같이

Address-Length 필드는 Address-Value 필드 내에 있는 유용한 세미 옥텟의 길이의 integer 표현이다. 채움 비트만 포함하는 세미 옥텟은 제외된다.

Type-of-Address 필드 포맷은 다음과 같다.

MS는 예약된 값을 "Unknown"으로 해석하겠지만 그 값들을 정확하게 받은데로 저장할 것이다.
SC는 예약된 값을 포함하거나 지원하지 않는 type of number 를 가진 메시지를 거부할 것이다.
예약된 값은 이 버전의 스펙을 준수하여 SC에 의해 전송되지 않을 것이다.
1) "Unkown"은 사용자나 네트웍이 numbering plan에 대한 이전(선험적인) 정보를 가지고 있지 않을 때 사용된다. 이 경우 Address-Value 필드는 network dialing plan에 따라 구성된다. 예를 들어 prefix 나 escape 숫자가 표시될 것이다.
2) international format은 MSC나 SGSN 상으로 동일 국가에 있는 수신인을 향한 메시지일 때도 수신될 것이다.
3) Prefix 나 escape 숫자는 포함되지 않을 것이다.
4) "Network specific number"는 serving network에 한정하여 administation/service number를 가리키는데 사용된다, 예를 들어 operator를 접근하는데 사용된다.
5) "Subscriber number"는 더 높은 레이어의 애플리케이션의 한 부분으로써 하나이상의 SC에 특정 short number 표현이 저장되어 있을 때 사용된다("Subscriber number"는 이 애플리케이션을 참조하는 적절한 PID와 조합하여서만 사용될 것이다)

Numbering-plain-identification

1) "Service Centre specific number"는 SMSC에 소속된 외부의 Short Message Entities에 한정된 numbering plan을 가리킬 때 사용된다.

Type-of-number = 101의 경우 bit 3,2,1,0은 예약 되어 있고 0000으로 전송될 것이다. SC, MSC, SGSN, 또는 MS의 어떤 엔터티에 대해 주소지정을 하기 위해서는 Numbering-plan-indentification=0001이 항상 사용될 것이다. 그러나 SME를 주소지정하기 위해서는 어떤 명시된 Numbering-plan-identification 값도 사용될 수 있다.

MS는 예약된 값을 "Unknown"으로 해석하 ㄹ수 있지만 그것들을 정확하게 수신받은 데로 저장할 것이다.
SC는 예약된 값이나 지원하지 않는 type of number 를 가진 메시지를 거부할 수 있다.
예약된 값은 이 버전의 명세를 준수하는 SC에 의해서는 전송되지 않을 것이다.
Address-Value field내에서는 세미 옥텟이나 alphanumeric 표현이 적용된다.
전체 address field의 최대 길이(Address-Length, Type-of-Address 그리고 Address-Value)는 12 옥텟이다.
1) SM-TL에서 주소지정할 때만 사용된다.

9.2 Service provided by the SM-TL
9.2.1 General

Short Message Transfer Layer(SM-TL)은 Short Message Application Layer(SM-AL)에게 서비스를 제공한다. 이 서비스는 SM-AL이 단문 메시지를 그것의 상태편 엔터티로 전송하고 상대 엔터티로부터 단문 메시지를 수신하고 전송된 단문 메시지에 대한 이전 요청에 대한 report를 수신한다.

이들 메시지에 대한 메시지와 report의 진로를 따라가기 위해서 SM-AL과 SM-TL사이의 프리미티브는 Short Message Identifier(SMI)를 포함한다. 이는 프리미티브와 연관된 메시지를 위한 레퍼런스 넘버이다. Short Message Identifier는 SM-TL과 Short message Relay Layer(SM-RL) 사이에 사용되는 Short Message identifier 와 상호 매핑된다.  Short Message Identifier는 엔터티들 사이에 전달되지 않으므로 주어진 메시지는 MS와 SC 측면에서 다른 SMI를 가질 수 있다(아래 9.3.1절을 보아라)

SM-TL은 아래 절에 설명하는 프로토콜을 사용하여 상대 엔터티와 통신한다.

9.9.2 PDU Type repertorie at SM-TL
SM-TL은 다음의 6개의 PDU들로 구성된다:

SMS-DELIVER, SM에서 MS로 단문 메시지를 실어나른다.
SMS-DELIVER-REPORT, 실어나른다;
a) a failure cause(필요하면)
b) SMS-DELIVER 나 SMS-STATUS-REPORT 에 대한 긍정 혹은 부정의 acknowledgement 부분으로써의 정보
SMS-SUBMIT, MS에서 SC로 단문 메시지를 실어나른다.
SMS-SUBMIT-REPORT, 실어나른다;
a) a failure cause(필요하면)
b) SMS-SUBMIT 또는 SMS-COMMAND에 대한 긍정 혹은 부정의 acknowledgement 부분으로써의 정보

SMS-STATUS-REPORT, SC에서 MS로 status report를 실어나른다.
SMS-COMMAND, MS에서 SC로 명령을 실어나른다.