diff options
Diffstat (limited to 'docs/html/guide/practices')
14 files changed, 146 insertions, 167 deletions
diff --git a/docs/html/guide/practices/screens-support-1.5.jd b/docs/html/guide/practices/screens-support-1.5.jd index 9f033b4..4c6fb99 100644 --- a/docs/html/guide/practices/screens-support-1.5.jd +++ b/docs/html/guide/practices/screens-support-1.5.jd @@ -46,7 +46,7 @@ android:targetSdkVersion}</a> set to {@code "4"} or higher, then this document i default, an application written for Android 1.5 or below that does not set the <a href="{@docRoot}guide/topics/manifest/uses-sdk-element.html#target">{@code android:targetSdkVersion}</a> set to {@code "4"} or higher runs in <a -href="screen-compat-mode">screen compatibility mode</a> when on a device with a screen larger than +href="screen-compat-mode.html">screen compatibility mode</a> when on a device with a screen larger than the <em>normal</em> screen size (basically, the system displays the application in a small window that is roughly the size of the normal screen size).</p> diff --git a/docs/html/guide/practices/security.jd b/docs/html/guide/practices/security.jd index 476c301..eeaac44 100644 --- a/docs/html/guide/practices/security.jd +++ b/docs/html/guide/practices/security.jd @@ -126,8 +126,8 @@ applications.</p> <p>Use of <a href="{@docRoot}reference/android/content/Context.html#MODE_WORLD_WRITEABLE"> world writable</a> or <a -href="{@docRoot}reference/android/content/Context.html#MODE_WORLD_READABLE -">world readable</a> files for IPC is discouraged because it does not provide +href="{@docRoot}reference/android/content/Context.html#MODE_WORLD_READABLE">world +readable</a> files for IPC is discouraged because it does not provide the ability to limit data access to particular applications, nor does it provide any control on data format. As an alternative, you might consider using a ContentProvider which provides read and write permissions, and can make @@ -199,10 +199,10 @@ ContentProvider</a></code>.</p> <p>ContentProviders can also provide more granular access by declaring the <a href="{@docRoot}guide/topics/manifest/provider-element.html#gprmsn"> grantUriPermissions</a> element and using the <code><a -href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_READ_URI_PERMIS -SION">FLAG_GRANT_READ_URI_PERMISSION</a></code> and <code><a -href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_WRITE_URI_PERMI -SSION">FLAG_GRANT_WRITE_URI_PERMISSION</a></code> flags in the Intent object +href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_READ_URI_PERMISSION">FLAG_GRANT_READ_URI_PERMISSION</a></code> +and <code><a +href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_WRITE_URI_PERMISSION">FLAG_GRANT_WRITE_URI_PERMISSION</a></code> +flags in the Intent object that activates the component. The scope of these permissions can be further limited by the <code><a href="{@docRoot}guide/topics/manifest/grant-uri-permission-element.html"> @@ -211,14 +211,9 @@ grant-uri-permission element</a></code>.</p> <p>When accessing a <code> <a href="{@docRoot}reference/android/content/ContentProvider.html"> ContentProvider</a></code>, use parameterized query methods such as <code> -<a href="{@docRoot}reference/android/content/ContentProvider.html#query(android.net -.Uri,%20java.lang.String[],%20java.lang.String,%20java.lang.String[],%20java.lan -g.String)">query()</a></code>, <code><a -href="{@docRoot}reference/android/content/ContentProvider.html#update(android.ne -t.Uri,%20android.content.ContentValues,%20java.lang.String,%20java.lang.String[] -)">update()</a></code>, and <code><a -href="{@docRoot}reference/android/content/ContentProvider.html#delete(android.ne -t.Uri,%20java.lang.String,%20java.lang.String[])">delete()</a></code> to avoid +<a href="{@docRoot}reference/android/content/ContentProvider.html#query(android.net.Uri,%20java.lang.String[],%20java.lang.String,%20java.lang.String[],%20java.lang.String)">query()</a></code>, <code><a +href="{@docRoot}reference/android/content/ContentProvider.html#update(android.net.Uri,%20android.content.ContentValues,%20java.lang.String,%20java.lang.String[])">update()</a></code>, and <code><a +href="{@docRoot}reference/android/content/ContentProvider.html#delete(android.net.Uri,%20java.lang.String,%20java.lang.String[])">delete()</a></code> to avoid potential <a href="http://en.wikipedia.org/wiki/SQL_injection">SQL Injection</a> from untrusted data. Note that using parameterized methods is not sufficient if the <code>selection</code> is built by concatenating user data @@ -249,8 +244,9 @@ href="{@docRoot}reference/android/R.styleable.html#AndroidManifestActivity"> Activities</a>, and <a href="{@docRoot}reference/android/R.styleable.html#AndroidManifestService"> Services</a> are all declared in the application manifest. If your IPC mechanism is -not intended for use by other applications, set the android:exported property -to false. This is useful for applications that consist of multiple processes +not intended for use by other applications, set the <a +href="{@docRoot}guide/topics/manifest/service-element.html#exported">{@code android:exported}</a> +property to false. This is useful for applications that consist of multiple processes within the same UID, or if you decide late in development that you do not actually want to expose functionality as IPC but you don’t want to rewrite the code.</p> @@ -276,11 +272,10 @@ activity.</p> <p>Intents are the preferred mechanism for asynchronous IPC in Android. Depending on your application requirements, you might use <code><a -href="{@docRoot}reference/android/content/Context.html#sendBroadcast(android.con -tent.Intent)">sendBroadcast()</a></code>, <code><a -href="{@docRoot}reference/android/content/Context.html#sendOrderedBroadcast(andr -oid.content.Intent,%20java.lang.String)">sendOrderedBroadcast()</a></code>, or -direct an intent to a specific application component.</p> +href="{@docRoot}reference/android/content/Context.html#sendBroadcast(android.content.Intent)">sendBroadcast()</a></code>, +<code><a +href="{@docRoot}reference/android/content/Context.html#sendOrderedBroadcast(android.content.Intent,%20java.lang.String)">sendOrderedBroadcast()</a></code>, +or direct an intent to a specific application component.</p> <p>Note that ordered broadcasts can be “consumed” by a recipient, so they may not be delivered to all applications. If you are sending an Intent where @@ -311,14 +306,13 @@ and/or access controls on a specific binder interface, those controls must be explicitly added as code in the interface.</p> <p>If providing an interface that does require access controls, use <code><a -href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(ja -va.lang.String)">checkCallingPermission()</a></code> to verify whether the +href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(java.lang.String)">checkCallingPermission()</a></code> +to verify whether the caller of the Binder has a required permission. This is especially important before accessing a Service on behalf of the caller, as the identify of your application is passed to other interfaces. If invoking an interface provided by a Service, the <code><a -href="{@docRoot}reference/android/content/Context.html#bindService(android.conte -nt.Intent,%20android.content.ServiceConnection,%20int)">bindService()</a></code> +href="{@docRoot}reference/android/content/Context.html#bindService(android.content.Intent,%20android.content.ServiceConnection,%20int)">bindService()</a></code> invocation may fail if you do not have permission to access the given Service. If calling an interface provided locally by your own application, it may be useful to use the <code><a @@ -332,14 +326,14 @@ an intent.</p> <p>By default, receivers are exported and can be invoked by any other application. If your <code><a -href={@docRoot}reference/android/content/BroadcastReceiver.html"> +href="{@docRoot}reference/android/content/BroadcastReceiver.html"> BroadcastReceivers</a></code> is intended for use by other applications, you may want to apply security permissions to receivers using the <code><a -href="{@docRoot}reference/android/R.styleable.html#AndroidManifestReceiver"> +href="{@docRoot}guide/topics/manifest/receiver-element.html"> <receiver></a></code> element within the application manifest. This will prevent applications without appropriate permissions from sending an intent to the <code><a -href={@docRoot}reference/android/content/BroadcastReceiver.html"> +href="{@docRoot}reference/android/content/BroadcastReceiver.html"> BroadcastReceivers</a></code>.</p> <h3>Using Services</h3> @@ -349,19 +343,21 @@ use. Each service class must have a corresponding <service> declaration in its package's AndroidManifest.xml.</p> <p>By default, Services are exported and can be invoked by any other -application. Services can be protected using the android:permission attribute +application. Services can be protected using the <a +href="{@docRoot}guide/topics/manifest/service-element.html#prmsn">{@code android:permission}</a> +attribute within the manifest’s <code><a -href="{@docRoot}reference/android/R.styleable.html#AndroidManifestService"> +href="{@docRoot}guide/topics/manifest/service-element.html"> <service></a></code> tag. By doing so, other applications will need to declare a corresponding <code><a -href="{@docRoot}reference/android/R.styleable.html#AndroidManifestService_permis -sion"><uses-permission></a></code> element in their own manifest to be +href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a> +</code> element in their own manifest to be able to start, stop, or bind to the service.</p> <p>A Service can protect individual IPC calls into it with permissions, by calling <code><a -href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(ja -va.lang.String)">checkCallingPermission()</a></code>before executing +href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(java.lang.String)">checkCallingPermission()</a></code> +before executing the implementation of that call. We generally recommend using the declarative permissions in the manifest, since those are less prone to oversight.</p> @@ -376,9 +372,9 @@ Service to handle IPC, since this modular approach reduces the risk of exposing functionality that is not intended for use by other applications.</p> <p>If you do expose an Activity for purposes of IPC, the <code><a -href="{@docRoot}reference/android/R.styleable.html#AndroidManifestActivity_permi -ssion">android:permission</a></code> attribute in the <code><a -href="{@docRoot}reference/android/R.styleable.html#AndroidManifestActivity"> +href="{@docRoot}guide/topics/manifest/activity-element.html#prmsn">android:permission</a></code> +attribute in the <code><a +href="{@docRoot}guide/topics/manifest/activity-element.html"> <activity></a></code> declaration in the application manifest can be used to restrict access to only those applications which have the stated permissions.</p> @@ -432,8 +428,8 @@ rkeley.edu/~afelt/felt_usenixsec2011.pdf</a></p> <p>Generally, you should strive to create as few permissions as possible while satisfying your security requirements. Creating a new permission is relatively uncommon for most applications, since <a -href="{@docRoot}reference/android/Manifest.permission.html"> -system-defined permissions</a> cover many situations. Where appropriate, +href="{@docRoot}reference/android/Manifest.permission.html">system-defined +permissions</a> cover many situations. Where appropriate, perform access checks using existing permissions.</p> <p>If you must create a new permission, consider whether you can accomplish @@ -560,17 +556,14 @@ href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code> does not execute JavaScript so cross-site-scripting is not possible.</p> <p>Use <code><a -href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav -a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> with +href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> with particular care because it allows JavaScript to invoke operations that are normally reserved for Android applications. Only expose <code><a -href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav -a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to +href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to sources from which all input is trustworthy. If untrusted input is allowed, untrusted JavaScript may be able to invoke Android methods. In general, we recommend only exposing <code><a -href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav -a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to +href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to JavaScript that is contained within your application APK.</p> <p>Do not trust information downloaded over HTTP, use HTTPS instead. Even if @@ -578,13 +571,11 @@ you are connecting only to a single website that you trust or control, HTTP is subject to <a href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">MiTM</a> attacks and interception of data. Sensitive capabilities using <code><a -href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav -a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> should +href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> should not ever be exposed to unverified script downloaded over HTTP. Note that even with the use of HTTPS, <code><a -href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(jav -a.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> +href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> increases the attack surface of your application to include the server infrastructure and all CAs trusted by the Android-powered device.</p> @@ -683,8 +674,7 @@ discussed in the Requesting Permissions section.</p> <p>If a GUID is required, create a large, unique number and store it. Do not use phone identifiers such as the phone number or IMEI which may be associated with personal information. This topic is discussed in more detail in the <a -href="http://android-developers.blogspot.com/2011/03/identifying-app-installatio -ns.html">Android Developer Blog</a>.</p> +href="http://android-developers.blogspot.com/2011/03/identifying-app-installations.html">Android Developer Blog</a>.</p> <p>Application developers should be careful writing to on-device logs. In Android, logs are a shared resource, and are available @@ -724,9 +714,8 @@ credentials to the wrong application.</p> <p>If credentials are to be used only by applications that you create, then you can verify the application which accesses the <code><a href="{@docRoot}reference/android/accounts/AccountManager.html"> -AccountManager</a></code> using <code><a href="<code><a -href="{@docRoot}h/reference/android/content/pm/PackageManager.html#checkSignatur -es(java.lang.String,%20java.lang.String)">checkSignature()</a></code>. +AccountManager</a></code> using <code><a +href="{@docRoot}reference/android/content/pm/PackageManager.html#checkSignatures(java.lang.String,%20java.lang.String)">checkSignature()</a></code>. Alternatively, if only one application will use the credential, you might use a <code><a href={@docRoot}reference/java/security/KeyStore.html">KeyStore</a></code> for @@ -756,15 +745,15 @@ RSA provided in the <code><a href="{@docRoot}reference/javax/crypto/Cipher.html">Cipher</a></code> class.</p> <p>Use a secure random number generator ( -<a href="http://developer.android.com/reference/java/security/SecureRandom.html"> +<a href="{@docRoot}reference/java/security/SecureRandom.html"> <code>SecureRandom</code></a>) to initialize any cryptographic keys (<a -href="http://developer.android.com/reference/javax/crypto/KeyGenerator.html"> +href="{@docRoot}reference/javax/crypto/KeyGenerator.html"> <code>KeyGenerator</code></a>). Use of a key that is not generated with a secure random number generator significantly weakens the strength of the algorithm, and may allow offline attacks.</p> <p>If you need to store a key for repeated use, use a mechanism like <code><a -href={@docRoot}reference/java/security/KeyStore.html">KeyStore</a></code> that +href="{@docRoot}reference/java/security/KeyStore.html">KeyStore</a></code> that provides a mechanism for long term storage and retrieval of cryptographic keys.</p> diff --git a/docs/html/guide/practices/tablets-and-handsets.jd b/docs/html/guide/practices/tablets-and-handsets.jd index dc35801..3f4aaa9 100644 --- a/docs/html/guide/practices/tablets-and-handsets.jd +++ b/docs/html/guide/practices/tablets-and-handsets.jd @@ -481,7 +481,7 @@ href="{@docRoot}guide/topics/ui/actionbar.html#Home">Action Bar</a> developer gu information in each list item based on the available space. That is, you can create alternative layouts to be used by the items in your list adapter such that a large screen might display more detail for each item.</li> - <li>Create <a href="{@docRoot}guide/topics/resources/more-resources.html ">alternative resource + <li>Create <a href="{@docRoot}guide/topics/resources/more-resources.html">alternative resource files</a> for values such as integers, dimensions, and even booleans. Using size qualifiers for these resources, you can easily apply different layout sizes, font sizes, or enable/disable features based on the current screen size.</li> diff --git a/docs/html/guide/practices/ui_guidelines/activity_task_design.jd b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd index 31ad466..5faa7ec 100644 --- a/docs/html/guide/practices/ui_guidelines/activity_task_design.jd +++ b/docs/html/guide/practices/ui_guidelines/activity_task_design.jd @@ -40,7 +40,7 @@ parent.link=index.html <li><a href=#reusing_tip>Handle case where no activity matches</a></li> <li><a href=#activity_launching_tip>Consider how to launch your activities</a></li> <li><a href=#activities_added_to_task_tip>Allow activities to add to current task</a></li> - <li><a href=#notifications_get_back_tip>Notifications should let user easily get back</li> + <li><a href=#notifications_get_back_tip>Notifications and App Widgets should provide consistent back behavior</li> <li><a href=#use_notification_tip>Use the notification system</a></li> <li><a href=#taking_over_back_key>Don't take over BACK key unless you absolutely need to</a></li> </ol> @@ -1063,110 +1063,23 @@ MAIN and </p> -<h3 id="notifications_get_back_tip">Notifications should let the user easily get back to the previous activity</h3> +<h3 id="notifications_get_back_tip">Notifications and App Widgets should provide consistent back behavior</h3> <p> - Applications that are in the background or not running can have - services that send out notifications to the user letting them know about - events of interest. Two examples are Calendar, which can send out notifications of - upcoming events, and Email, which can send out notifications when new - messages arrive. One of the user interface guidelines is that when the - user is in activity A, gets a notification for activity B and - picks that notification, when they press the BACK key, they should - go back to activity A. + Notifications and app widgets are two common ways that a user can launch + your app through something besides its main icon in Launcher. You must + take care when implementing these so that the user has a consistent experience + with the back button, not causing surprises in where they return to or the + state the application ends up in. </p> <p> - The following scenario shows how the activity stack should work - when the user responds to a notification. -</p> - -<ol> - <li> - User is creating a new event in Calendar. They realize they - need to copy part of an email message into this event - </li> - <li> - The user chooses Home > Gmail - </li> - <li> - While in Gmail, they receive a notification from Calendar for an upcoming meeting - </li> - <li> - So they choose that notification, which takes them to a - dedicated Calendar activity that displays brief details of the - upcoming meeting - </li> - <li> - The user chooses this short notice to view further details - </li> - <li> - When done viewing the event, the user presses the BACK - key. They should be taken to Gmail, which is where they were - when they took the notification - </li> -</ol> - -<p> -This behavior doesn't necessarily happen by default. -</p> - -<p> -Notifications generally happen primarily in one of two ways: -</p> - - <ul> - <li> - <b>The chosen activity is dedicated for notification only</b> - - For example, when the user receives a - Calendar notification, choosing that - notification starts a special activity that displays a list - of upcoming calendar events — this view is available only - from the notification, not through the Calendar's own user - interface. After viewing this upcoming event, to ensure that - the user pressing the BACK key will return to the activity - the user was in when they picked the notification, you would - make sure this dedicated activity does not have the same - task affinity as the Calendar or any other activity. (You do - this by setting task affinity to the empty string, which - means it has no affinity to anything.) The explanation for - this follows. - - <p> - Because of the way tasks work, if the taskAffinity of the - dedicated activity is kept as its default, then pressing the - BACK key (in step 6, above) would go to Calendar, rather - than Gmail. The reason is that, by default, all activities - in a given application have the same task - affinity. Therefore, the task affinity of the dedicated - activity matches the Calendar task, which is already running - in step 1. This means in step 4, choosing the notification - brings the existing Calendar event (in step 1) forward and - starts the dedicated activity on top of it. This is not - what you want to have happen. Setting the dedicated - activity's taskAffinity to empty string fixes this. - </p> - </li> - - <li> - <b>The chosen activity is not dedicated, but always comes to - the foreground in its initial state</b> - For example, in - response to a notification, when the Gmail application comes - to the foreground, it always presents the list of conversations. - You can ensure this happens by setting a "clear top" flag in the - intent that the notification triggers. This ensures that when the - activity is launched, it displays its initial activity, preventing - Gmail from coming to the foreground in whatever state the user last - happened to be viewing it. (To do this, you put {@link - android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP - FLAG_ACTIVITY_CLEAR_TOP} in the intent you pass to startActivity()). - </li> - </ul> - -<p> - There are other ways to handle notifications, such as bringing the - activity to the foreground, set to display specific data, such as - displaying the text message thread for the person who just sent a - new text message. + The + <a href="{@docRoot}guide/topics/ui/notifiers/notifications.html#HandlingNotifications">Handling + Notifications</a> section of the developer guide's + <a href="{@docRoot}guide/topics/ui/notifiers/notifications.html">Status Bar Notifications</a> + documentation provides an overview of how to write code to correctly handle + notification. This dicussion applies equally to handling interactions with + app widgets. </p> <p> diff --git a/docs/html/guide/practices/ui_guidelines/icon_design.jd b/docs/html/guide/practices/ui_guidelines/icon_design.jd index 07b73bb..96aecf5 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design.jd @@ -57,6 +57,16 @@ Screens</a></li> </div> </div> + +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + + + <p>Creating a unified look and feel throughout a user interface adds value to your product. Streamlining the graphic style will also make the UI seem more professional to users.</p> diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_action_bar.jd b/docs/html/guide/practices/ui_guidelines/icon_design_action_bar.jd index 449c27f..2476255 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_action_bar.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_action_bar.jd @@ -29,6 +29,12 @@ Screens</a></li> </div> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> <p>Action Bar icons are graphical elements placed in the <a diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_dialog.jd b/docs/html/guide/practices/ui_guidelines/icon_design_dialog.jd index f78bd86..9b8cce7 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_dialog.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_dialog.jd @@ -27,6 +27,12 @@ Screens</a></li> </div> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> <p>Dialog icons are shown in pop-up dialog boxes that prompt the user for diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd b/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd index 3f6061c..6b686b1 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_launcher.jd @@ -26,6 +26,15 @@ Screens</a></li> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + + + <p>A launcher icon is a graphic that represents your application. Launcher icons are used by Launcher applications and appear on the user’s Home screen. Launcher icons can also be used to represent shortcuts into your application (for example, a contact shortcut icon that opens detail diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_list.jd b/docs/html/guide/practices/ui_guidelines/icon_design_list.jd index 7bf34cc..fd4dc6b 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_list.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_list.jd @@ -28,6 +28,13 @@ Screens</a></li> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + <p>List view icons look a lot like dialog icons, but they use an inner shadow effect where the light source is above the object. They are also designed to be diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_menu.jd b/docs/html/guide/practices/ui_guidelines/icon_design_menu.jd index 974e48f..e267013 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_menu.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_menu.jd @@ -32,6 +32,13 @@ Screens</a></li> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + <p>Menu icons are graphical elements placed in the options menu shown to users when they press the Menu button. They are drawn in a flat-front perspective and diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_status_bar.jd b/docs/html/guide/practices/ui_guidelines/icon_design_status_bar.jd index b8e07b5..a20c1ee 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_status_bar.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_status_bar.jd @@ -40,6 +40,13 @@ Screens</a></li> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + <p>Status bar icons are used to represent notifications from your application in the status bar.</p> diff --git a/docs/html/guide/practices/ui_guidelines/icon_design_tab.jd b/docs/html/guide/practices/ui_guidelines/icon_design_tab.jd index 271bd85..f85398d 100644 --- a/docs/html/guide/practices/ui_guidelines/icon_design_tab.jd +++ b/docs/html/guide/practices/ui_guidelines/icon_design_tab.jd @@ -32,6 +32,13 @@ Screens</a></li> </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>, including more guidelines +for <a href="{@docRoot}design/style/iconography.html">Iconography</a>.</p> +</div> + <p>Tab icons are graphical elements used to represent individual tabs in a multi-tab interface. Each tab icon has two states: unselected and selected.</p> diff --git a/docs/html/guide/practices/ui_guidelines/index.jd b/docs/html/guide/practices/ui_guidelines/index.jd index 0e42788..3255275 100644 --- a/docs/html/guide/practices/ui_guidelines/index.jd +++ b/docs/html/guide/practices/ui_guidelines/index.jd @@ -2,18 +2,28 @@ page.title=User Interface Guidelines @jd:body -<img src="{@docRoot}assets/images/uiguidelines1.png" alt="" align="right"> + +<div class="design-announce" style="background:none;overflow:auto;padding:10px 5px"> + <a href="{@docRoot}design/index.html"><img src="{@docRoot}images/home/android-design.png" alt="" +style="float:left;margin:0 1em 0 0;"/></a> +<p><strong>New Guides for App Designers!</strong></p> +<p>The Android UX team has put together a set of guidelines for the interaction and +visual design of Android applications. The new collection provides an overview of +Android styles, design patterns, building blocks for exceptional Android designs, and more.</p> +<p><strong><a href="{@docRoot}design/index.html">Android Design</a></strong></p> + +<p>Over time, the documents below will be deprecated as more design information is published at +the new location.</p> +</div> + -<p>The Android UI team has begun developing guidelines for the interaction and -visual design of Android applications. Look here for articles that describe -these guidelines as we release them.</p> <dl> <dt><a href="{@docRoot}guide/practices/ui_guidelines/icon_design.html">Icon Design Guidelines</a> and <a href="{@docRoot}shareables/icon_templates-v4.0.zip">Android Icon Templates Pack -» </a> <span class="new">updated</span></dt> +» </a></dt> <dd>Your applications need a wide variety of icons, from a launcher icon to icons in menus, dialogs, tabs, the status bar, and lists. The Icon Guidelines describe each kind of icon in detail, with specifications for the size, color, @@ -22,7 +32,8 @@ The Icon Templates Pack is an archive of Photoshop and Illustrator templates and filters that make it much simpler to create conforming icons.</dd> </dl> <dl> - <dt><a href="{@docRoot}guide/practices/ui_guidelines/widget_design.html">Widget Design Guidelines</a> <span class="new">updated</span></dt> + <dt><a href="{@docRoot}guide/practices/ui_guidelines/widget_design.html">Widget Design +Guidelines</a> </dt> <dd>A widget displays an application's most important or timely information at a glance, on a user's Home screen. These design guidelines describe how to design widgets that fit with others on the Home screen. They include links to @@ -43,7 +54,7 @@ graphics files and templates that will make your designer's life easier.</dd> <dd>Android applications make use of Option menus and Context menus that enable users to perform operations and navigate to other parts of your application or to other applications. These guidelines describe - the difference between Options and Context menus, how to arrange + the difference between Options anontext menus, how to arrange menu items, when to put commands on-screen, and other details about menu design. </dd> diff --git a/docs/html/guide/practices/ui_guidelines/widget_design.jd b/docs/html/guide/practices/ui_guidelines/widget_design.jd index f63f3c4..d789407 100644 --- a/docs/html/guide/practices/ui_guidelines/widget_design.jd +++ b/docs/html/guide/practices/ui_guidelines/widget_design.jd @@ -44,6 +44,13 @@ parent.link=index.html </div> +<div class="design-announce"> +<p><strong>New Guides for App Designers!</strong></p> +<p>Check out the new documents for designers at <strong><a +href="{@docRoot}design/index.html">Android Design</a></strong>.</p> +</div> + + <p>App widgets (sometimes just "widgets") are a feature introduced in Android 1.5 and vastly improved in Android 3.0 and 3.1. A widget can display an application's most timely or otherwise relevant information at a glance, on a user's Home screen. The standard Android system image |