Step 1: Get the latest CTS version.
Make sure you are running the latest version of CTS -- check if your version is the same as the one posted on the
Downloads
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.
Step 2: Investigate the CTS source code.
Make sure you have grabbed the CTS sources provided on the
Download
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.
Step 3: Fix the error in your source and re-run CTS.
Once you have located the cause of failure in your source code, fix it and re-run CTS.
Step 4: The test is broken.
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).
Android 1.5 CTS r1 known issues
android.app.cts.ActivityManagerTest#testGetRunningServices - known issue test, waived automatically
android.graphics.cts.BitmapTest#testCopyPixelsToBuffer - can be an issue if device uses a pixel format like ARGB (4 bytes per pixel)
tests.api.java.io.OutputStreamWriterTest.test_write$C(OutputStreamWriterTest.java:470) - test breaks in 1.5 r3
The following tests have known issues with non en_US locales:
tests.api.java.io.PrintStreamTest#test_formatLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object
tests.api.java.io.PrintStreamTest#test_printfLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object
tests.api.java.io.PrintWriterTest#test_formatLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object
tests.api.java.io.PrintWriterTest#test_printfLjava_util_Locale_Ljava_lang_String_$Ljava_lang_Object
tests.api.java.util.CalendarTest#test_hashCode
tests.api.java.util.CalendarTest#test_getFirstDayOfWeek
tests.api.java.util.CalendarTest#test_getInstanceLjava_util_Locale
tests.api.java.util.CalendarTest#test_getInstanceLjava_util_TimeZoneLjava_util_Locale
tests.api.java.util.CalendarTest#test_getMinimalDaysInFirstWeek
tests.api.java.util.FormatterTest#test_formatLjava_lang_String$Ljava_lang_Object_ByteShortIntegerLongConversionD
tests.api.java.util.FormatterTest#test_formatLjava_lang_String$Ljava_lang_Object_DateTimeConversion
tests.api.java.util.FormatterTest#test_formatLjava_lang_String$LBigInteger
tests.api.java.util.FormatterTest#test_formatLjava_lang_String$Ljava_lang_Object_BigIntegerPaddingConversion
tests.api.java.util.FormatterTest#test_formatLjava_util_LocaleLjava_lang_StringLjava_lang_Object
tests.api.java.util.GregorianCalendarTest#test_ConstructorLjava_util_Locale
tests.api.java.util.LocaleTest#test_getDisplayCountryLjava_util_Locale
tests.api.java.util.LocaleTest#test_getDisplayLanguageLjava_util_Locale
tests.api.java.util.LocaleTest#test_getDisplayNameLjava_util_Locale
tests.api.java.util.ScannerTest#test_nextDouble
tests.api.java.util.ScannerTest#test_nextFloat
tests.api.java.util.ScannerTest#test_nextInt
tests.api.java.util.ScannerTest#test_nextIntI
tests.api.java.util.ScannerTest#test_nextLong
tests.api.java.util.ScannerTest#test_nextShortI
tests.api.java.util.ScannerTest#test_nextShort
tests.api.java.util.ScannerTest#test_nextLongI
tests.api.java.util.ScannerTest#test_hasNextIntI
tests.api.java.util.ScannerTest#test_hasNextInt
tests.api.java.util.ScannerTest#test_hasNextFloat
tests.api.java.util.ScannerTest#test_hasNextShortI
tests.api.java.util.ScannerTest#test_hasNextShort
tests.api.java.util.ScannerTest#test_hasNextLongI
tests.api.java.util.ScannerTest#test_hasNextLong
tests.api.java.util.ScannerTest#test_hasNextDouble
tests.api.java.util.ScannerTest#test_hasNextBigDecimal
tests.api.java.util.ScannerTest#test_nextBigDecimal
tests.api.java.util.TimeZoneTest#test_getDisplayNameLjava_util_Locale
tests.api.java.util.TimeZoneTest#test_getDisplayNameZILjava_util_Locale
org.apache.harmony.text.tests.java.text.DateFormatTest#test_getAvailableLocales
org.apache.harmony.text.tests.java.text.DecimalFormatSymbolsTest#test_getCurrency
org.apache.harmony.text.tests.java.text.DecimalFormatTest#test_formatToCharacterIteratorLjava_lang_Object
org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getInstanceLjava_util_Locale
org.apache.harmony.text.tests.java.text.NumberFormatTest#test_parseObjectLjava_lang_StringLjava_text_ParsePosition
org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getIntegerInstanceLjava_util_Locale
org.apache.harmony.text.tests.java.text.NumberFormatTest#test_formatLdouble
org.apache.harmony.text.tests.java.text.NumberFormatTest#test_formatLlong
org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getCurrencyInstanceLjava_util_Locale
org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getNumberInstanceLjava_util_Locale
org.apache.harmony.text.tests.java.text.NumberFormatTest#test_getPercentInstanceLjava_util_Locale
org.apache.harmony.text.tests.java.text.NumberFormatTest#test_setGroupingUsed
Can I remove the 'final' modifier from classes in the Android public APIs and still be an Android-compatible device?
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.
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:
public /* final */ class BaseClass {
/* private */ protected BaseClass() { }
public static final String SOME_FIELD = "base";
// If this is declared final, WrongApproach.java won't compile.
// In Contacts.People, it is not declared final (it didn't need to since the class was final)
public static /* final */ String frungulate() { return "foo"; }
}
public final class CorrectApproach {
public static final String SOME_FIELD = "some";
public static final String frungulate() { return "bar"; }
}
public class WrongApproach extends BaseClass {
public static final String SOME_FIELD = "some";
public static final String frungulate() { return "bar"; }
public static void main(String[] args) {
WrongApproach m = new WrongApproach();
System.out.println(m.SOME_FIELD);
System.out.println(m.frungulate());
// What should be done...
System.out.println(CorrectApproach.SOME_FIELD);
System.out.println(CorrectApproach.frungulate());
}
}
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?
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.
You should dig into the test source to see whats happening underneath.
Why are compass and accelerometer required for Android compatibility?
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
Donut
release will the ability to scale application windows to different densities and resolutions so that devices aren't restricted to 160-180dpi HVGA displays.
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:
-
Google Sky Map
uses compass and accelerometer
-
Labyrinth
uses accelerometer
-
Bonzai Blast
uses accelerometer
-
Wikitude
uses compass and accelerometer
-
Zagat
uses compass
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.