Loud ramblings of a Software Artisan

Wednesday 20 June 2012

Android phone camera failure

I don't know if you noticed, but when you connect a Nexus One or a Samsung phone (Gingerbread or ICS, tested with a SGS 2 or Galaxy Note) to your Mac, the phone isn't recognized as a camera.

There is a difference between the Nexus One (stuck to Gingerbread) and the Samsung. The Nexus is USB Mass Storage (ie the phone is seen as a USB disk) while the Samsung is MTP (a variant of PTP, the USB standard for still image cameras). But in both case, the MacOS digital camera support (Image Capture, iPhoto or Aperture) recognize it but do not show anything. Adobe Lightroom is in the same boat (I'm not sure if it uses the OS capability or reimplemented it). This is because Android butcher the implementation of the Design rules for Camera Filesystem. See Android bug 2960 where you'll notice that it was largely ignored by Google despite even having a patch.

For the Nexus One this does not prevent from manually copying the images. But Samsung.... one would think they would have fixed that, but obviously they didn't. To make things worse, Samsung doesn't use Mass Storage but MTP, which mean that there is no way to just copy files from the camera[1]. That last bit is utter fail.

Update (June 21st): from the comment, apparently I can set the Galaxy Note to be as USB Mass Storage. It is complicated, needs to be done manually, require disabling USB Debugging (it will do it for you, but not reenable it), etc. In short they turned something relatively simple to something overly complex and unfriendly. Worse, it is so many to reach the dialog where like on the Nexus One, you can tap to enable Mass Storage. The positive side is that you can't enable Mass Storage without unlocking the phone, which is a security feature.

Notes

[1] unless maybe you install some tool, but anything runs better without Samsung software

Firefox Mac accessibility update

Some update about Firefox accessibility on Mac:

  • Accessibility on Mac has been disabled in Aurora 15 (and Nightly) shortly after the uplift early June. This was done because accessibility seemed to be instanciated for more than just accessibility clients, causing several unforeseen performance issues.
  • Accessibility on Mac has been re-enabled in last night Nightly 16 build for Mac. The changes are that now we whitelist VoiceOver before starting accessibility on the Mac. We also added a switch in about:config to force enable (bypass the white listing) or disable.
  • I have a current patch queue that include dealing with tab panels properly (bug 750612), text reading (bug 718625) and WAI-ARIA landmarks (bug 718700).

Using about:config: accessibility.force_disable. This option has 3 values:

  • 0 (default): do as usual
  • 1: disabled. Accessibility will not be started.
  • -1: force enabled. Accessibility will always start when requested, even without voice over.

This also works on Windows (the value -1 is unused) and soon on Linux with atk (I have to finish it)

I hope to get more rolling before we uplift Aurora 16.