반응형

이번 포스팅은 App Fragment Test 에 대하여 알아보도록 하겠습니다.


Fragment는 앱 내에서 재사용 가능한 컨테이너 역할을 하며, 다양한 Activity와 레이아웃 구성에서 동일한 사용자 인터페이스 레이아웃을 표시할 수 있습니다. Fragment는 다양한 용도로 사용되기 때문에 일관적이고 효율적으로 리소스를 사용하는 환경을 제공하는지 검증하는 것이 중요합니다.

Fragment의 외형은 대형 스크린 화면이나 기기에서 가로 모드를 지원하는 Fragment를 포함하여 모든 레이아웃 구성에서 일관적이어야 합니다.

Fragment가 사용자에게 보일 경우에만 Fragment의 뷰 계층 구조를 생성하세요.


Fragment의 상태 변경



이 테스트를 쉽게 설정할 수 있도록 AndroidX는 Fragment를 생성하고 상태를 변경하기 위한 FragmentScenario 라이브러리를 제공합니다.

참고: FragmentScenario 객체가 포함된 테스트 실행을 성공하기 위해 Test 계측 스레드에서 각 API 메서드를 실행하세요. Android 테스트에서 사용한 여러 가지 스레드에 대한 자세한 내용은 테스트의 스레드 이해를 참조하세요.


Test artifact 위치 구성

FragmentScenario를 의도한 대로 사용하려면 다음 소스 코드와 같이 앱의 테스트 APK에서 Fragment test artifact를 app/build.gradle 안에 정의합니다.

dependencies {
   
// ...
   
debugImplementation 'androidx.fragment:fragment-testing:{{ fragment_version }}'
}


Fragment 만들기

FragmentScenario에는 다음 유형의 Fragment를 실행하기 위한 메서드가 포함됩니다.

사용자 인터페이스 포함하는 그래픽 Fragment 입니다. 이 유형의 Fragment를 실행하려면 launchFragmentInContainer()를 호출합니다. FragmentScenario는 Fragment를 Activity의 루트 뷰 컨트롤러에 연결합니다. 그 외의 경우에는 Activity가 포함된 이 작업은 비어 있습니다.

▶ 여러 Activity에 포함된 정보를 단기적으로 실행하거나 저장하는 비 그래픽 Fragment 입니다. 이 유형의 Fragment를 실행하려면 launchFragment()를 호출합니다. FragmentScenario는 이 유형의 조각을 루트 보기가 없는 완전히 빈 활동에 연결합니다.

이런 Fragment 유형 중 하나를 실행한 이후 FragmentScenario는 테스트 중인 Fragment를 RESUMED 상태로 변경합니다. 이 상태는 Fragment가 실행 중이라는 것을 나타냅니다. 그래픽 Fragment를 테스트할 때 사용자에게도 테스트가 보이므로 Espresso UI 테스트를 사용하여 UI 요소에 대한 정보를 평가할 수 있습니다.

다음 소스 코드는 각 유형의 Fragment를 실행하는 방법을 보여줍니다.

<그래픽 Fragment 예시>

@RunWith(AndroidJUnit4::class)
class MyTestSuite {
   
@Test fun testEventFragment() {
       
// The "state" and "factory" arguments are optional.
       
val fragmentArgs = Bundle().apply {
            putInt
("selectedListItem", 0)
       
}
       
val factory = MyFragmentFactory()
       
val scenario = launchFragmentInContainer<MyFragment>(
                fragmentArgs
, factory)
        onView
(withId(R.id.text)).check(matches(withText("Hello World!")))
   
}
}

<비 그래픽 Fragment의 예시>

@RunWith(AndroidJUnit4::class)
class MyTestSuite {
   
@Test fun testEventFragment() {
       
// The "state" and "factory" arguments are optional.
       
val fragmentArgs = Bundle().apply {
            putInt
("numElements", 0)
       
}
       
val factory = MyFragmentFactory()
       
val scenario = launchFragment<MyFragment>(fragmentArgs, factory)
   
}
}


