Hello Android Developers!

I have been working with Android for almost 2 years now, and there is one
thing that I have been looking for this entire time.  I would like to start
a thread where we can report phone specific, manufacturer specific, or even
operating-system specific issues for all of us developers to see in one
place.

I have a few notable issues that I would love to start the thread
with...but please keep adding issues to this list.

If you see an issue that you've developed a workaround for, by all means,
please share that as well!

*Issue:*
Samsung Infuse on AT&T does not clear preferences when the phone is
uninstalled, or when the user clicks "clear data" in the application
settings menu.

*Impact:*
You will want to be careful making updates to your application if you are
using SharedPreferences to store data.  If you change a preference (from an
int, to a String, for example), you will not be able to access that
preference anymore, and you application will crash when it does try to
access it.

*Workaround:*
The best way to work around this is to always create a _new_ preference,
instead of changing an existing preference.  This will ensure that you are
not trying to access dirty data when you release an updated application.

*Issue:*
LG phones have an extremely aggressive PowerManager that puts the phone
into a "deep sleep".

*Impact:*
You may notice that the notification pane doesn't get populated on some of
your users' phones.  Well, the PowerManager can be so aggressive on some of
the LG phones (most notably, the LG Revolution) that the handoff from the
AlarmManager, to your application, and finally to the NotificationManager,
gets interrupted.  The phone will fall back asleep - even if you are using
RTC_WAKEUP with your AlarmManager pending intents.

*Workaround:*
There are many good posts about how to use WakeLocks (WakefulService by
Commonsware is a great start), but the most important thing to make certain
you are doing, is to populate your AlarmManager's pending intent with a
BroadcastReceiver, instead of a Service or any other Activity.
 BroadcastReceivers are significantly less work for Android to spin up, and
gives your application a fighting chance to acquire a WakeLock and start
running like normal.

*Issue:*
Samsung Sidekick does not properly implement the ACTION_SEND intent for
text messaging.

*Impact:*
Your users will likely not be able to send/share anything via MMS/SMS from
your application.

*Workaround:*
Unknown at this time.

*Issue:*
HTC Sense phones do not properly implement the ACTION_SEND intent.

*Impact:*
If you don't take this into consideration, your users will likely not be
able to share anything via MMS/SMS from your application.

*Workaround:*
Anytime you plan on using the ACTION_SEND intent, be certain that you also
populate the chooser with the HTC_ACTION_SEND as well.
This is really easy to do, simply use the below code snippet to handle it.

final Intent chooser = Intent.createChooser(messageIntent, pickerTitle);
chooser.putExtra(Intent.EXTRA_INITIAL_INTENTS, new Intent[] {
htcMessageIntent });

Thanks for clarifying, Mark!

I agree that it's not specific to the device; however, it is definitely
more frequent (as you point out) due to the device.  My goal here is to
help others find out what their problem might be, by sharing what I've
learned in my experience.  And this is something that I learned explicitly
due to this device, and did not learn from using/testing with any of the
other 12 devices that I've been using/testing with.

*Issue:*
Carrier specific builds (MotoBlur for Verizon, for example) do not have
support for multiple locales.  The en_US locale is the default locale, and
certain settings are not supported in other locales.  For example, the
decimal separator does not switch to a "," from a "." when switching to a
locale like de_DE where the comma is the default decimal separator.

*Impact:*
Very low impact, but it may cause confusion.

*Workaround:*
No good workaround at this time.

*Issue:*
The Motorola Droid X2 has an "odd" screen resolution.  It does not fit in
well with the default screen characteristics defined by Android.  The
resolution is 960 x 540, which gives you a 5.3:3 aspect ratio.

*Impact:*
If you have "pixel perfect" UIs, you will struggle with making it look good
on the Droid X2.  This phone isn't quite an "xlarge" screen, but it's
bigger than most "large" screens.  The ratio isn't off enough to be
considered a "long" screen, either.

*Workaround:*
Be sure to use flexible layouts.  Consider defining a window background on
your UIs such that any "extra" screen that is displayed at the bottom/top
of your pixel-perfect UI is intentional, and not just the theme's default.

*Issue:*
Samsung Galaxy Spica (and variants): The GPS Location Manager does not
respond to the standard listener registration
*Impact:*
Your app will be unable to acquire a GPS fix on these devices when you use
the standard recommended code..

*Workaround:*
Use an alternative way to register the location listener.

