Android는 터치 키보드와 같은 소프트 입력 방법 외에도 기기에 연결된 물리적 키보드도 지원합니다. 키보드는 편리한 텍스트 입력 모드와 사용자가 앱을 탐색하고 상호작용할 수 있는 방법을 제공합니다. 스마트폰과 같은 대부분의 휴대기기는 터치를 기본 상호작용 모드로 사용하지만, 태블릿 및 이와 유사한 기기의 인기가 높아지면서 많은 사용자가 키보드 액세서리를 연결하기를 좋아합니다.
이런 종류의 환경을 제공하는 Android 지원 기기가 많아짐에 따라 키보드를 통한 상호작용을 지원하도록 앱을 최적화하는 것이 중요합니다. 이 문서에서는 키보드를 사용한 탐색을 개선하는 방법을 설명합니다.
앱 테스트
Android 시스템에서 대부분의 필수 동작을 기본적으로 지원하므로 사용자가 이미 키보드를 사용하여 앱을 탐색할 수 있을 수 있습니다.
Android 프레임워크에서 제공하는 모든 대화형 위젯(예: Button 및 EditText)에 포커스를 둘 수 있습니다. 즉, 사용자는 D패드나 키보드와 같은 컨트롤 기기로 탐색할 수 있으며 각 위젯은 입력 포커스를 받으면 발광하거나 모양이 바뀝니다.
앱을 테스트하려면 다음 절차를 따르세요.
하드웨어 키보드를 제공하는 기기에 앱을 설치합니다.
키보드가 있는 하드웨어 기기가 없는 경우에는 블루투스 키보드나 USB 키보드를 연결하세요.
다음과 같은 방법으로 Android 에뮬레이터를 사용할 수도 있습니다.
AVD Manager에서 New Device를 클릭하거나 기존 프로필을 선택한 후 Clone을 클릭합니다.
창이 나타나면 Keyboard 및 DPad가 사용 설정되었는지 확인합니다.
앱을 테스트하려면 Tab 키만 사용하여 UI를 탐색합니다. 각 UI 컨트롤이 예상대로 포커스를 받는지 확인합니다.
예상치 못한 방식으로 포커스가 이동하는 경우가 있는지 확인합니다.
앱의 처음부터 다시 시작하고 키보드의 화살표 키와 같은 방향 컨트롤을 사용하여 UI를 탐색합니다. UI의 각 포커스 요소에서 위쪽, 아래쪽, 왼쪽, 오른쪽을 누릅니다.
예상치 못한 방식으로 포커스가 이동하는 경우가 있는지 확인합니다.
Tab 키나 방향 컨트롤을 사용한 탐색이 예상대로 작동하지 않는 경우를 발견하는 경우 다음 섹션의 설명대로 포커스가 레이아웃에서 어느 위치에 있어야 하는지 지정합니다.
탭 탐색 처리하기
사용자가 키보드 Tab 키를 사용하여 앱을 탐색할 때 시스템은 입력 포커스가 레이아웃에 나타나는 순서에 따라 입력 포커스를 요소 사이에 전달합니다. 예를 들어 상대적 레이아웃을 사용하는데 화면 요소의 순서가 파일에서의 순서와 다르면 포커스 순서를 수동으로 지정해야 할 수 있습니다.
예를 들어 다음 레이아웃에서는 버튼 2개가 오른쪽에 정렬되고 텍스트 필드가 두 번째 버튼 왼쪽에 정렬됩니다. 첫 번째 버튼에서 텍스트 필드로, 그런 다음 두 번째 버튼으로 포커스를 전달하려면 레이아웃에서 android:nextFocusForward 속성이 있는 각 포커스 요소의 포커스 순서를 명시적으로 정의해야 합니다.
이제 포커스가 button1에서 button2로, 그런 다음 editText1로 이동하는 대신 화면에 표시되는 방식에 따라 button1에서 editText1로, 그런 다음 button2로 적절하게 이동합니다.
방향 탐색 처리
사용자는 키보드의 화살표 키를 사용하여 앱을 탐색할 수도 있습니다. D패드나 트랙볼을 사용해 탐색할 때와 동작이 동일합니다. 시스템은 화면에 표시되는 뷰의 레이아웃을 기반으로 특정 방향으로 포커스를 맞춰야 할 뷰에 관한 '최선의 추측'을 제공합니다. 하지만 시스템의 추측이 잘못될 수도 있습니다.
특정 방향으로 탐색할 때 시스템이 적절한 뷰에 포커스를 전달하지 않는다면 다음 속성을 사용하여 포커스를 받아야 할 뷰를 지정합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-26(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-26(UTC)"],[],[],null,["# Support keyboard navigation\n\nTry the Compose way \nJetpack Compose is the recommended UI toolkit for Android. Learn how to use touch and input in Compose. \n[Focus →](/develop/ui/compose/touch-input/focus) \n\nIn addition to soft input methods---such as on-screen\nkeyboards---Android supports physical keyboards attached to the device. A\nkeyboard offers a convenient mode for text input and a way for users to\nnavigate and interact with your app. Although most hand-held devices such as\nphones use touch as the primary mode of interaction, tablets and similar\ndevices are popular, and many users like to attach keyboard accessories to\nthem.\n\nAs more Android-powered devices offer this kind of experience, it's important\nthat you optimize your app to support interaction through a keyboard. This\ndocument describes how you can improve navigation with a keyboard.\n| **Note:** Supporting directional navigation in your app is also an important part of helping ensure your app is [accessible](/guide/topics/ui/accessibility/apps) to users who don't navigate using visual cues. Fully supporting directional navigation in your app can also help you automate [user interface testing](/tools/testing/testing_ui) with tools like [UiAutomator](/tools/help/uiautomator).\n\nTest your app\n-------------\n\nUsers might already be able to navigate your app using a keyboard, because\nthe Android system enables most of the necessary behaviors by default.\n\nAll interactive widgets provided by the Android framework---such as\n[Button](/reference/android/widget/Button) and\n[EditText](/reference/android/widget/EditText)---are\nfocusable. This means users can navigate with control devices such as a D-pad or\nkeyboard, and each widget glows or otherwise changes its appearance when it\ngains input focus.\n\nTo test your app, perform the following procedure:\n\n1. Install your app on a device that offers a hardware keyboard. If you don't have a hardware device with a keyboard, connect a Bluetooth\n keyboard or a USB keyboard.\n\n You can also use the Android emulator:\n 1. In the AVD Manager, either click **New Device** or select an existing profile and click **Clone**.\n 2. In the window that appears, ensure **Keyboard** and **DPad** are enabled.\n2. To test your app, use only the \u003ckbd\u003eTab\u003c/kbd\u003e key to navigate through your UI. Make sure each UI control gets focus as expected.\n\n Look for any instances in which the focus moves in an unexpected\n manner.\n3. Start again from the beginning of your app and navigate through your UI using direction controls like the arrow keys on the keyboard. From each focusable element in your UI, press \u003ckbd\u003eUp\u003c/kbd\u003e, \u003ckbd\u003eDown\u003c/kbd\u003e, \u003ckbd\u003eLeft\u003c/kbd\u003e, and \u003ckbd\u003eRight\u003c/kbd\u003e.\n\n Look for any instances in which the focus moves in an unexpected\n manner.\n\nIf you encounter any instances where navigating with the \u003ckbd\u003eTab\u003c/kbd\u003e key\nor direction controls doesn't do what you expect, specify where the focus must\nbe in your layout, as discussed in the following sections.\n\nHandle tab navigation\n---------------------\n\nWhen a user navigates your app using the keyboard \u003ckbd\u003eTab\u003c/kbd\u003e key, the\nsystem passes input focus between elements based on the order in which they\nappear in the layout. If you use a relative layout, for example, and the order\nof elements on the screen is different than the order in the file, then you\nmight need to manually specify the focus order.\n\nFor example, in the following layout, two buttons are aligned to the right\nside, and a text field is aligned to the left of the second button. To pass\nfocus from the first button to the text field and then to the second button, the\nlayout needs to explicitly define the focus order for each of the focusable\nelements with the\n[`android:nextFocusForward`](/reference/android/view/View#attr_android:nextFocusForward)\nattribute. \n\n```xml\n\u003candroidx.constraintlayout.widget.ConstraintLayout ...\u003e\n \u003cButton\n android:id=\"@+id/button1\"\n android:nextFocusForward=\"@+id/editText1\"\n app:layout_constraintRight_toRightOf=\"parent\"\n app:layout_constraintTop_toTopOf=\"parent\"\n ... /\u003e\n \u003cButton\n android:id=\"@+id/button2\"\n android:nextFocusForward=\"@+id/button1\"\n app:layout_constraintStart_toStartOf=\"parent\"\n app:layout_constraintTop_toBottomOf=\"@id/button1\"\n ... /\u003e\n \u003cEditText\n android:id=\"@id/editText1\"\n android:nextFocusForward=\"@+id/button2\"\n app:layout_constraintBottom_toBottomOf=\"@+id/button2\"\n app:layout_constraintRight_toLeftOf=\"@id/button2\n ... /\u003e\n ...\n\u003c/androidx.constraintlayout.widget.ConstraintLayout\u003e\n```\n\nNow, instead of the focus moving from `button1` to\n`button2` and then `editText1`, it appropriately moves\naccording to the appearance on the screen: from `button1` to\n`editText1` and then `button2`.\n\nHandle directional navigation\n-----------------------------\n\nUsers can also navigate your app using the arrow keys on a keyboard, which\nbehaves the same as when navigating with a D-pad or trackball. The system\nprovides a \"best guess\" for which view to give focus to in a given direction\nbased on the layout of the views on screen. However, sometimes the system\nguesses wrong.\n\nIf the system doesn't pass focus to the appropriate view when navigating in a\ngiven direction, specify which view must receive focus with the following\nattributes:\n\n- [`android:nextFocusUp`](/reference/android/view/View#attr_android:nextFocusUp)\n- [`android:nextFocusDown`](/reference/android/view/View#attr_android:nextFocusDown)\n- [`android:nextFocusLeft`](/reference/android/view/View#attr_android:nextFocusLeft)\n- [`android:nextFocusRight`](/reference/android/view/View#attr_android:nextFocusRight)\n\nEach attribute designates the next view to receive focus when the user\nnavigates in that direction, as specified by the view ID. This is shown in the\nfollowing example: \n\n```xml\n\u003cButton\n android:id=\"@+id/button1\"\n android:nextFocusRight=\"@+id/button2\"\n android:nextFocusDown=\"@+id/editText1\"\n ... /\u003e\n\u003cButton\n android:id=\"@id/button2\"\n android:nextFocusLeft=\"@id/button1\"\n android:nextFocusDown=\"@id/editText1\"\n ... /\u003e\n\u003cEditText\n android:id=\"@id/editText1\"\n android:nextFocusUp=\"@id/button1\"\n ... /\u003e\n```\n| **Note:** Some Android views override the default navigation keys. For example, [`EditText`](/reference/android/widget/EditText) overrides the arrow keys to provide navigation within the inserted text.\n\nAdditional resources\n--------------------\n\nRefer to the following related resources:\n\n- [Build accessible apps](/training/accessibility)"]]