Fragment 다시 생성

기기에 리소스가 부족할 경우 시스템이 Fragment가 포함된 Activity를 소멸할 수 있으며, 이때 사용자가 앱에 돌아왔을 때 앱이 해당 Fragment를 다시 생성해야 합니다. 이 상황을 시뮬레이션하려면 recreate()를 호출하세요.

@RunWith(AndroidJUnit4::class)
class MyTestSuite {
   
@Test fun testEventFragment() {
       
val scenario = launchFragmentInContainer<MyFragment>()
       
scenario.recreate()
   
}
}

FragmentScenario 클래스가 테스트 중인 Fragment를 다시 생성하면 Fragment는 다시 생성하기 이전의 수명 주기 상태로 돌아옵니다.


Fragment를 새로운 상태로 변경

앱 UI 테스트에서는 대개 테스트 중인 Fragment를 실행하고 다시 생성하는 것만으로 충분합니다. 그러나 세밀한 유닛 테스트에서는 Fragment가 하나의 수명 주기에서 다른 수명 주기로 넘어갈 때 Fragment의 동작을 평가할 수 있습니다.

Fragment를 다른 수명 주기 상태로 변경하려면 moveToState()를 호출하세요. 이 메서드는 CREATED, STARTED, RESUMED, DESTROYED의 상태를 인수로 지원합니다. 이 작업은 Fragment가 포함된 Activity가 다른 앱이나 시스템 작업에 중단되어 상태를 변경하는 상황을 시뮬레이션합니다.

 참고: Fragment를 DESTROYED 상태로 전환할 경우 해당 Fragment를 다른 상태로 변경할 수 없고 Fragment를 다른 Activity에 연결할 수도 없습니다.

moveToState()의 사용 예시가 다음 소스 코드에서 나타납니다.

@RunWith(AndroidJUnit4::class)
class MyTestSuite {
   
@Test fun testEventFragment() {
       
val scenario = launchFragmentInContainer<MyFragment>()
       
scenario.moveToState(State.CREATED)
   
}
}

주의: 테스트 중인 Fragment를 현재의 상태로 전환하려고 할 경우 FragmentScenario는 이 요청을 예외가 아니라 ‑작업 불능으로 취급합니다. 특히, 이 API를 사용하면 Fragment를 DESTROYED 상태로 연속해서 여러 번 전환할 수 있습니다.


Fragment에서 작업 자르기

테스트 중인 Fragment에서 작업을 트리거하려면 Espresso 뷰 매처를 사용하여 뷰에서 요소와 상호작용하세요.

@RunWith(AndroidJUnit4::class)
class MyTestSuite {
   
@Test fun testEventFragment() {
       
val scenario = launchFragmentInContainer<MyFragment>()
       
onView(withId(R.id.refresh))
               
.perform(click())

   
}
}

Fragment 자체에서 메서드를 호출해야 할 경우 (예: 옵션 메뉴에서의 선택에 응답) FragmentAction을 구현하면 안전하게 호출할 수 있습니다.

@RunWith(AndroidJUnit4::class)
class MyTestSuite {
   
@Test fun testEventFragment() {
       
val scenario = launchFragmentInContainer<MyFragment>()
       
scenario.onFragment(fragment ->
            fragment
.onOptionsItemSelected(clickedItem) {
               
// Update fragment's state based on selected item.
           
}
       
}

   
}
}

참고: 테스트 클래스에서는 onFragment()로 전달한 객체에 대한 참조를 그대로 두지 마세요. 이 참조는 시스템 리소스를 사용하고, 프레임워크가 콜백 메서드로 전달된 Fragment를 다시 생성했기 때문에 참조 자체가 최신이 아닐 수 있습니다.


Reference

1. https://developer.android.com/training/basics/fragments/testing


반응형

'Development > Android' 카테고리의 다른 글

