LineageOS/android_development
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
Files
c38796e255e1d33dddcfc992ddd830a25f88c97c
android_development/pdk/docs/compatibility/faq.jd
Dan Morrill a9788cd98f Cleaning up source.android.com files. 
This change fixes some formatting artifacts that resulted from the export from
Sites, and also updates links to no longer point to Sites and use the standard
{@docRoot} idiom. Also contains a few content updates, and introduces a page
about branch management.
2009-11-15 11:49:30 -08:00

101 lines
10 KiB
Plaintext
Raw Blame History

page.title=Frequently Asked Questions
doc.type=compatibility
@jd:body
<h3>
The CTS report shows test failures -- what should I do now?
</h3>
<div><div><b>Step 1: Get the latest CTS version.</b>
Make sure you are running the latest version of CTS -- check if your version is the same as the one posted on the <a href="http://sites.google.com/a/android.com/compatibility/download-cts">Downloads</a>
page. If not, make sure you update to the latest version and re-run CTS. As we find issues in CTS, we push out new versions with fixes to the tests and/or frame-work. Using the latest version minimizes the chances of you facing any CTS specific issues.
</div>
<div><br></div>
<div><b>Step 2: Investigate the CTS source code.</b>
Make sure you have grabbed the CTS sources provided on the <a href="http://sites.google.com/a/android.com/compatibility/download-cts">Download</a>
page. Then unzip the CTS report zip$CTS_ROOT/repository/results/start time.zipand opentestResult.xmlin your favorite browser. Find the exception next to the failing test and check the corresponding source file for possible failure causes.</div>
<div><br></div>
<div><b>Step 3: Fix the error in your source and re-run CTS.</b>
Once you have located the cause of failure in your source code, fix it and re-run CTS.
</div>
<div><br></div>
<div><b>Step 4: The test is broken.</b>
If you think the CTS test is incorrect or is not testing things the right way, shoot a detailed email to cts@android.com with the following information at the minimum - the failing test, why you think the CTS test is broken, your CTS test report and the log generated by your CTS run (text file in the$CTS_ROOT/repository/results/directory corresponding to timestamp of run).</div>
<div><br></div>
<h3>
Android 1.5 CTS r1 known issues
</h3>
<div>android.app.cts.ActivityManagerTest#testGetRunningServices - known issue test, waived automatically</div>
<div>android.graphics.cts.BitmapTest#testCopyPixelsToBuffer - can be an issue if device uses a pixel format like ARGB (4 bytes per pixel)</div>
<div>tests.api.java.io.OutputStreamWriterTest.test_write$C(OutputStreamWriterTest.java:470) - test breaks in 1.5 r3</div>
<div><br></div>
<div><b>The following tests have known issues with non en_US locales:</b>
</div>
<div>tests.api.java.io.PrintStreamTest#test_formatLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object <br>tests.api.java.io.PrintStreamTest#test_printfLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object <br>tests.api.java.io.PrintWriterTest#test_formatLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object <br>tests.api.java.io.PrintWriterTest#test_printfLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object <br>tests.api.java.util.CalendarTest#test_hashCode <br>tests.api.java.util.CalendarTest#test_getFirstDayOfWeek <br>tests.api.java.util.CalendarTest#test_getInstanceLjava_util_Locale <br>tests.api.java.util.CalendarTest#test_getInstanceLjava_util_TimeZoneLjava_util_Locale <br>tests.api.java.util.CalendarTest#test_getMinimalDaysInFirstWeek <br>tests.api.java.util.FormatterTest#test_formatLjava_lang_String$Ljava_lang_Object_ByteShortIntegerLongConversionD <br>tests.api.java.util.FormatterTest#test_formatLjava_lang_String$Ljava_lang_Object_DateTimeConversion <br>tests.api.java.util.FormatterTest#test_formatLjava_lang_String$LBigInteger <br>tests.api.java.util.FormatterTest#test_formatLjava_lang_String$Ljava_lang_Object_BigIntegerPaddingConversion <br>tests.api.java.util.FormatterTest#test_formatLjava_util_LocaleLjava_lang_StringLjava_lang_Object <br>tests.api.java.util.GregorianCalendarTest#test_ConstructorLjava_util_Locale <br>tests.api.java.util.LocaleTest#test_getDisplayCountryLjava_util_Locale <br>tests.api.java.util.LocaleTest#test_getDisplayLanguageLjava_util_Locale <br>tests.api.java.util.LocaleTest#test_getDisplayNameLjava_util_Locale <br>tests.api.java.util.ScannerTest#test_nextDouble <br>tests.api.java.util.ScannerTest#test_nextFloat <br>tests.api.java.util.ScannerTest#test_nextInt <br>tests.api.java.util.ScannerTest#test_nextIntI <br>tests.api.java.util.ScannerTest#test_nextLong <br>tests.api.java.util.ScannerTest#test_nextShortI <br>tests.api.java.util.ScannerTest#test_nextShort <br>tests.api.java.util.ScannerTest#test_nextLongI <br>tests.api.java.util.ScannerTest#test_hasNextIntI <br>tests.api.java.util.ScannerTest#test_hasNextInt <br>tests.api.java.util.ScannerTest#test_hasNextFloat <br>tests.api.java.util.ScannerTest#test_hasNextShortI <br>tests.api.java.util.ScannerTest#test_hasNextShort <br>tests.api.java.util.ScannerTest#test_hasNextLongI <br>tests.api.java.util.ScannerTest#test_hasNextLong <br>tests.api.java.util.ScannerTest#test_hasNextDouble <br>tests.api.java.util.ScannerTest#test_hasNextBigDecimal <br>tests.api.java.util.ScannerTest#test_nextBigDecimal <br>tests.api.java.util.TimeZoneTest#test_getDisplayNameLjava_util_Locale <br>tests.api.java.util.TimeZoneTest#test_getDisplayNameZILjava_util_Locale <br>org.apache.harmony.text.tests.java.text.DateFormatTest#test_getAvailableLocales <br>org.apache.harmony.text.tests.java.text.DecimalFormatSymbolsTest#test_getCurrency <br>org.apache.harmony.text.tests.java.text.DecimalFormatTest#test_formatToCharacterIteratorLjava_lang_Object <br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getInstanceLjava_util_Locale <br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_parseObjectLjava_lang_StringLjava_text_ParsePosition <br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getIntegerInstanceLjava_util_Locale <br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_formatLdouble <br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_formatLlong <br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getCurrencyInstanceLjava_util_Locale <br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getNumberInstanceLjava_util_Locale <br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getPercentInstanceLjava_util_Locale <br>org.apache.harmony.text.tests.java.text.NumberFormatTest#test_setGroupingUsed <br><br></div>
<div><br></div>
<h3>
Can I remove the 'final' modifier from classes in the Android public APIs and still be an Android-compatible device?
</h3>
<div>Let's take the following example, where you want to extend the base Contacts class to create your own version of the class. Android 1.5 supports SDK add-ons that OEMs can create to expose new functionality and platform APIs specific to the phone. However, the SDK add-on architecture does not allow the add-on provider to include their own android.jar Thus, when you expose your new Contacts class (which expects to extend the base Contacts class) developers using your add-on plugin will be unable to compile and run their applications against the standard android.jar containing the *final* Contacts class.</div>
<div><div><br></div>
<div>The recommended approach is to create a new class with the specific fields that you want to add and access these fields from the new class. This will not only ensure compatibility but will also ensure a safer and easier update path when the Android schema/implementation changes with future releases. This is illustrated in the following example:</div>
<div><div><br></div>
<div><p>public /* final */ class BaseClass {</p>
<p>/* private */ protected BaseClass() { }</p>
<br>
<p>public static final String SOME_FIELD = "base";</p>
<p>// If this is declared final, WrongApproach.java won't compile.</p>
<p>// In Contacts.People, it is not declared final (it didn't need to since the class was final)</p>
<p>public static /* final */ String frungulate() { return "foo"; }</p>
<p>}</p>
<br>
<p>public final class CorrectApproach {</p>
<p>public static final String SOME_FIELD = "some";</p>
<p>public static final String frungulate() { return "bar"; }</p>
<p>}</p>
<br>
<p>public class WrongApproach extends BaseClass {</p>
<p>public static final String SOME_FIELD = "some";</p>
<p>public static final String frungulate() { return "bar"; }</p>
<p>public static void main(String[] args) {</p>
<p>WrongApproach m = new WrongApproach();</p>
<p>System.out.println(m.SOME_FIELD);</p>
<p>System.out.println(m.frungulate());</p>
<p>// What should be done...</p>
<p>System.out.println(CorrectApproach.SOME_FIELD);</p>
<p>System.out.println(CorrectApproach.frungulate());</p>
<p>}</p>
<p>}</p>
</div>
<div></div>
</div>
</div>
<div><br></div>
<h3>
I see a failure in my report with the comment "A test that was a known failure actually passed. Please check." -- what does this mean?
</h3>
<div>A "known failure" test is one that fails when run against our own implementation on G1 or Magic, hence it gets tagged as such and does not count towards your failure. However, if the test suddenly starts passing on your implementation this is not the expected result causing it to show up as a failure then.
</div>
<div><br>You should dig into the test source to see whats happening underneath.<br><br></div>
<h3>
Why are compass and accelerometer required for Android compatibility?
</h3>
<div>Whenever possible, we try to open up hardware options by making the Android software smarter.For example, in Android 1.5 we added an Input Method Framework and soft keyboard so that devices didn't need physical text input devices.The Android <i>Donut</i>
release will the ability to scale application windows to different densities and resolutions so that devices aren't restricted to 160-180dpi HVGA displays.<br><br>Unfortunately, software can only do so much, and a compass and accelerometer are things Android cannot replace with software.These two input devices are now commonly used by applications.For example, many of the most popular applications in Android Market:<br><br>-<a href="http://www.android.com/market/featured.html#app=skymap"><i>Google Sky Map</i>
</a>
uses compass and accelerometer <br>-<a href="http://www.android.com/market/free.html#app=labyrinth"><i>Labyrinth</i>
</a>
uses accelerometer <br>-<a href="http://www.android.com/market/free.html#app=bonsaiblast"><i>Bonzai Blast</i>
</a>
uses accelerometer <br>-<a href="http://www.android.com/market/featured.html#app=wikitude"><i>Wikitude</i>
</a>
uses compass and accelerometer <br>-<a href="http://www.android.com/market/featured.html#app=zagatnru"><i>Zagat</i>
</a>
uses compass <br><br>As Market has no way of knowing whether an application uses these controls, we would not be able to filter these out of Android Market for devices which don't have the required hardware.This would create a bad user experience and could hurt the Android ecosystem if developers can no longer rely on these features in handsets, or receive bad reviews from consumers who have devices which can't support the features.<br></div>
<div><br></div>
</div>
</div>
Reference in New Issue View Git Blame Copy Permalink