mLocationListener = this;
new Thread() {
    @Override
    public void run() {

Looper.prepare();
locationThreadLooper = Looper.myLooper();
lm.addGpsStatusListener(onGpsStatusChange);
lm.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0,
mLocationListener, locationThreadLooper);
Looper.loop();
      }

960x540 is 16::9 and is quite common - from my very limited notes:

   - Motorola Droid X
   - Motorola Droid X2
   - HTC One S
   - HTC Sensation
   - Samsung Galaxy S III
   - Samsung Google Galaxy Nexus

All 16::9, there are more but I don't have notes on them

*Issue:*
HTC Sense UI overrode the android.R.layout.simple_list_item_1 view.
 Specifically, the layout_height is no longer "wrap_content".

*Impact:*
If you rely on the simple_list_item_1 view for any of your adapters, any
items that span the text/images/etc. onto multiple lines will get cut off.
 Sometimes, it looks like you simply don't have anything displaying, so it
creates confusion for your users.

*Workaround:*
Create a simple TextView and name it something similar like "list_item".
 The attributes of the default android.R.layout.simple_list_item_1 are as
follows...
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@android:id/text1"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:textAppearance="?android:attr/textAppearanceLarge"
    android:gravity="center_vertical"
    android:paddingLeft="6dip"    
/>

A Wiki seems like a better place than a mailing list for this, no?

Larry

While 16:9 is a common aspect ratio for TVs, displays, and monitors...it's
not a "common" ratio, or dimensions, for Android's screen qualifiers...
http://developer.android.com/guide/practices/screens_support.html#qua...

So the best you can do is create custom layouts for those combinations.

A better alternative would be to create layouts/UIs that are responsive and
look great anytime; however, sometimes our clients have very prescriptive
designs that they would like to see implemented, regardless of impact on
multiple devices.

With your additions of devices, and clarification on the ratio, it makes it
even more of an issue because pixel-perfect UI's will work less and less,
especially since the S3 and Galaxy Nexus are such popular phones!

I apologize, Larry, I didn't mean to spam your email.

If you know of an Android specific (or high density of Android Developers)
Wiki, then I would be happy to start a page in there.

Thanks!

*Issue:*
Parrot Asteroid: Android version is crippled and AudioPlayer cannot play
sounds shorter than 1 second

*Impact:*
You will not be able to use sounds that are shorter than 1 second

*Workaround:
*Extend your app sounds so they are at least 1 second long

On the contrary, I think this is an ideal place for the information to be
published, its really important that people realise that you cannot rely on
your apps always working correctly on the huge range of devices out there.
It is Android's unfortunate dirty little secret, and the more people
realise this, perhaps the more pressure will be brought onto the
manufacturers to implement the OS in a consistent way.

Duplicating the information in a wiki is a great idea, but since we are
discussing specific SDK issues with specific devices IMO it is entirely
within the remit of this group to publish such issues as they are found.

James

W dniu środa, 25 lipca 2012 23:22:41 UTC+2 użytkownik Matt Terry napisał:

Yes it is. All high end motorola phones has 16:9 ratio (854x480 - Droid
line, qHD Atrix an RAZR line), almost all high end Sony Xperia
phones  (X10, Play, Arc, Arc S, and Xperia NXT line) has aspect 16:9
(854x480). All new hide and medium range phones tends to have 1280x720 or
qHD resolution.

This phone isn't quite an "xlarge" screen, but it's bigger than most

Physical resolution doesn't defined size class, logical (or density
independent) resolution does, so saying that qHD screen "isn't quite
xlarge" is meaningless, and what's more important 16:9 is of course "long"
screen (its "longer" than common 800x480 with 16:10 aspect)

--
Bart

Device:

HTC Inredible S with 2.3, and maybe others.

Issue:

SQLite databases are opened in WAL mode.

Impact:

If the process is killed while the database is still open, the WAL file is
not deleted, and next time is appended to (rather than truncated). This
causes the file to grow larger and larger taking up more and more internal
storage space.

Now, before Mark Murphy hits me on the head with a shovel for not closing
my databases -- this affects all databases, e.g. those used by WebView (for
cache index and history) that an app has no control over.

Workaround:

Check the logging mode, set it to "truncate" if the current mode is found
to be "WAL". Check the existence of WebView-managed databases, if found,
open and close to truncate the WAL. Do it in
Application{subclaass}.onCreate.

Fixed in the 4.* update on the Incredible S, but may affect other devices.
It's probably a tempting performance tweak for manufacturers.

-- K