[Android] Intent Filter  (0) 2019.09.10
[Android] Flexable Fragment UI 구축  (0) 2019.09.06
[Android] Fragment의 생성  (0) 2019.09.06
[Android] Fragment의 개요  (0) 2019.09.06
[Android] Button의 배경을 투명하게 하는 방법  (0) 2019.09.05
반응형

이번 포스팅은 Fragment 생성하는 방법에 대하여 알아보도록 하겠습니다.


Fragment의 생성



Fragment를 생성하려면 Fragment 클래스를 extend 한 후 Activity 클래스에서와 마찬가지로 주요 수명 주기 메서드를 재정의하여 자체 앱 로직을 적용합니다.

Fragment 생성 시 한 가지 차이점은 레이아웃 정의에 onCreateView() 콜백을 사용해야 한다는 점입니다. 사실 Fragment 실행에 필요한 콜백은 이것뿐입니다. 다음은 자체 레이아웃을 지정하는 간단한 Fragment의 예입니다.

import android.os.Bundle
import android.support.v4.app.Fragment
import android.view.LayoutInflater
import android.view.ViewGroup

class ArticleFragment : Fragment() {
   
override fun onCreateView(inflater: LayoutInflater, container: ViewGroup,
                     savedInstanceState
: Bundle?): View {
       
// Inflate the layout for this fragment
       
return inflater.inflate(R.layout.article_view, container, false)
   
}
}

Activity와 마찬가지로, Fragment는 Activity에 추가되거나 Activity에서 삭제될 때, 그리고 Activity가 수명 주기 상태 간에 전환될 때 Fragment의 상태를 관리할 수 있는 다른 수명 주기 콜백을 구현해야 합니다. 예를 들어 Activity의 onPause() 메서드가 호출되면 Activity 내 모든 Fragment도 onPause() 호출을 받게 됩니다.

Fragment 수명 주기 및 콜백 메서드에 대한 자세한 내용은 Fragments 개발자 가이드를 참조하세요.


XML을 이용하여 Activity에 Fragment 추가



Fragment는 재사용이 가능한 모듈식 UI 구성 요소인 반면, Fragment 클래스의 각 인스턴스는 상위 FragmentActivity와 연결되어야 합니다. Activity 레이아웃 XML 파일 안에 각각의 Fragment를 정의하여 이 연결을 설정할 수 있습니다.

★ 참고: FragmentActivity는 지원 라이브러리에서 제공하는 특수한 Activity이며, API 레벨 11보다 낮은 시스템 버전에서 Fragment를 처리하는 데 사용합니다. 지원하는 가장 낮은 시스템 버전이 API 레벨 11 이상일 경우, 일반 Activity를 사용해도 됩니다.

다음은 기기 화면을 "large"로 간주할 때, 두 개의 Fragment를 Activity에 추가하는 레이아웃 파일의 예입니다. (디렉토리 이름에 large 한정자가 지정되어 있음).

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
   
android:orientation="horizontal"
   
android:layout_width="fill_parent"
   
android:layout_height="fill_parent">

   
<fragment android:name="com.example.android.fragments.HeadlinesFragment"
             
android:id="@+id/headlines_fragment"
             
android:layout_weight="1"
             
android:layout_width="0dp"
             
android:layout_height="match_parent" />

   
<fragment android:name="com.example.android.fragments.ArticleFragment"
             
android:id="@+id/article_fragment"
             
android:layout_weight="2"
             
android:layout_width="0dp"
             
android:layout_height="match_parent" />

</LinearLayout>

그런 다음 레이아웃을 Activity에 적용합니다.

import android.os.Bundle
import android.support.v4.app.FragmentActivity

class MainActivity : FragmentActivity() {
   
override fun onCreate(savedInstanceState: Bundle?) {
       
super.onCreate(savedInstanceState)
        setContentView
(R.layout.news_articles)
   
}
}

위 소스에서 v7 appcompat library를 사용하는 경우, Activity는 FragmentActivity의 하위 클래스인 AppCompatActivity를 대신 확장해야 합니다. 자세한 내용은 App bar 추가를 참조하세요.

