| /frameworks/base/docs/html/guide/topics/resources/ |
| D | color-list-resource.jd | 24 uses various attributes to describe the state in which it should be used.</p>
97 …<dd><em>Boolean</em>. "true" if this item should be used when the object is pressed (such as when …
98 is touched/clicked); "false" if this item should be used in the default, non-pressed state.</dd>
100 …<dd><em>Boolean</em>. "true" if this item should be used when the object is focused (such as when …
101 is highlighted using the trackball/d-pad); "false" if this item should be used in the default,
104 …<dd><em>Boolean</em>. "true" if this item should be used when the object is selected (such as when…
105 tab is opened); "false" if this item should be used when the object is not selected.</dd>
107 …<dd><em>Boolean</em>. "true" if this item should be used when the object is checkable; "false" if …
108 item should be used when the object is not checkable. (Only useful if the object can
111 … <dd><em>Boolean</em>. "true" if this item should be used when the object is checked; "false" if it
[all …]
|
| /frameworks/native/cmds/flatland/ |
| D | README.txt | 11 Because it's measuring hardware performance, flatland should be run in as
12 consistent and static an environment as possible. The display should be
13 turned off and background services should be stopped before running the
17 with GPU rendering, those should be stopped as well (and ideally they'd be
20 Additionally, all relevant hardware clocks should be locked at a particular
30 time between 10 and 50 ms should address most thermal problems.
35 The output of flatland should look something like this:
69 scenario. In this case, simply rerunning flatland should yield a valid
|
| /frameworks/base/docs/html/design/wear/ |
| D | style.jd | 33 …se, your specific design may necessitate other assets. Background images should be provided in lan…
41 …should be readable in the peek state, particularly for contextual cards. Content that requires an …
56 …should be designed to be glanceable in a split second, just like reading the time on a traditional…
70 … should only be used in cases that are both timely and involve a contact, for example receiving a …
79 …should adhere to the size and color recommendations (see the UI Toolkit in the <a href="{@docRoot}…
87 …rhanging the top right edge of the card. Note that app icons or branding should not be displayed i…
91 …icons paired with values instead of text wherever possible. Text strings should be as concise as p…
|
| /frameworks/base/docs/html/training/tv/games/ |
| D | index.jd | 86 should also ensure that your Android TV game does not refer to a touch interface. For example, an
87 Android TV game should not tell a player to "<em>Tap</em> here to continue."
105 …to a good user experience. For example, you should adhere to accepted customs by using the A button
116 So, your game should query the controller and if motion detection is not
128 The Back button should never act as a toggle. For example, do not use it to both open and close a
129 menu. It should only navigate backward, breadcrumb-style, through the previous screens the player
135 Since the Back button should only perform linear (backward) navigation, you may use the back
164 When a controller is disconnected in the middle of gameplay, the game should pause, and a dialog
165 should appear prompting the disconnected player to reconnect his or her controller.
169 The dialog should also offer troubleshooting tips (for example, a pop-up dialog telling the
[all …]
|
| /frameworks/base/docs/html/training/wearables/watch-faces/ |
| D | designing.jd | 12 <h2>You should also read</h2>
41 <p>As you plan the look of your watch face and what kind of information it should present
55 <dd>Your design should work for both square and round Android Wear devices, including devices with
60 <dd>Your watch face should support ambient mode with limited color and interactive mode with
64 <dd>In ambient mode, your watch face should keep most pixels black. Depending on the screen
69 <dd>Your design should ensure that system indicators remain visible and that users can still
101 Android Wear devices with a screen density of hdpi should be 320 by 320 pixels in size to fit
104 image if the device has a lower resolution than your image. To improve performance, you should
107 <p>You should run the application code to retrieve contextual data only as often as required
112 should be relatively simple. You usually draw outlines of shapes using a limited set of colors
|
| /frameworks/native/opengl/specs/ |
| D | EGL_ANDROID_presentation_time.txt | 76 specifies the time at which the current color buffer of surface should be
77 presented to the viewer. The time parameter should be a time in
81 display device, the time should correspond to the system monotonic up-time
109 2. How can the current value of the clock that should be used for the
117 or should it be a new parameter to an extended variant of eglSwapBuffers?
119 RESOLVED: The presentation time should be new state which is used by
131 - Clarified how uses that either do or do not need an absolute time should
|
| /frameworks/base/docs/html/guide/practices/ui_guidelines/ |
| D | icon_design_action_bar.jd | 48 Screens</a>, you should create separate icons for all generalized screen densities, including low-,
71 <p>Action Bar icons should be 32-bit PNGs with an alpha channel for transparency. The finished
124 application's theme. Action Bar icons should not look three-dimensional.</p>
126 <p>In order to maintain consistency across the application's Action Bar, all Action Bar icons should
129 <p>When using the default "Holo Light" or "Holo Dark" themes, icons should use the color palette
147 <tr><td><em>2.</em></td><td nowrap>Inner content:</td><td>Inner content should subtract from
169 <tr><td><em>2.</em></td><td nowrap>Inner content:</td><td>Inner content should subtract from
172 <p class="note"><strong>Note: </strong> icons should should have a transparent background;
189 you should not reference built-in icons using the Android platform resource IDs (i.e. menu or Action
191 drawable resources, you should store a local copy of those icons or drawables in your application
|
| D | icon_design_launcher_archive.jd | 52 Density-Specific Icon Sets</a>, you should create separate icons for low-,
86 <p>Starting with Android 2.0, launcher icons should be front-facing, instead of
92 <p>The launcher icons that you create should follow the general style principles
109 <li>Launcher icons should be modern and sometimes quirky; they should not
110 appear aged or ragged. You should avoid overused symbolic metaphors whenever
116 <li>Android Launcher icons are caricatural in nature; your icons should be
118 sizes. Your icons should not be overly complicated. </li>
124 <li>Your icons <em>should not</em> present a cropped view of a larger
130 <li>Icons should feature non-glossy, textured material. See
138 icons should be forward-facing, with very little perspective, and they
[all …]
|
| D | icon_design_launcher.jd | 47 Screens</a>, you should create separate icons for all generalized screen densities, including low-,
92 app is about. Thus, you should:</p>
123 app widgets. To do this, icons should:</p>
133 …<li>Have a unique silhouette for faster recognition; not all Android app icons should be square. <…
134 <li>Icons should not present a cropped view of a larger image.</li></ul>
152 <td style="border:0; vertical-align:middle">Icons should not be overly complicated. Remember
153 that launcher icons will be used at often small sizes, so they should be distinguishable at
160 <td style="border:0; vertical-align:middle">Icons should not be cropped. Use unique shapes
161 where appropriate; remember that launcher icons should differentiate your application from
169 <td style="border:0; vertical-align:middle">Icons should not be thin. They should have a
[all …]
|
| D | icon_design_tab.jd | 48 Density-Specific Icon Sets</a>, you should create separate icon sets for low-,
67 provide support for all Android versions</strong>, developers should:
78 This will inform the system that it should render tabs using the new tab style.
85 <p>Tab icons should have two states: unselected and selected. To provide icons
117 <p>The contents of the XML files listed above should reference the corresponding
143 <p>Tab icons should use simple shapes and forms and those must be
147 asset. You should size the icons <em>smaller than the actual bounds of the
232 <p>Tab icons should have two states: selected and unselected.</p>
243 …<p><em>Note: all pixel dimensions are for medium density and should be scaled appropriately for ot…
246 …<tr><td><em>2.</em></td><td nowrap>Inner content:</td><td>Inner content should subtract from the o…
[all …]
|
| /frameworks/base/docs/html/training/basics/supporting-devices/ |
| D | screens.jd | 18 <h2>You should also read</h2>
29 <p>Android categorizes device screens using two general properties: size and density. You should
31 and density. As such, you should include some alternative resources that optimize your app’s
45 screen size, so many apps should revise the layout to optimize the user experience in each
51 <p>To optimize your user experience on different screen sizes, you should create a unique layout XML
52 file for each screen size you want to support. Each layout should be
54 suffix. For example, a unique layout for large screens should be saved under
134 <p>You should always provide bitmap resources that are properly scaled to each of the generalized
138 <p>To generate these images, you should start with your raw resource in vector format and generate
147 <p>This means that if you generate a 200x200 image for xhdpi devices, you should generate the same
|
| /frameworks/base/docs/html/training/testing/integration-testing/ |
| D | content-provider-testing.jd | 26 <h2>You should also read</h2>
37 accessible to other apps, you should test your provider to ensure that it doesn't behave in an
46 For this reason, you should write your tests based only on the provider's public members.
53 do not modify actual user data. For example, you should avoid writing a test that fails because
54 there was data left over from a previous test. Similarly, your test should avoid adding or deleting
65 <p>Your integration test should be written as a JUnit 4 test class. To learn more about creating
136 {@link android.test.ProviderTestCase2}, you should always test with a resolver object
142 available to other applications, you should test it as a contract. Some examples of how to
148 data tables. These should always be constants publicly defined by the provider.
155 Test invalid URIs: Your unit tests should deliberately call the provider with an
[all …]
|
| /frameworks/base/tools/orientationplot/ |
| D | README.txt | 53 point in between the two orientations; that is the gap. The gap should be
59 There should be no gap observed initially. The algorithm should pick one
62 settles, the confidence values should start trending to 0 again because
72 should be a fairly constant 60ms. If the latency jumps around wildly or
77 degrees (refer to MAX_TILT constant). Consequently, you should expect there
85 6. Orientation changes should be significantly harder when the device is held
|
| /frameworks/base/docs/html/training/basics/activity-lifecycle/ |
| D | pausing.jd | 18 <h2>You should also read</h2>
45 you to stop ongoing actions that should not continue while paused (such as a video) or persist
46 any information that should be permanently saved in case the user continues to leave your app. If
66 the user is leaving the activity and it will soon enter the Stopped state. You should usually use
95 <p>Generally, you should <strong>not</strong> use {@link android.app.Activity#onPause()} to store
97 you should persist user changes to permanent storage within {@link android.app.Activity#onPause()}
99 However, you should avoid performing CPU-intensive work during {@link
101 transition to the next activity (you should instead perform heavy-load shutdown operations during
104 <p>You should keep the amount of operations done in the {@link android.app.Activity#onPause
121 including when it's created for the first time. As such, you should implement {@link
|
| /frameworks/base/docs/html/training/managing-audio/ |
| D | audio-focus.jd | 25 <h2>You should also read</h2>
34 <p>With multiple apps potentially playing audio it's important to think about how they should
36 audio playback—only apps that hold the audio focus should play audio.</p>
38 <p>Before your app starts playing audio it should request—and receive—the audio focus.
39 Likewise, it should know how to listen for a loss of audio focus and respond appropriately when that
45 <p>Before your app starts playing any audio, it should hold the audio focus for the stream
55 <p>The following snippet requests permanent audio focus on the music audio stream. You should
126 <p>Generally speaking, a transient (temporary) loss of audio focus should result in your app
127 silencing it’s audio stream, but otherwise maintaining the same state. You should continue to
132 listen to audio and your app should effectively end itself. In practical terms, that means stopping
|
| D | index.jd | 19 <h2>You should also read</h2>
42 These should be short and to the point. It should be clear from reading the summary whether someone
53 <dd>With multiple apps potentially playing audio it's important to think about how they should
|
| /frameworks/av/include/cpustats/ |
| D | README.txt | 5 * should be related to CPU usage statistics
6 * should be portable to host; avoid Android OS dependencies without a conditional
|
| /frameworks/wilhelm/doc/ |
| D | README.txt | 1 When building applications using the OpenSL-ES API you should compile and link the OpenSLES_IID.c f…
2 have been automatically generated. Application developers should not edit these interface IDs.
|
| /frameworks/base/docs/html/guide/topics/media/ |
| D | mediaplayer.jd | 121 try to parse in any particular way. However, the content of this resource should not
122 be raw audio. It should be a properly encoded and formatted media file in one
161 method that may take long to execute, you should <strong>never call it from your
182 <p>Another aspect of a {@link android.media.MediaPlayer} that you should keep in mind is
192 state. At that point, you should initialize it by calling
219 Therefore, you should always take extra precautions to make sure you are not
221 are done with it, you should always call
232 <p>Here's how you should release and then nullify your {@link android.media.MediaPlayer}:</p>
262 You should be careful about this setup, because the user and the system have expectations
263 about how an application running a background service should interact with the rest of the
[all …]
|
| /frameworks/base/docs/html/training/design-navigation/ |
| D | index.jd | 13 …ocused and does not require knowledge of the Android SDK. That said, you should have experience us…
15 <p>You should also have basic familiarity with the Action Bar (<a href="{@docRoot}design/patterns/a…
24 … chronological order. After going through the lessons in this class, you should be able to apply t…
33 … how to choose which screens your application should contain. Also learn how to choose which scree…
|
| /frameworks/base/docs/html/training/ |
| D | best-ux.jd | 10 in your app, your app should match their expectations for user interaction on Android.
11 And to keep your users coming back, you should take advantage of
|
| /frameworks/base/docs/html/training/articles/ |
| D | perf-anr.jd | 55 <strong>you should not perform the work on the UI thread</strong>, but instead create a
85 <p>Therefore, any method that runs in the UI thread should do as little work
86 as possible on that thread. In particular, activities should do as little as possible to set
91 resizing bitmaps should be done in a worker thread (or in the case of databases
141 you should set the thread priority to "background" priority by calling {@link
151 thread to complete, your main thread should provide a {@link
161 called in the UI thread, applications should avoid potentially long-running
164 application should start an {@link android.app.IntentService} if a
179 are some additional tips beyond what you should do to avoid ANR and
192 loading is in progress and fill the information asynchronously. In either case, you should
|
| /frameworks/base/docs/html/design/tv/ |
| D | style.jd | 55 display correctly. On a 1920 x 1080 screen, this margin should be a minimum of 27 pixels
68 TV screens. Some color gradient combinations will show bands. You should avoid pure whites on
70 should review them when used to fill significant areas of the screen. You
71 should also avoid using very dark or muddy colors, as TV settings may display these colors with
77 <p>The text and controls in a TV application's UI should be easily visible and navigable from a
78 distance. The minimum recommended font size for TV is 12sp. The default text size setting should
92 Therefore you should avoid thin or light typefaces on TV.</p>
|
| /frameworks/base/docs/html/google/play/billing/ |
| D | billing_promotions.jd | 109 To support promotion codes, your app should call the <a href=
132 In addition, your app should allow users to redeem promo codes inside the app
141 purchase was completed. However, your app should still call <a href=
153 Your app should also support the scenario where a user redeems a promo code
175 method should call <a href=
182 Your activity's {@link android.app.Activity#onPause onPause()} method should
190 <strong>Note:</strong> You should not register this broadcast receiver in the
194 user. Instead, your app should call <a href=
204 If your app supports in-app promotions, you should test the following use
225 possible workflows. You should verify each one of these.
[all …]
|
| /frameworks/base/docs/html/preview/ |
| D | guide.jd | 24 your app with the preview, there are some specific system changes that you should focus on to
29 This guide describes the what and how to test preview features with your app. You should
65 should begin planning your app’s migration to the new permissions model now, with a goal of
98 the user experience and flows you provide to users. You should assess your app’s current
100 the platform provides compatibility behavior, but you should plan on updating your app and not
107 testing on the new platform and code analysis. In testing, you should focus on opting in to
115 depend on permissions. Where a dependency is not obvious or logical you should consider
134 that your app behaves properly with these power saving optimizations, you should test your app by
180 from standby mode. In particular, you should check if your app's Notifications and background
|