resolved conflicts for merge of 7008b7c1 to master

<div id="qv-wrapper">

<div id="qv">

<h2 align="left">Market filters quickview</h2>

<h2>Quickview</h2>

<ul> <li>Android Market applies filters to that let you control whether your app is shown to a

user who is browing or searching for apps.</li> 

<li>Filtering is determined by elements in an app's manifest file,

page.title=Designing for Performance

@jd:body

<p>An Android application will run on a mobile device with limited computing

power and storage, and constrained battery life. Because of

this, it should be <em>efficient</em>. Battery life is one reason you might

want to optimize your app even if it already seems to run "fast enough".

Battery life is important to users, and Android's battery usage breakdown

means users will know if your app is responsible draining their battery.</p>

<div id="qv-wrapper">

<div id="qv">

<p>This document covers these topics: </p>

<ul>

<h2>In this document</h2>

<ol>

  <li><a href="#intro">Introduction</a></li>

  <li><a href="#optimize_judiciously">Optimize Judiciously</a></li>

  <li><a href="#object_creation">Avoid Creating Objects</a></li>

  <li><a href="#library">Know And Use The Libraries</a></li>

  <li><a href="#native_methods">Use Native Methods Judiciously</a></li>

  <li><a href="#closing_notes">Closing Notes</a></li>

</ul>

</ol>

</div>

</div>

<p>An Android application will run on a mobile device with limited computing

power and storage, and constrained battery life. Because of

this, it should be <em>efficient</em>. Battery life is one reason you might

want to optimize your app even if it already seems to run "fast enough".

Battery life is important to users, and Android's battery usage breakdown

means users will know if your app is responsible draining their battery.</p>

<p>Note that although this document primarily covers micro-optimizations,

these will almost never make or break your software. Choosing the right

page.title=Designing for Responsiveness

@jd:body

<div id="qv-wrapper">

<div id="qv">

<h2>In this document</h2>

<ol>

  <li><a href="#anr">What Triggers ANR?</a></li>

  <li><a href="#avoiding">How to Avoid ANR</a></li>

  <li><a href="#reinforcing">Reinforcing Responsiveness</a></li>

</ol>

</div>

</div>

<div class="figure">

<img src="{@docRoot}images/anr.png" alt="Screenshot of ANR dialog box" width="240" height="320"/>

<p><strong>Figure 1.</strong> An ANR dialog displayed to the user.</p>

</div>

<p>It's possible to write code that wins every performance test in the world, but still sends users

in a fiery rage when they try to use the application. These are the applications that aren't

<em>responsive</em> enough &mdash; the ones that feel

sluggish, hang or freeze for significant periods, or take too long to process

input. </p>

<p>In Android, the system guards against applications that are insufficiently responsive for a

period of time by displaying a dialog to the user, called the Application Not Responding (ANR)

dialog. The user can choose to let the application continue, but the user won't appreciate having to

act on this dialog every time he or she uses your application. So it's important to design

responsiveness into your application, so that the system never has cause to display an ANR to the

user. </p>

<p>It's possible to write code that wins every performance test in the world,

but still sends users in a fiery rage when they try to use the application.

These are the applications that aren't <em>responsive</em> enough &mdash; the

page.title=Designing for Seamlessness

@jd:body

<div id="qv-wrapper">

<div id="qv">

<h2>In this document</h2>

<ol>

  <li><a href="#drop">Don't Drop Data</a></li>

  <li><a href="#expose">Don't Expose Raw Data</a></li>

  <li><a href="#interrupt">Don't Interrupt the User</a></li>

  <li><a href="#threads">Got a Lot to Do? Do it in a Thread</a></li>

  <li><a href="#multiple-activities">Don't Overload a Single Activity Screen</a></li>

  <li><a href="#themes">Extend System Themes</a></li>

  <li><a href="#flexui">Design Your UI to Work with Multiple Screen Resolutions</a></li>

  <li><a href="#network">Assume the Network is Slow</a></li>

  <li><a href="#keyboard">Don't Assume Touchscreen or Keyboard</a></li>

  <li><a href="#battery">Do Conserve the Device Battery</a></li>

</ol>

</div>

</div>

<p>Even if your application is fast and responsive, certain design decisions can

still cause problems for users — because of unplanned interactions with

other applications or dialogs, inadvertent loss of data, unintended blocking,

by allowing you to integrate cleanly and seamlessly with other applications, and

so you should design your own code to return the favor.</p>

<p>This document discusses common seamlessness problems and how to avoid them.

It covers these topics: </p>

<ul>

    <li><a href="#drop">Don't Drop Data</a></li>

    <li><a href="#expose">Don't Expose Raw Data</a></li>

    <li><a href="#interrupt">Don't Interrupt the User</a></li>

    <li><a href="#threads">Got a Lot to Do? Do it in a Thread</a></li>

    <li><a href="#multiple-activities">Don't Overload a Single Activity Screen</a></li>

    <li><a href="#themes">Extend System Themes</a></li>

    <li><a href="#flexui">Design Your UI to Work with Multiple Screen Resolutions</a></li>

    <li><a href="#network">Assume the Network is Slow</a></li>

    <li><a href="#keyboard">Don't Assume Touchscreen or Keyboard</a></li>

    <li><a href="#battery">Do Conserve the Device Battery</a></li>

</ul>

<p>This document discusses common seamlessness problems and how to avoid them.</p>

<h2 id="drop">Don't Drop Data</h2>

<div id="qv-wrapper">

<div id="qv">

  <h2>Multiple screens quickview: </h2>

  <h2>Quickview</h2>

  <ul>

    <li>Android runs on devices that have different screen sizes and resolutions.</li>

    <li>The screen on which your application is displayed can affect its user interface.</li>