참고: 레이아웃 XML 파일에서 Fragment를 정의하여 Activity 레이아웃에 Fragment를 추가하는 경우, 런타임에 Fragment를 삭제할 수 없습니다. 사용자 상호작용 중 Fragment를 추가 및 삭제하려면, Activity를 처음 시작할 때 Fragment를 Activity에 추가해야 합니다. 



Reference

1. https://developer.android.com/training/basics/fragments/creating

반응형
반응형

이번 포스팅은 Fragment 에 대하여 자세히 알아보도록 하겠습니다.


Fragment FragmentActivity 내의 어떤 동작 또는 사용자 인터페이스의 일부를 나타냅니다. 여러 개의 프래그먼트를 하나의 액티비티에 결합하여 창이 여러 개인 UI를 빌드할 수 있으며, 하나의 프래그먼트를 여러 액티비티에서 재사용할 수 있습니다. 프래그먼트는 액티비티의 모듈식 섹션이라고 생각하면 됩니다. 이는 자체적인 수명 주기를 가지고, 자체 입력 이벤트를 수신하고, 액티비티 실행 중에 추가 및 삭제가 가능합니다(다른 액티비티에 재사용할 수 있는 "하위 액티비티"와 같은 개념).


프래그먼트는 항상 액티비티 내에서 호스팅되어야 하며 해당 프래그먼트의 수명 주기는 호스트 액티비티의 수명 주기에 직접적으로 영향을 받습니다. 예를 들어 액티비티가 일시정지되는 경우, 그 안의 모든 프래그먼트도 일시정지되며 액티비티가 소멸되면 모든 프래그먼트도 마찬가지로 소멸됩니다. 그러나 액티비티가 실행 중인 동안(onResume 수명 주기 상태에 있을 경우)에는 각 프래그먼트를 추가 또는 제거하는 등 개별적으로 조작할 수 있습니다. 그와 같은 프래그먼트 트랜잭션을 수행할 때는 이를 액티비티가 관리하는 백 스택에도 추가할 수 있습니다. 각 백 스택 항목이 발생한 프래그먼트 트랜잭션의 기록이 됩니다. 이 백 스택을 사용하면 사용자가 프래그먼트 트랜잭션을 거꾸로 돌릴 수 있습니다(뒤로 이동). 이때 Back 버튼을 누르면 됩니다.


프래그먼트를 액티비티 레이아웃에 추가하면, 해당 프래그먼트는 액티비티의 뷰 계층 내에서 ViewGroup에 들어가고 자체적인 뷰 레이아웃을 정의합니다. 액티비티의 레이아웃 파일에서 <fragment> 요소로 프래그먼트를 선언하거나 기존 ViewGroup에 추가하는 방법으로 애플리케이션 코드에서 프래그먼트를 선언하면 액티비티 레이아웃에 프래그먼트를 삽입할 수 있습니다.


모범 사례 가이드를 포함한 수명 주기 처리에 대한 자세한 내용은 다음 참고 자료를 참조하세요.

수명 주기 인식 구성 요소로 수명 주기 처리

앱 아키텍처에 대한 가이드

태블릿 및 핸드셋 지원


Fragment 디자인 철학



Android가 프래그먼트를 처음 도입한 것은 Android 3.0(API 레벨 11)부터입니다. 기본적으로 태블릿과 같은 큰 화면에서 보다 역동적이고 유연한 UI 디자인을 지원하는 것이 목적이었습니다. 태블릿의 화면은 핸드셋 화면보다 훨씬 크기 때문에 UI 구성 요소를 조합하고 상호 교환할 공간이 더 많습니다. 프래그먼트는 개발자가 뷰 계층에 복잡한 변경 내용을 관리하지 않아도 이러한 디자인을 사용할 수 있도록 해줍니다. 액티비티의 레이아웃을 여러 프래그먼트로 나누면 런타임에서 액티비티의 외관을 수정할 수도 있고, 그러한 변경 내용을 해당 액티비티가 관리하는 백 스택에 보존할 수도 있습니다. 이제 프래그먼트는 Fragment suppoert library를 통해 폭넓게 제공됩니다.


