Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 4c0278f4 authored by Scott Main's avatar Scott Main Committed by Android Git Automerger
Browse files

am bcad8540: am 91d60268: am a48de700: Merge "clarification to the... 

am bcad8540: am 91d60268: am a48de700: Merge "clarification to the uses-configuration tag to discourage its use." into klp-docs

* commit 'bcad8540':
  clarification to the uses-configuration tag to discourage its use.
parents b32bd76a bcad8540

docs/html/guide/topics/manifest/uses-configuration-element.jd

+44 −40
Original line number Diff line number Diff line
@@ -12,7 +12,7 @@ keyboard / navigation control / touch screen to work." But then what does "unde 
Seems like some API change is in the works, either eliminating the "no___" values or

"undefined".  Since it's unclear what the change will be, I've chosen to document the "no___"

and "undefined" attributes using the same language, which is surely wrong but may make it

easier to update the doc when the change is made. -->

easier to update the doc when the change is made... Nov 2013, this still seems unresolved. -->



<dl class="xml">

<dt>syntax:</dt>
@@ -32,20 +32,17 @@ For example, an application might specify that it requires a physical keyboard 
or a particular navigation device, like a trackball.  The specification is

used to avoid installing the application on devices where it will not work.



<p>

If an application can work with different device configurations, it 

should include separate {@code &lt;uses-configuration&gt;} declarations for 

each one.  Each declaration must be complete.  For example, if an application 

requires a five-way navigation control, a touch screen that can be operated 

with a finger, and either a standard QWERTY keyboard or a numeric 12-key

keypad like those found on most phones, it would specify these requirements

with two {@code &lt;uses-configuration&gt;} elements as follows:

</p>

<p class="note"><strong>Note: Most apps should not use this manifest tag.</strong> You should

<em>always</em> support input with a directional pad (d-pad) in order to assist sight-impaired

users and support devices that provide d-pad input in addition to or instead of touch. For

information about how to support d-pad input in your app, read <a href=

"{@docRoot}guide/topics/ui/accessibility/apps.html#focus-nav">Enabling Focus Navigation</a>. If

your app absolutely cannot function without a touchscreen, then instead use the <a href=

"{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code &lt;uses-feature&gt;}</a> tag to

declare the required touchscreen type, ranging from {@code "android.hardware.faketouch"} for basic

touch-style events to more advanced touch types such as {@code

"android.hardware.touchscreen.multitouch.jazzhand"} for distinct input from multiple fingers.</p>



<pre>&lt;uses-configuration android:reqFiveWayNav="true" android:reqTouchScreen="finger"

                    android:reqKeyboardType="qwerty" /&gt;

&lt;uses-configuration android:reqFiveWayNav="true" android:reqTouchScreen="finger"

                    android:reqKeyboardType="twelvekey" /&gt;</pre></dd>



<dt>attributes:</dt>

<dd><dl class="attr">
@@ -158,7 +155,14 @@ The value must be one of the following strings: 
   <td>The application requires a touch screen that's operated with a stylus.</td>

</tr><tr>

   <td>"{@code finger}"</td>

   <td>The application requires a touch screen that can be operated with a finger.</td>

   <td>The application requires a touch screen that can be operated with a finger.



      <p class="note"><strong>Note:</strong> If some type of touch input is required for your app,

      you should instead use the

      <a href="{@docRoot}guide/topics/manifest/uses-feature-element.html">{@code

      &lt;uses-feature>}</a> tag to declare the required touchscreen

      type, beginning with {@code "android.hardware.faketouch"} for basic touch-style events.</p>

   </td>

</tr>

</table></dd>

</dl></dd>