예를 들어 뉴스 애플리케이션이라면 하나의 프래그먼트를 사용하여 왼쪽에 기사 목록을 표시하고, 또 다른 프래그먼트로 오른쪽에 기사 내용을 표시할 수 있습니다. 두 프래그먼트 모두 한 가지 액티비티에서 양쪽으로 나란히 나타나며, 각 프래그먼트에 나름의 수명 주기 콜백 메서드가 있고 각자 사용자 입력 이벤트를 따로 처리하게 됩니다. 따라서 사용자는 기사를 선택하는 데 하나의 액티비티를 쓰고 기사를 읽는 데 다른 액티비티를 선택하는 대신, 같은 액티비티 안에서 기사를 선택하고 읽는 과정을 모두 끝낼 수 있습니다.


각 프래그먼트는 모듈식이고 재사용 가능한 액티비티 구성 요소로 디자인해야 합니다. 다시 말해, 각 프래그먼트가 자체적인 수명 주기 콜백으로 레이아웃과 동작을 정의하기 때문에 한 프래그먼트를 여러 액티비티에 포함할 수 있습니다. 그러므로 다시 사용할 것을 염두에 두고 디자인하고 하나의 프래그먼트를 다른 프래그먼트에서 직접 조작하는 것은 삼가야 합니다. 이것이 특히 중요한 이유는 모듈식 프래그먼트를 사용하면 프래그먼트 조합을 여러 가지 화면 크기에 맞춰 변경할 수 있기 때문입니다. 태블릿과 핸드셋을 모두 지원하는 애플리케이션을 디자인하는 경우, 사용 가능한 화면 공간을 사용자 환경에서 최적화하도록 프래그먼트를 여러 레이아웃 구성에 재사용할 수 있습니다.


여러 가지 화면 구성에 맞게 여러 가지 프래그먼트 조합으로 애플리케이션을 디자인하는 법에 대한 보다 더 자세한 내용은 화면 호환성 개요에 대한 가이드를 참조 부탁드립니다.


Reference

1. https://developer.android.com/guide/components/fragments

반응형
반응형


이번 포스팅은 Android에서 Button 위젯의 배경을 투명하게 하는 방법에 대하여 알아보도록 하겠습니다.


1. 첫번째 방법은 android:background="#00ff0000" 으로 xml에 적용하는 것입니다.


<Button

        android:id="@+id/bt_confirm"

        android:layout_width="match_parent"

        android:layout_height="match_parent"

        android:background="#00ff0000" />


2. 두번째 방법은 Android 내부에 이미 선언된 transparent color를 사용하는 것입니다.


<Button

        android:id="@+id/bt_confirm"

        android:layout_width="match_parent"

        android:layout_height="match_parent"

        android:background="@android:color/transparent" />


위의 첫번째 방법과 두번째 방법이 있지만 두번째 방법의 경우 Theme 에 따라 투명도가 정상적으로 작동하지 않을 수도 있으니 참고 하시기 바랍니다.


여기에서 첫번째 방법에 사용한 "#00ff0000" 값에 대하여 궁금하신 분도 계실 수도 있어 간단하게 설명드리도록 하겠습니다.

"#" 이하부터 "00ff0000" 라는 총 8자리 문자열을 00 / ff / 00 / 00 두 자리씩 나눕니다.

- 첫번째 문자열 "00" 은  투명도를 나타냅니다. 

- 두번째 문자열 "ff" 는  적색을 나타냅니다.

- 세번째 문자열 "00" 은 녹색을 나타냅니다.

- 네번째 문자열 "00" 은 청색을 나타냅니다.


적색과 녹색, 청색의 조화로 인해 새로운 Color 가 나타나게 됩니다.


반응형
반응형

이번 포스팅은 Android KeyChain을 사용하여 대칭키를 안전하게 저장하는 방법에 대하여 알아보도록 하겠습니다.

 

Android KeyChain API를 사용하여 대칭 키를 저장하는 안전한 방법은 다음과 같습니다.

 

 

Part 1.  Key 생성 및 저장


 

1. 대칭키를 생성합니다.
2. Android Keystore에서 비대칭키를 생성합니다.
3. 2번에서 생성한 비대칭키의 공개키(Public Key) 사용하여 대칭키를 암호화합니다. 

    encrypted_symmetric_key = public_encrypt (symmetric_key)

4. 앱 내에 암호화된 대칭키를 저장합니다.

 

Part.2  대칭키를 사용 


 

원문을 암복호화할 경우에 사용합니다.

1. Android KeyStore에서 비 대칭키의 개인키(PrivateKey)를 메모리로 로드합니다.
2. 앱 내에 암호화된 대칭키를 디스크에서 로드합니다.
3. 1번에서 로드한 개인키(PrivateKey)로 암호화된 대칭키를 복호화합니다.

    symmetric_key = private_decrypt (encrypted_symmetric_key)

4. 복호화된 대칭키로 원문을 암호화 나 복호화를 진행합니다.

 

Reference

https://codeday.me/ko/qa/20190503/453287.html

반응형
반응형

이번 포스팅은 중요한(민감한) 데이터를 어떻게 Android 내에서 접근을 통제하고 요구 사항을 확인하는지 알아보도록 하겠습니다.


중요한(민감한) 데이터 Access permission

권한의 목적은 Android 사용자의 Privacy를 보호하는 것입니다.  Android 앱은 특정 시스템 기능(예: 카메라, 인터넷 등)뿐만 아니라 민감한 사용자 데이터(예: 연락처, SMS 등)에 접근할 수있는 권한을 요청해야 합니다. 기능에 따라 시스템이 자동으로 권한을 부여하거나 사용자에게 요청을 승인하도록 요청 할 수 있습니다.

Android 보안 아키텍처의 핵심 설계 포인트는 기본적으로 어떤 앱도 다른 앱, 운영 체제 또는 사용자에게 부정적인 영향을 미칠 수 있는 작업을 수행할 수 있는 권한을 가지고 있지 않다는 것입니다. 여기에는 연락처 또는 전자 메일과 같은 사용자의 개인 데이터 읽기 또는 쓰기, 다른 앱의 파일 읽기 또는 쓰기, 네트워크 액세스 수행, 장치 절전 모드 유지 등이 포함됩니다.

이 페이지에서는 Android 사용 권한이 사용자에게 제공되는 방법, 설치 시간과 런타임 사용 권한 요청 간의 차이, 사용 권한 적용 방법, 사용 권한 및 해당 그룹의 유형을 비롯하여 Android 사용 권한의 작동 방법에 대해 간략히 설명합니다. 앱 사용 권한을 사용하는 방법 안내서를 원하는 경우 대신 애플리케이션 사용 권한 요청을 참조하십시오.


허가 승인

앱은 AndroidMenifest <uses-permission> 태그를 포함하여 필요한 권한을 공개해야 합니다. 예를 들어 SMS 메시지를 보내야하는 앱은 AndroidMenifest에 다음 선언문이 있습니다.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
         
package="com.example.snazzyapp">

   
<uses-permission android:name="android.permission.SEND_SMS"/>

   
<application ...>
        ...
   
</application>
</manifest>

이 AndroidMenifest에 일반 권한 (즉, 사용자의 개인 정보 보호 또는 기기 작동에 큰 위험을 주지 않는 권한)을 표시하면 시스템은 자동으로 앱에 해당 권한을 부여합니다.

앱이 AndroidMenifest에 위의 SEND_SMS 권한과 같이 위험한 권한 (즉, 사용자의 개인 정보 보호 또는 기기의 정상적인 작동에 영향을 줄 수있는 권한)을 표시하는 사용자는 해당 권한을 부여하는 데 명시적으로 동의해야 합니다.

일반 권한 및 위험 권한에 대한 자세한 내용은 보호 수준 참조하십시오.


위험한 권한에 사용 권한을 요청

위험한 권한만 사용자 동의가 필요합니다Android가 사용자에게 위험한 사용 권한을 부여하도록 요청하는 방법은 사용자의 기기에서 실행되는 Android 버전과 앱에서 대상으로하는 시스템 버전에 따라 다릅니다.


런타임 요청 (Android 6.0 이상)

기기에서 Android 6.0(API 수준 23) 이상을 실행 중이며 앱의 targetSdkVersion 23 이상인 경우 설치 시 사용자에게 앱 사용 권한이 통보되지 않습니다. 앱은 사용자에게 런타임시 위험한 권한을 부여하도록 요청해야합니다. 앱이 권한을 요청하면 사용자에게 앱이 액세스하려는 권한 그룹을 알려주는 시스템 대화 상자가 표시됩니다. 대화 상자에는 거부  허용 버튼이 있습니다. 

사용자가 사용 권한 요청을 거부하면 다음에 앱에서 사용 권한을 요청할 때 사용자에게 사용 권한을 다시 요청하지 않음을 나타내는 확인란이 대화상자에 포함됩니다.

사용자가 다시 묻지 않음 확인란을 선택하고 거부 를 누르면 나중에 동일한 권한을 요청하려고 할 때 시스템에서 더 이상 메시지를 표시하지 않습니다.

사용자가 요청한 사용 권한을 앱에 부여하더라도 항상 앱에 의존 할 수는 없습니다. 또한 사용자는 시스템 설정에서 사용 권한을 하나씩 활성화 및 비활성화 할 수 있습니다. 런타임 오류 ( SecurityException를 방지하려면 항상 런타임시 사용 권한을 확인하고 요청해야합니다 .

런타임 사용 권한 요청을 처리하는 방법에 대한 자세한 내용은 앱 권한 요청을 참조하십시오.


런타임 요청 (Android 5.1.1 이하)

장치가 안드로이드 5.1.1 (API 레벨 22) 이하를 실행중이거나 응용 프로그램의 targetSdkVersion 이 (22) 이하인 경우 시스템은 사용자에게 설치 시 앱에 대한 모든 위험한 사용 권한을 부여하도록 자동으로 요청합니다.

사용자가 수락을 클릭하면 앱 요청에 대한 모든 사용 권한이 부여됩니다. 사용자가 권한 요청을 거부하면 시스템에서 앱 설치를 취소합니다.

앱 업데이트에 추가 사용 권한이 필요한 경우 사용자에게 앱을 업데이트하기 전에 해당 새 사용 권한을 수락하라는 메시지가 표시됩니다.

사용 권한 요청에 대한 권장되는 사용자 경험 패턴에 대한 개요는 앱 권한 모범 사례를 참조하십시오.

사용자에게 사용 권한을 확인하고 요청하는 방법에 대한 자세한 내용은 앱 사용 권한 요청을 참조하십시오.


민감한 사용자 정보에 액세스 하라는 메시지 요청

일부 앱은 통화 로그 및 SMS 메시지와 관련된 민감한 사용자 정보에 대한 액세스에 의존합니다. 로그 및 SMS 메시지를 호출하고 앱을 Play Store에 게시할 권한을 요청하려면 이러한 런타임 권한을 요청하기 전에 사용자에게 앱을 핵심시스템 기능의 기본 처리기로 설정하라는 메시지를 표시해야 합니다.

사용자에게 기본 핸들러 프롬프트 표시에 대한 지침을 포함하여 기본 핸들러에 대한 자세한 정보는 기본 핸들러에서만 사용되는 사용 권한에 대한 모범 사례를 참조하십시오. 


선택적 하드웨어 기능에 대한 사용 권한

일부 하드웨어 기능 (예 : Bluetooth 또는 카메라)에 액세스하려면 앱 사용 권한이 필요합니다. 그러나 모든 Android 기기에 실제로 이러한 하드웨어 기능을 가지고 있는 것은 아닙니다. 따라서 앱에서 CAMERA권한을 요청하는 경우 <uses-feature>태그를 AndroidMenifest에 포함하여 이 기능이 실제로 필요한지 여부를 선언하는 것이 중요합니다. 예를 들면 다음과 같습니다.

<uses-feature android:name="android.hardware.camera" android:required="false" />


android:required="false"기능 을 선언하면 Google Play에서 해당 기능이 없는 기기에 앱을 설치할 수 있습니다. 그런 다음 PackageManager.hasSystemFeature()호출하여 런타임시 현재 장치에 기능이 있는지 확인하고 해당 기능을 사용할 수 없으면 정상적으로 비활성화해야합니다.

<uses-feature>태그를 제공하지 않으면 Google Play에서 앱이 해당 사용 권한 요청을 확인하면 앱에 이 기능이 필요하다고 가정합니다. 따라서 android:required="true"태그 선언한 것처럼 기능이 없는 장치에서 앱을 필터링합니다.

자세한 내용은 Google Play 및 기능 기반 필터링 참조하십시오.


사용 권한 시행



사용 권한은 시스템 기능만을 요청하기 위한 것이 아닙니다. 앱에서 제공하는 서비스는 사용자가 지정 권한을 부여하여 누가 해당 서비스를 사용할 수 있는지 제한 할 수 있습니다. 사용자 지정 사용 권한을 선언하는 방법에 대한 자세한 내용 사용자 정의 앱 권한 정의 참조하십시오.


Activity 사용 권한 허용

android:permission속성을 사용하여 AndroidMenifest 에서 <activity> 태그에 적용된 사용 권한은 해당 속성을 시작할 수있는 사용자를 제한합니다. 사용 권한은Context.startActivity() 및 Activity.startActivityForResult()중에 점검이 됩니다. 발신자에게 필요한 권한이 없으면 호출에서 SecurityException 예외가 발생합니다.


Service 사용 권한 허용

android:permission속성을 사용하여 AndroidMenifest 에서 <service> 태그에 적용된 사용 권한은 관련 서비스를 시작하거나 바인딩할 수 있는 사용자를 제한합니다. 사용 권한은 Context.startService(), Context.stopService() 및 Context.bindService() 중에 점검이 됩니다. 발신자에게 필요한 권한이 없으면 호출에서 SecurityException 예외가 발생합니다.


BroadCast 사용 권한 허용

 android:permission 속성을 사용하여 <receiver> 태그에 적용되는 사용 권한은 연결된 BroadcastReceiver로 broadcast 보낼 수 있는 사용자를 제한합니다. 시스템이 제출된 브로드 캐스트를 지정된 수신자에게 전달하려고 시도하므로 Context.sendBroadcast()가 리턴 된 후 권한이 점검됩니다. 결과적으로 권한 실패로 인해 호출자에게 예외가 발생하지 않습니다. 그것은 단지 Intent를 전달하지 않습니다.

마찬가지로, 프로그래밍 방식으로 등록된 수신자에게 브로드캐스트할 수 있는 사용자를 제어하는 권한을 Context.registerReceiver()에 권한을 제공할 수 있습니다. 반대로 Context.sendBroadcast()를 호출 할 때 브로드 캐스트를 수신 할 수있는 브로드 캐스트 수신자를 제한하기 위해 권한을 제공 할 수 있습니다.

수신기와 브로드 캐스터 모두 권한이 필요할 수 있습니다. 이러한 상황이 발생하면 Intent가 연관된 대상으로 전달되도록 두 권한 점검을 모두 통과해야합니다. 자세한 내용은 권한이 있는 브로드 캐스트 제한을 참조하십시오.


Reference

1. https://developer.android.com/games/develop/permissions?hl=en




반응형

'Development > Security' 카테고리의 다른 글

[Security] 대칭키 암호화  (0) 2019.08.29
[Security] PKCS 정의  (0) 2019.08.29
[Security] Android Keystore 시스템  (0) 2019.08.27
[Security] Android Securely 데이터 저장  (0) 2019.08.26
[Security] Android Security Tips  (0) 2019.08.26

+ Recent posts