from:"blindfold"

I'm not getting any sound with the Android 3.0 (Honeycomb, final) SDK
emulator. I have no such problem with the Android 2.2 and 2.3.1
emulators. This is on Windows 7 64-bit. I have all volume sliders up.
Anyone else having this problem?

Thanks

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: No sound with Android 3.0 emulator?

I should add that I do get sound also with the Android 3.0 *preview*
emulator, but just not with the new final Android 3.0 emulator. I
rebooted my system because the new emulator appears to be doing some
heavy caching judging from the quick startup after a first run, but to
no avail. What can one do? Is it a new bug?

On Feb 23, 9:26 am, blindfold seeingwithso...@gmail.com wrote:
 I'm not getting any sound with the Android 3.0 (Honeycomb, final) SDK
 emulator. I have no such problem with the Android 2.2 and 2.3.1
 emulators. This is on Windows 7 64-bit. I have all volume sliders up.
 Anyone else having this problem?

 Thanks

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: No sound with Android 3.0 emulator?

Problem solved! The trick for me was to delete the huge (in my case
close to 1 GB) cache file snapshots.img that the new emulator had
created in my AVD folder for the Android 3.0 emulator - because I had
selected the corresponding snapshot checkbox while defining a new
AVD. Unlike a system reboot, this forced a clean restart of the
emulator (taking much longer, obviously), and next I had sound. I now
made a new Android 3.0 AVD with the snapshot checkbox not selected,
and things are fine now.

I suspected that the new emulator with the snapshot option turned on
also cached whatever PC audio device it had found and selected upon a
first run, such that if it goes wrong there one is stuck without
audio. However, creating yet another AVD with the snapshot option
turned on for some reason again gave me the same no-sound problem that
I had before, so it looks like using the snapshot option consistently
causes problems with the audio device. I did not further investigate
though.

On Feb 23, 10:07 am, blindfold seeingwithso...@gmail.com wrote:
 I should add that I do get sound also with the Android 3.0 *preview*
 emulator, but just not with the new final Android 3.0 emulator. I
 rebooted my system because the new emulator appears to be doing some
 heavy caching judging from the quick startup after a first run, but to
 no avail. What can one do? Is it a new bug?

 On Feb 23, 9:26 am, blindfold seeingwithso...@gmail.com wrote:

  I'm not getting any sound with the Android 3.0 (Honeycomb, final) SDK
  emulator. I have no such problem with the Android 2.2 and 2.3.1
  emulators. This is on Windows 7 64-bit. I have all volume sliders up.
  Anyone else having this problem?

  Thanks

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: No sound with Android 3.0 emulator?

 Can I ask you to file a bug at b.android.com with the text you just wrote 
 here?

I was about to, but it seems that the behavior is a bit erratic. For
final checking before filing a bug I just made yet another AVD with
the snapshot feature checked, and this time it did give sound. So I'm
not sure anymore what the pattern is, while it is too time-consuming
to do any statistics on creating AVDs under Android 3.0, so I'd rather
wait now if other group members experience similar issues before
filing a bug report.

Thanks

On Feb 23, 4:28 pm, David Turner di...@android.com wrote:
 Thanks a lot for this information. Can I ask you to file a bug at
 b.android.com with the text you just wrote here?
 It will help us track the issue for a future fix.

 Thanks

 On Wed, Feb 23, 2011 at 11:00 AM, blindfold seeingwithso...@gmail.comwrote:

  Problem solved! The trick for me was to delete the huge (in my case
  close to 1 GB) cache file snapshots.img that the new emulator had
  created in my AVD folder for the Android 3.0 emulator - because I had
  selected the corresponding snapshot checkbox while defining a new
  AVD. Unlike a system reboot, this forced a clean restart of the
  emulator (taking much longer, obviously), and next I had sound. I now
  made a new Android 3.0 AVD with the snapshot checkbox not selected,
  and things are fine now.

  I suspected that the new emulator with the snapshot option turned on
  also cached whatever PC audio device it had found and selected upon a
  first run, such that if it goes wrong there one is stuck without
  audio. However, creating yet another AVD with the snapshot option
  turned on for some reason again gave me the same no-sound problem that
  I had before, so it looks like using the snapshot option consistently
  causes problems with the audio device. I did not further investigate
  though.

  On Feb 23, 10:07 am, blindfold seeingwithso...@gmail.com wrote:
   I should add that I do get sound also with the Android 3.0 *preview*
   emulator, but just not with the new final Android 3.0 emulator. I
   rebooted my system because the new emulator appears to be doing some
   heavy caching judging from the quick startup after a first run, but to
   no avail. What can one do? Is it a new bug?

   On Feb 23, 9:26 am, blindfold seeingwithso...@gmail.com wrote:

I'm not getting any sound with the Android 3.0 (Honeycomb, final) SDK
emulator. I have no such problem with the Android 2.2 and 2.3.1
emulators. This is on Windows 7 64-bit. I have all volume sliders up.
Anyone else having this problem?

Thanks

  --
  You received this message because you are subscribed to the Google
  Groups Android Developers group.
  To post to this group, send email to android-developers@googlegroups.com
  To unsubscribe from this group, send email to
  android-developers+unsubscr...@googlegroups.com
  For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: No sound with Android 3.0 emulator?

OK, filed anyway: http://code.google.com/p/android/issues/detail?id=14953
after I observed that I did get sound upon the first launch of a new
AVD with the snapshot feature, and no sound upon a second launch of
this same AVD (which is way faster). I cannot vouch that this pattern
is entirely reproducible though.

On Feb 23, 4:28 pm, David Turner di...@android.com wrote:
 Thanks a lot for this information. Can I ask you to file a bug at
 b.android.com with the text you just wrote here?
 It will help us track the issue for a future fix.

 Thanks

 On Wed, Feb 23, 2011 at 11:00 AM, blindfold seeingwithso...@gmail.comwrote:

  Problem solved! The trick for me was to delete the huge (in my case
  close to 1 GB) cache file snapshots.img that the new emulator had
  created in my AVD folder for the Android 3.0 emulator - because I had
  selected the corresponding snapshot checkbox while defining a new
  AVD. Unlike a system reboot, this forced a clean restart of the
  emulator (taking much longer, obviously), and next I had sound. I now
  made a new Android 3.0 AVD with the snapshot checkbox not selected,
  and things are fine now.

  I suspected that the new emulator with the snapshot option turned on
  also cached whatever PC audio device it had found and selected upon a
  first run, such that if it goes wrong there one is stuck without
  audio. However, creating yet another AVD with the snapshot option
  turned on for some reason again gave me the same no-sound problem that
  I had before, so it looks like using the snapshot option consistently
  causes problems with the audio device. I did not further investigate
  though.

  On Feb 23, 10:07 am, blindfold seeingwithso...@gmail.com wrote:
   I should add that I do get sound also with the Android 3.0 *preview*
   emulator, but just not with the new final Android 3.0 emulator. I
   rebooted my system because the new emulator appears to be doing some
   heavy caching judging from the quick startup after a first run, but to
   no avail. What can one do? Is it a new bug?

   On Feb 23, 9:26 am, blindfold seeingwithso...@gmail.com wrote:

I'm not getting any sound with the Android 3.0 (Honeycomb, final) SDK
emulator. I have no such problem with the Android 2.2 and 2.3.1
emulators. This is on Windows 7 64-bit. I have all volume sliders up.
Anyone else having this problem?

Thanks

  --
  You received this message because you are subscribed to the Google
  Groups Android Developers group.
  To post to this group, send email to android-developers@googlegroups.com
  To unsubscribe from this group, send email to
  android-developers+unsubscr...@googlegroups.com
  For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Honeycomb SDK

2011-02-07 Thread blindfold

Yes I hope they will fix that for the final Honeycomb SDK, because
currently I need to recompile for either

uses-sdk android:minSdkVersion=4/
uses-sdk android:targetSdkVersion=Honeycomb/

giving me the conventional (Android 2.3-) phone appearance in the
Honeycomb emulator, or

uses-sdk android:minSdkVersion=Honeycomb/
uses-sdk android:targetSdkVersion=Honeycomb/

for the holographic appearance in the Honeycomb emulator. What I want
of course is to have one APK that is backward compatible to (in my
case) minSdkVersion=4 and that shows the holographic UI on tablets
or phones that run Honeycomb. I do not need to change anything in my
code but these manifest changes to get there, so it is very
inconvenient to forbid uses-sdk android:minSdkVersion=4/uses-sdk
android:targetSdkVersion=Honeycomb/ when aiming to get the
holographic appearance on Honeycomb  devices and the conventional
Android 2.3- UI on non-Honeycomb  devices.

On Feb 7, 8:54 am, Marcin Orlowski webnet.andr...@gmail.com wrote:
 On 7 February 2011 00:57, midtoad stewart.midwin...@gmail.com wrote:

  You will then get the Honeycomb Holograph them and your app will have
  an updated look and feel.

 http://developer.android.com/sdk/preview/index.html

 Android 3.0 offers an updated set of UI widgets that are redesigned
 for use on larger screens such as tablets and incorporate the new
 holographic theme. Your existing application can inherit the new
 design simply by setting the uses-sdk element's
 android:targetSdkVersion attribute to Honeycomb.

 If you do not update the android:targetSdkVersion attribute and the
 android:minSdkVersion is set to 9 or lower, then your application
 uses the widget designs from Android 2.3 and does not inherit the
 holographic theme.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Honeycomb SDK

2011-02-07 Thread blindfold

Ah yes, of course, for now (in my case) with the preview SDK uses-sdk
android:minSdkVersion=4 android:targetSdkVersion=Honeycomb/ and
soon with the final SDK uses-sdk android:minSdkVersion=4
android:targetSdkVersion=11/. Thank you, Dianne.

On Feb 7, 7:06 pm, Dianne Hackborn hack...@android.com wrote:
 You are using this wrong.  Both attributes need to be in a single uses-sdk
 tag.

 The rule is simple: if the targetSdkVersion is Honeycomb, then you get the
 new Honeycomb behavior.  (Note this is the exact same way this has worked
 forever, as documented by android.os.Build.VERSION_CODES about the changes
 in behavior you get as you target later platform versions.)

 This SDK is a preview, without final APIs, so its SDK version is a codename
 since code you write with it is by definition not tested on final builds.
  Once the final SDK is available, that will have an actual API version
 number for Honeycomb.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Emulator with disabled camera still has camera?

2011-02-05 Thread blindfold

It looks like the emulator currently only supports one default
hardware configuration for hasSystemFeature()
http://code.google.com/p/android/issues/detail?id=11682 which indeed
is inconvenient for emulating/testing app behavior for different
hardware configurations.

On Feb 4, 8:42 pm, Manfred Moser mosa...@gmail.com wrote:
 Hi!

 I want to test that my app behaves correctly without camera support but I
 have no device without camera. So I created a avd with Camer support set to
 no.

 However when I run the emulator this call still returns true

 public boolean hasCamera() {
         PackageManager packageManager = application.getPackageManager();
         return
 packageManager.hasSystemFeature(PackageManager.FEATURE_CAMERA);
     }

 Is this a bug in the emulator that I should report or am I missing
 something?

 thx

 manfred

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] APIs for stereoscopic camera support in Android 3.0?

2011-02-02 Thread blindfold

Apparently, some Honeycomb (Android 3.0) tablets like the T-Mobile G-
Slate are coming out with dual rear-facing cameras for stereoscopic
video recording
http://www.androidpolice.com/2011/02/01/t-mobile-releases-details-and-images-of-the-lg-g-slate-honeycomb-tablet/

I'd like to do some depth mapping and other real-time processing of
the live stereo video feed, but cannot find the relevant APIs for
working with stereoscopic camera input in the Android 3.0 Preview SDK.
Am I missing something, is it coming with the final Android 3.0 SDK,
or is this again a manufacturer's proprietary extension that is not
(yet) covered by an official Android 3.0? I know that Android 3.0 has
support for multiple cameras, but that is here insufficient to tell
for instance which cameraId represents the left camera and which
cameraId represents the right camera. Camera.CameraInfo currently only
offers CAMERA_FACING_BACK and CAMERA_FACING_FRONT, which is irrelevant
here. In the Preview SDK there is no
Camera.CameraInfo.CAMERA_FACING_LEFT or
Camera.CameraInfo.CAMERA_FACING_RIGHT or generalization thereof as
needed to prevent a possible fragmentation of conventions.

Thanks!


The vOICe for Android
http://www.seeingwithsound.com/android.htm

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] System Bar location and height in Honeycomb?

2011-01-27 Thread blindfold

How can I find the location (bottom or top) and height of the System
Bar (status bar) in Honeycomb?

In compatibility testing of my app I find that I get some vertical
offsets in screen locations wrong in Honeycomb, apparently because I
did not yet account for the System Bar at the bottom of the screen in
Honeycomb.

Thanks!

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: System Bar location and height in Honeycomb?

2011-01-27 Thread blindfold

Thank you, Dianne. Yes we can - for better or for worse. I have a
graphical screen where I track touch locations through getRawY() in
relation to my graphics. However, in the mean-time I already fixed my
problem using getLocationOnScreen() for my main view, such that along
with its getHeight() I do know both bottom and top absolute
coordinates. Perhaps an appalling approach, but it now works fine for
both the new Honeycomb UI and Android 2.3-. Problem solved.

On Jan 27, 6:24 pm, Dianne Hackborn hack...@android.com wrote:
 You can't.  Don't use Display.getWidth()/Height(), and you will be fine.
  This is one of the reasons I have been saying for years to not use the raw
 Display dimensions to do UI layout.

 If you aren't using Display to get dimensions, some more details about you
 are doing are needed.  Apps will never be given any space on the screen that
 infringes on the system bar or otherwise have any idea it is there.

 On Thu, Jan 27, 2011 at 3:29 AM, blindfold seeingwithso...@gmail.comwrote:



  How can I find the location (bottom or top) and height of the System
  Bar (status bar) in Honeycomb?

  In compatibility testing of my app I find that I get some vertical
  offsets in screen locations wrong in Honeycomb, apparently because I
  did not yet account for the System Bar at the bottom of the screen in
  Honeycomb.

  Thanks!

  --
  You received this message because you are subscribed to the Google
  Groups Android Developers group.
  To post to this group, send email to android-developers@googlegroups.com
  To unsubscribe from this group, send email to
  android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
  For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 --
 Dianne Hackborn
 Android framework engineer
 hack...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support, and so won't reply to such e-mails.  All such
 questions should be posted on public forums, where I and others can see and
 answer them.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Wake locks and camera

2011-01-26 Thread blindfold

Thank you, Dianne, that confirms my experimental observations with the
camera. For the future it would seem better and less heuristically
defined to decouple camera use from screen use, because it allows for
(modest) power savings in computer vision applications that send/store
their output elsewhere. However, it is not a major issue as long as
the camera is a main power hog.

I need a wake lock to keep the other sensors for location (GPS) and
orientation active, although with Android 2.2 orientation readings
still fail in standby due to issue 11028 
http://code.google.com/p/android/issues/detail?id=11028
despite using a wake lock. This is reportedly fixed with Android 2.3.

Thanks!

On Jan 26, 12:14 am, Dianne Hackborn hack...@android.com wrote:
 I believe the only way to ensure the camera continues operating is to keep
 the screen on.  All you need to do is keep the screen on, you don't need to
 hold a wake lock.

 On Tue, Jan 25, 2011 at 1:00 PM, blindfold seeingwithso...@gmail.comwrote:



  I noticed that in Android 2.2 and earlier I must do either a
  FULL_WAKE_LOCK or a combination of PARTIAL_WAKE_LOCK and
  FLAG_KEEP_SCREEN_ON to make sure the camera does not get turned off
  after a while with my app in the foreground (and I need a wake lock to
  keep GPS going). The underlying assumption seems to be that the camera
  is not useful when the screen is off, but that assumption is false for
  computer vision applications where not the user but the program is
  watching the camera view. Is this fixed in Android 2.3 (Gingerbread)?

  Thanks

  --
  You received this message because you are subscribed to the Google
  Groups Android Developers group.
  To post to this group, send email to android-developers@googlegroups.com
  To unsubscribe from this group, send email to
  android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
  For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 --
 Dianne Hackborn
 Android framework engineer
 hack...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support, and so won't reply to such e-mails.  All such
 questions should be posted on public forums, where I and others can see and
 answer them.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Force Close Does Not Release Camera Resource

2011-01-26 Thread blindfold

Indeed this is an old known issue (1578) 
http://code.google.com/p/android/issues/detail?id=1578
and only restarting the phone helps. You can try to  minimize
occurrences by properly releasing the camera yourself when an
exception occurs in your app.

On Jan 25, 10:41 pm, Joe McCann joseph.is...@gmail.com wrote:
 So while developing a custom camera application I've realized on rare
 occasions and on various devices if the app has to force close, it
 does not always release the camera resource.

 Is there a way to find/detect the process that is holding onto this
 resource and kill it?  Or some other technique?  It is rather
 difficult bug to reproduce (for me anyway), but ultimately the device
 has to be restarted.

 Thanks!

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Wake locks and camera

2011-01-25 Thread blindfold

I noticed that in Android 2.2 and earlier I must do either a
FULL_WAKE_LOCK or a combination of PARTIAL_WAKE_LOCK and
FLAG_KEEP_SCREEN_ON to make sure the camera does not get turned off
after a while with my app in the foreground (and I need a wake lock to
keep GPS going). The underlying assumption seems to be that the camera
is not useful when the screen is off, but that assumption is false for
computer vision applications where not the user but the program is
watching the camera view. Is this fixed in Android 2.3 (Gingerbread)?

Thanks

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Camera preview issue on SDK 2.3 emulator?

2011-01-24 Thread blindfold

No I haven't found any solution. Please add your observation to
http://code.google.com/p/android/issues/detail?id=13133 such that it
becomes apparent to Google that it is something in need of fixing and
not a unique developer problem.

Thanks!

On Jan 24, 10:38 am, abukustfan abukust...@gmail.com wrote:
 Hi,

 I also met the same problem.
 Did you find the solutions??

 Thanks

 On Dec 8 2010, 6:14 pm, blindfold seeingwithso...@gmail.com wrote:

  Am I really the only one with this problem? Even the built-in camera
  app gives me only a blank screen in the SDK 2.3 emulator, but after
  taking a snapshot I do get a picture of the familiar green Android in
  the Gallery.

  Thanks

  On Dec 7, 12:27 pm, blindfold seeingwithso...@gmail.com wrote:

   Just found that the CameraPreview sample that comes bundled with SDK
   2.3 compiles fine but also gives me a plain white preview screen in
   the SDK 2.3 emulator on Windows 7 64-bit, so apparently it is not
   (just) my app not playing by the new rules. Any ideas? Gingerbread
   hardware acceleration acting up?

   Thanks

   On Dec 7, 11:24 am, blindfold seeingwithso...@gmail.com wrote:

In testing my camera app in the SDK 2.3 emulator, I find that it runs
OK *except* that the live camera preview is missing and instead
shows a plain white area. Is anyone else experiencing this?

Despite the live preview not showing, I can still do image processing
as expected and redraw the emulator's familiar built-in checkerboard
video on the screen, but the direct preview is plain white despite the
video data in the preview callback apparently being fine. Is there
some change in SurfaceView/SurfaceHolder handling or something?

My app runs fine in SDK 1.6 through 2.2 devices and emulators, and I
wonder what is causing the preview issue with SDK 2.3. I'm not using
any of the new camera API features of SDK 2.3, for backward
compatibility, and I am not observing any exceptions being thrown.

Thanks!

The vOICe for Androidhttp://www.seeingwithsound.com/android.htm

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Problem launching Google Goggles from camera app

2011-01-20 Thread blindfold

I'm launching Google Goggles from my own camera app through an intent,
which generally works fine, but occasionally Google Goggles refuses to
launch, popping up an error message reading

 Camera Error

 Cannot connect to camera. You may need to restart your device.

and after pressing OK my app takes over again and successfully resumes
its own use of the camera (no device restart, and not even an app
restart). Now of course only one app at a time can use the camera, so
I explicitly first release() the camera and set my camera object to
null before launching Google Goggles.

Just waiting for camera==null to happen automatically after a
camera.release() does not work: log output shows that the camera
object remains non-null after doing a camera.release(), and I have to
explicitly set it to null as is common practice, but after that
something is sometimes still blocking reuse of the camera. I suspect
that some camera ownership flag is still floating around deep down in
Android, but if it is not somehow exposed such that I can check for it
then it is of no use.

So what *else* can I check for to make sure that the camera REALLY has
been released and *is* available before handing control to another
camera app? Or should it be filed as an Android bug?

The problem occurs on my HTC Desire running Android 2.2. BTW, I always
do camera.stopPreview() and camera.setPreviewCallback(null) before
doing camera.release().

Thanks!

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Amazon to Policy Android Market Place

2011-01-15 Thread blindfold

Indeed that can work for some, at the expense of a bloated APK (ZXing
is about twice as large as my app, so it would likely triple my APK
size), and at the expense of updates to ZXing not automatically
becoming available to your users until you release your own update
that bundles an updated ZXing, or unless you add additional checks to
see if ZXing is already installed and use that external one instead of
your baked-in copy of ZXing.

For me this approach would not work anyway, because apart from ZXing
my app also launches Google Goggles and if not installed searches for
it on Android Market, while I am working on third-party product
referrals via Android Market. Again I have no idea if those third-
party products will ever land in the Amazon Appstore.

In relation to some discussion notes by others: I welcome alternatives
for Android Market, and I distribute my app also via for instance
Phoload, AndAppStore and Getjar, as well as via my own website, but in
all those cases I need not change a bit to my APK and can rely on
Android Market for extending basic functionality of my app. Amazon
Appstore sets a precedent, and leaves the whole burden of sorting out
how to best deal with it to the developer.

Thanks


On Jan 15, 4:14 am, Brill Pappin br...@pappin.ca wrote:
 @blindfold I have an experimental app that does the same thing. Luck
 for us, the Xzing code can be pulled down an added to your local app.
 However this is apparently a drawback to multiple app stores!

 - Brill Pappin

 On Jan 14, 4:26 pm, blindfold seeingwithso...@gmail.com wrote:

  My app got rejected by Amazon Appstore today because it searches for a
  third-party app (the well-known free ZXing barcode reader) on Android

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Interfacing External Camera To An Android Mobile Device

2011-01-14 Thread blindfold

Not without some hacking for enabling USB host mode and installing a
Linux USB webcam driver. Sven Killig did something like this
http://lifehacker.com/5558594/usb-host-hack-allows-keyboards-flash-drives-to-connect-to-the-nexus-one

On Jan 14, 8:13 am, 7Sigma 7si...@gmail.com wrote:
 Hi,
 Is it possible to attach an external camera to an android mobile
 device using USB, WIFI etc. Will it be possible for the application in
 the device to use the camera for processing.

 Thanks,
 Mohit

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Amazon to Policy Android Market Place

2011-01-14 Thread blindfold

My app got rejected by Amazon Appstore today because it searches for a
third-party app (the well-known free ZXing barcode reader) on Android
Market if the user tries to launch it from my app and it is not
installed. The barcode reader acts as a functional extension to my
app, launched via an intent, and I would not even know if it will come
to Amazon Appstore. So I'm not pleased with the Amazon Appstore
restrictions, and do not know of an elegant way to deal with this use
case. There is a related and ongoing discussion in the android-discuss
thread Amazon Market - First red flag
http://groups.google.com/group/android-discuss/browse_thread/thread/1879410c513b7df3/

On Jan 5, 11:05 pm, Leon Moreyn-Android Development
lmor...@earthcam.com wrote:
 The almighty Amazon.com feels that is should police the Android
 Market  for proper applications. On one hand I think this could be a
 good idea but on the other hand this feels took much like an Apple iOS
 development clone. With Amazon developing its own market place and
 limiting which apps can appear there you are guaranteed a visible
 market for your application. People who pursue amazon will know that
 your app may meet some sort of standard and may consider buying it.
 But just as good as that is, if Amazon is backed up with testing your
 application and like apple takes two weeks to reject your application
 based on some sort of merit what is to stop me from just uploading my
 application directly to the market place. ABSOLUTELY NOTHING. As
 someone who develops on both sides of the spectrum I don't see the
 implement of this Amazon App Market place as a good idea. I am curious
 as to other developers take on this and how many plan to actually
 develop to meet the amazon market guidelines.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Amazon to Policy Android Market Place

2011-01-14 Thread blindfold

Same answer as in 
http://groups.google.com/group/android-discuss/msg/b71caf66580b9cd0:

Good point. Not currently, but this I can (and will) easily fix by
checking if the Android Market app is installed, in the same way that
I check if ZXing is installed. However, doing so will AFAIK still not
suffice to comply with the Amazon Appstore requirements, because my
app would still perform a search on Android Market if the Android
Market app is installed and ZXing isn't. If Amazon only wants graceful
degradation in cases where users do not have the Android Market
installed, that is fine with me, and I'll gladly comply with that.

On Jan 14, 11:56 pm, Streets Of Boston flyingdutc...@gmail.com
wrote:
 If your app can be installed from another market than the Android
 Market, you cannot assume that the market: intent/scheme is handled
 on every device.

 If users without Android Market on their device download your app from
 Amazon Market, how would your app react if fails to find ZXing (i.e.
 if it fails the market: intent)? If your app fails gracefully and
 your app is still (fully) functional, Amazon shouldn't complain. But
 if your app just raises an error and, for example, quits your app,
 Amazon has a point of rejecting your app.

 If your app handles a lack of the market: scheme/intent gracefully
 but Amazon just tried it on a phone *with* Android Market installed
 and didn't like the fact that the Android Market activity was started,
 then I think Amazon is wrong. They can require apps to handle missing
 functionality gracefully, but they should not forbid any searches
 using the Android Market if Android Market is installed.

 On Jan 14, 4:26 pm, blindfold seeingwithso...@gmail.com wrote:

  My app got rejected by Amazon Appstore today because it searches for a
  third-party app (the well-known free ZXing barcode reader) on Android
  Market if the user tries to launch it from my app and it is not
  installed. The barcode reader acts as a functional extension to my
  app, launched via an intent, and I would not even know if it will come
  to Amazon Appstore. So I'm not pleased with the Amazon Appstore
  restrictions, and do not know of an elegant way to deal with this use
  case. There is a related and ongoing discussion in the android-discuss
  thread Amazon Market - First red 
  flaghttp://groups.google.com/group/android-discuss/browse_thread/thread/1...

  On Jan 5, 11:05 pm, Leon Moreyn-Android Development

  lmor...@earthcam.com wrote:
   The almighty Amazon.com feels that is should police the Android
   Market  for proper applications. On one hand I think this could be a
   good idea but on the other hand this feels took much like an Apple iOS
   development clone. With Amazon developing its own market place and
   limiting which apps can appear there you are guaranteed a visible
   market for your application. People who pursue amazon will know that
   your app may meet some sort of standard and may consider buying it.
   But just as good as that is, if Amazon is backed up with testing your
   application and like apple takes two weeks to reject your application
   based on some sort of merit what is to stop me from just uploading my
   application directly to the market place. ABSOLUTELY NOTHING. As
   someone who develops on both sides of the spectrum I don't see the
   implement of this Amazon App Market place as a good idea. I am curious
   as to other developers take on this and how many plan to actually
   develop to meet the amazon market guidelines.- Hide quoted text -

  - Show quoted text -

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Google analytics crash

2011-01-03 Thread blindfold

Well, after another user apparently had 6 crashes in 2 minutes from
GoogleAnalyticsTracker.trackEvent() right when launching my app, I've
updated my app to wrap all Google Analytics calls in try-catch blocks
to quench the symptoms. Even though the crash reports were rare, this
seems to be the only/simplest way for me to avoid an occasional bad
user experience due to use of Google Analytics.

Regards


java.lang.RuntimeException: Unable to start activity
ComponentInfo{vOICe.vOICe/vOICe.vOICe.The_vOICe}:
java.lang.IllegalStateException: no transaction pending at
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:
2663) at
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:
2679) at android.app.ActivityThread.access$2300(ActivityThread.java:
125) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:
2033) at android.os.Handler.dispatchMessage(Handler.java:99) at
android.os.Looper.loop(Looper.java:123) at
android.app.ActivityThread.main(ActivityThread.java:4627) at
java.lang.reflect.Method.invokeNative(Native Method) at
java.lang.reflect.Method.invoke(Method.java:521) at
com.android.internal.os.ZygoteInit
$MethodAndArgsCaller.run(ZygoteInit.java:878) at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:636) at
dalvik.system.NativeStart.main(Native Method) Caused by:
java.lang.IllegalStateException: no transaction pending at
android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:
555) at
com.google.android.apps.analytics.PersistentEventStore.putEvent(Unknown
Source) at
com.google.android.apps.analytics.GoogleAnalyticsTracker.createEvent(Unknown
Source) at
com.google.android.apps.analytics.GoogleAnalyticsTracker.trackEvent(Unknown
Source) at vOICe.vOICe.The_vOICe.a(Unknown Source) at
vOICe.vOICe.The_vOICe.onCreate(Unknown Source) at
android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:
1047) at
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:
2627) ... 11 more

FINGERPRINT {verizon/thunderc/thunderc/thunderc:2.2/FRF91/eng.lge.
20101101.102025:user/release-keys}


On Dec 31 2010, 3:55 pm, blindfold seeingwithso...@gmail.com wrote:
 Hmm, I have only one global tracker object that I create in the
 onCreate() of my main activity, and with a regular dispatch interval
 through the format tracker.start(UA-12345-0, nseconds, this), so I'd
 say that it all works from one alive thread. However, in one pair of
 crash logs the first GoogleAnalyticsTracker.trackEvent() crash occurs
 after my app had been running for some time, while the second
 GoogleAnalyticsTracker.trackEvent() crash occurs immediately at app
 startup only 3 minutes later, for the same device FINGERPRINT,
 suggesting that indeed some sort of lock had lived on even across runs
 to cause a second crash because the second run would not be owning the
 lingering lock. This was for a Samsung GT-I5800 running Android 2.1-
 update1.

 On Dec 31, 3:21 pm, H m...@howardb.com wrote:

  Looking in the analytics source after you've called trackEvent(), I suspect
  that error is coming out when it is using a database transaction to insert
  the event into the database. Once inserted, it calls endTransaction as well
  as setTransactionSuccessful. Both of these do this check:

  if (!mLock.isHeldByCurrentThread()) {
              throw new IllegalStateException(no transaction pending);
          }

  So it could be worth checking to see if you are tracking the event from a
  thread that has ended, or calling dispatch from a different thread...?

  HTH.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Google analytics crash

2010-12-31 Thread blindfold

 anyone else getting this?

I have recently received several crash reports caused by Google
Analytics (version 1.1), such as

java.lang.IllegalStateException: no transaction pending at
android.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:
480) at
com.google.android.apps.analytics.PersistentEventStore.putEvent(Unknown
Source) at
com.google.android.apps.analytics.GoogleAnalyticsTracker.createEvent(Unknown
Source) at
com.google.android.apps.analytics.GoogleAnalyticsTracker.trackEvent(Unknown
Source) at vOICe.vOICe.The_vOICe.a(Unknown Source) at
vOICe.vOICe.m.onAutoFocus(Unknown Source) at android.hardware.Camera
$EventHandler.handleMessage(Camera.java:345) at
android.os.Handler.dispatchMessage(Handler.java:99) at
android.os.Looper.loop(Looper.java:123) at
android.app.ActivityThread.main(ActivityThread.java:4363) at
java.lang.reflect.Method.invokeNative(Native Method) at
java.lang.reflect.Method.invoke(Method.java:521) at
com.android.internal.os.ZygoteInit
$MethodAndArgsCaller.run(ZygoteInit.java:862) at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:620) at
dalvik.system.NativeStart.main(Native Method)

I'm not sure yet what to do about them. Maybe put a try-catch block
around all uses of Google Analytics?

Regards


On Dec 29, 8:39 pm, Mark Wyszomierski mar...@gmail.com wrote:
 Hi,

 I'm using google analytics in my app. I am getting a good number of
 force closes from users, finally got a stacktrace:

 Caused by: android.database.sqlite.SQLiteException: file is encrypted
 or is not a database
   at android.database.sqlite.SQLiteDatabase.native_setLocale(Native
 Method)
   at
 android.database.sqlite.SQLiteDatabase.setLocale(SQLiteDatabase.java:
 1864)
   at android.database.sqlite.SQLiteDatabase.init(SQLiteDatabase.java:
 1814)
   at
 android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:
 808)
   at
 android.database.sqlite.SQLiteOpenHelper.getReadableDatabase(SQLiteOpenHelper.java:
 168)
   at
 com.google.android.apps.analytics.PersistentEventStore.getNumStoredEvents(PersistentEventStore.java:
 160)
   at
 com.google.android.apps.analytics.PersistentEventStore.startNewVisit(PersistentEventStore.java:
 177)
   at
 com.google.android.apps.analytics.GoogleAnalyticsTracker.start(GoogleAnalyticsTracker.java:
 108)
   at
 com.google.android.apps.analytics.GoogleAnalyticsTracker.start(GoogleAnalyticsTracker.java:
 99)
   at
 com.google.android.apps.analytics.GoogleAnalyticsTracker.start(GoogleAnalyticsTracker.java:
 83)
   at
 com.google.android.apps.analytics.GoogleAnalyticsTracker.start(GoogleAnalyticsTracker.java:
 94)
   at com.me.myapp.MyActivity.onCreate(MyActivity.java:30)
   at
 android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:
 1047)
   at
 android.app.ActivityThread.performLaunchActivity(ActivityThread.java:
 2459)

 anyone else getting this? The call that causes it:

   private GoogleAnalyticsTracker tracker;

   tracker = GoogleAnalyticsTracker.getInstance();
   tracker.start(mykey, context);  - causes the exception.

 This is working fine for most users. I'm going to try catching the
 exception, hopefully that will work.

 Thanks

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Google analytics crash

2010-12-31 Thread blindfold

You may be right, although the crash reports that I have all suggest
that they were triggered from direct calls to
GoogleAnalyticsTracker.trackEvent() in my code leading to
java.lang.IllegalStateException: no transaction pending. Judiciously
sprinkling try-catch blocks is a great way to further uglify source
code, so maybe I'll just live with the occasional crashes until Google
fixes the problem, given that thus far only 3 out of 5000 app runs
gave me crashes.

Thanks


On Dec 31, 2:26 pm, H m...@howardb.com wrote:
 You could stick a try/catch block in, but I doubt it would catch *most* of
 the bugs. Remember that your request for a track simply gets added to the
 database at that point and then some time later the dispatcher picks
 requests up from the database and sends them (although if you ask it to
 dispatch immediately you might catch them, but due to the use of handlers, I
 still doubt it). So your try/catch in your code would only catch errors from
 the first part and not the second.

 From the ACRA reporting in my app for the previous release of the analytics,
 the vast majority of my errors were coming from the latter part of the
 process where it was trying to read back from the database or failed during
 the sending part or failed when removing entries from the database.

 The analytics team did state they fixed a load of bugs in this latest
 release. I don't know if it's against the rules or not, but I decompiled the
 latest release and built it natively into my app and that allowed me to
 stick in a sprinkling of my own try/catch clauses around spots that I
 thought looked tetchy. I haven't released this yet..

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Google analytics crash

2010-12-31 Thread blindfold

Hmm, I have only one global tracker object that I create in the
onCreate() of my main activity, and with a regular dispatch interval
through the format tracker.start(UA-12345-0, nseconds, this), so I'd
say that it all works from one alive thread. However, in one pair of
crash logs the first GoogleAnalyticsTracker.trackEvent() crash occurs
after my app had been running for some time, while the second
GoogleAnalyticsTracker.trackEvent() crash occurs immediately at app
startup only 3 minutes later, for the same device FINGERPRINT,
suggesting that indeed some sort of lock had lived on even across runs
to cause a second crash because the second run would not be owning the
lingering lock. This was for a Samsung GT-I5800 running Android 2.1-
update1.

On Dec 31, 3:21 pm, H m...@howardb.com wrote:
 Looking in the analytics source after you've called trackEvent(), I suspect
 that error is coming out when it is using a database transaction to insert
 the event into the database. Once inserted, it calls endTransaction as well
 as setTransactionSuccessful. Both of these do this check:

 if (!mLock.isHeldByCurrentThread()) {
             throw new IllegalStateException(no transaction pending);
         }

 So it could be worth checking to see if you are tracking the event from a
 thread that has ended, or calling dispatch from a different thread...?

 HTH.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: App disappeared from Market Home

2010-12-21 Thread blindfold

I got the JSON parsing error too when uploading an updated APK
yesterday and today, using Firefox. Did not get this error in the past
with Firefox. Just reloading the page then gives you a draft listing,
and you can next proceed to fill in the Recent Changes (was grayed out
after the error) and press Publish.

 I think it's a cheap way to get people to use Chrome

Reminds me of all those online banking and booking sites that would
break unless you used Microsoft Internet Explorer. :-)

Regards

On Dec 21, 12:14 am, TreKing treking...@gmail.com wrote:
 Which browser are you guys using? I had an issue updating yesterday where it
 wouldn't accept my hi-rez icon on Firefox and gave me some strange JSON
 parsing error when I uploaded my app.

 Everything went fine when I used Chrome instead.

 I think it's a cheap way to get people to use Chrome :-P

 -
 TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago
 transit tracking app for Android-powered devices

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: How to simulate a (missing) DPAD

2010-12-18 Thread blindfold

OK, I've got it working, and in a rather straightforward manner.
Although dispatchKeyEvent() for some reason does not always determine
which UI element gets focus, it turned out that the UI element
actually does have a focus that one can in onKeyDown() reliably
perform a hasFocus() for after having done setFocusable(),
setFocusableInTouchMode() on all UI elements and a requestFocus(),
requestFocusFromTouch() on one element. Next, after putting all UI
elements like radiobuttons, checkboxes and editboxes in (for instance)
arrays, one can assign focus to the previous or next element when the
volume up or down key is pressed, thus hard-coding in what order UI
elements are traversed. Not very elegant, but thus far it works
reliably (no strange dependencies on whether a view is scrollable),
does the accessibility job for me in all activities, and it did not
require a major program overhaul. Tested on Android 1.6 and 2.2. It is
a bit like defining the tab order when programming for Microsoft
Windows. The key thing was to discard use of dispatchKeyEvent()
altogether and manually do what dispatchKeyEvent() was supposed to
do in terms of moving focus to a next UI element for a generated
KeyEvent.KEYCODE_DPAD_DOWN and KeyEvent.KEYCODE_DPAD_UP.

Thanks


On Dec 17, 10:06 am, Dianne Hackborn hack...@android.com wrote:
 I doubt you will get this to work correctly, because you are doing this
 after parts of the framework that deal with things like going in and out of
 touch mode have seen the events.

 Why are you doing this?  If a device doesn't have a DPAD, the user isn't
 going to think to use the volume keys to navigate focus(!!).  You should be
 giving them a good touch-based UI.

 On Fri, Dec 17, 2010 at 12:38 AM, blindfold seeingwithso...@gmail.comwrote:



  For Android phones that lack a physical d-pad or trackball (e.g.
  Alcatel OT-980, Motorola Droid Pro), I am trying to remap the physical
  up and down volume keys to simulated up and down d-pad keys using code
  like

  �...@override
    public boolean onKeyDown(int keyCode, KeyEvent event) {
       if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {
          KeyEvent ke = new KeyEvent(KeyEvent.ACTION_DOWN,
  KeyEvent.KEYCODE_DPAD_UP);
          dispatchKeyEvent(ke);
          return true;
       }
       return super.onKeyDown(keyCode, event);
    }

  Although this works fine with a ListView and with activity views that
  become scrollable because they are too large to fit on the physical
  screen, it somehow does not work at all for activity views that remain
  small enough to fit on the screen. I can test this by increasing the
  number of radio buttons in some activity view and then see how the
  above key remapping begins to work fine as soon as there are more
  controls than fit on the screen. I have tried all sorts of things with
  setting focus after making things focusable using setFocusable(true),
  setFocusableInTouchMode(true), requestFocus(), requestFocusFromTouch()
  and so on, but nothing seems to help. The above onKeyDown() executes
  in all relevant cases as shown by my Log.i() output, but it is the
  dispatchKeyEvent() that  in the described cases does nothing. All my
  activity views are surrounded by ScrollView/ScrollView in the XML
  of their respective layouts. More about the context of this problem at

 http://groups.google.com/group/eyes-free-dev/browse_thread/thread/374...
  (eyes-free-dev list).

  So the above code works sometimes, but I need a reliable/general
  solution. How can one reliably remap physical keys to perform key
  functions for which there are no physical keys on the Android device?

  Thanks!

  --
  You received this message because you are subscribed to the Google
  Groups Android Developers group.
  To post to this group, send email to android-developers@googlegroups.com
  To unsubscribe from this group, send email to
  android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
  For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 --
 Dianne Hackborn
 Android framework engineer
 hack...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support, and so won't reply to such e-mails.  All such
 questions should be posted on public forums, where I and others can see and
 answer them.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] How to simulate a (missing) DPAD

For Android phones that lack a physical d-pad or trackball (e.g.
Alcatel OT-980, Motorola Droid Pro), I am trying to remap the physical
up and down volume keys to simulated up and down d-pad keys using code
like

  @Override
   public boolean onKeyDown(int keyCode, KeyEvent event) {
  if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {
 KeyEvent ke = new KeyEvent(KeyEvent.ACTION_DOWN,
KeyEvent.KEYCODE_DPAD_UP);
 dispatchKeyEvent(ke);
 return true;
  }
  return super.onKeyDown(keyCode, event);
   }

Although this works fine with a ListView and with activity views that
become scrollable because they are too large to fit on the physical
screen, it somehow does not work at all for activity views that remain
small enough to fit on the screen. I can test this by increasing the
number of radio buttons in some activity view and then see how the
above key remapping begins to work fine as soon as there are more
controls than fit on the screen. I have tried all sorts of things with
setting focus after making things focusable using setFocusable(true),
setFocusableInTouchMode(true), requestFocus(), requestFocusFromTouch()
and so on, but nothing seems to help. The above onKeyDown() executes
in all relevant cases as shown by my Log.i() output, but it is the
dispatchKeyEvent() that  in the described cases does nothing. All my
activity views are surrounded by ScrollView/ScrollView in the XML
of their respective layouts. More about the context of this problem at
http://groups.google.com/group/eyes-free-dev/browse_thread/thread/3747abb6f0b9df11
(eyes-free-dev list).

So the above code works sometimes, but I need a reliable/general
solution. How can one reliably remap physical keys to perform key
functions for which there are no physical keys on the Android device?

Thanks!

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: How to simulate a (missing) DPAD

Thanks Dianne! Good to know, even though it presents a setback.

 Why are you doing this?

For accessibility purposes. One of my blind users just bought an
Alcatel OT-980 running Android 2.1. This phone does have a physical
QWERTY keyboard but no d-pad or equivalent (BTW, the same applies to
Motorola Droid Pro and Sony Ericsson X10 mini pro). So I want to make
provisions for blind navigation of menu and dialogs through Google's
screen reader TalkBack. This currently requires physical keys, because
Android still lacks the kind of touch event model of the iPhone where
(blind) users can explore the screen by touch and hear GUI elements
spoken without immediately activating whatever elements they are
touching or sliding over. This is particularly relevant for the soft
keyboard, but even with Android phones that have a physical keyboard
we face this accessibility problem when there is no d-pad. These users
are motivated enough to learn a few workarounds, because that is part
of their daily life.

Best regards


The vOICe for Android
http://www.seeingwithsound.com/android.htm

On Dec 17, 10:06 am, Dianne Hackborn hack...@android.com wrote:
 I doubt you will get this to work correctly, because you are doing this
 after parts of the framework that deal with things like going in and out of
 touch mode have seen the events.

 Why are you doing this?  If a device doesn't have a DPAD, the user isn't
 going to think to use the volume keys to navigate focus(!!).  You should be
 giving them a good touch-based UI.

 On Fri, Dec 17, 2010 at 12:38 AM, blindfold seeingwithso...@gmail.comwrote:



  For Android phones that lack a physical d-pad or trackball (e.g.
  Alcatel OT-980, Motorola Droid Pro), I am trying to remap the physical
  up and down volume keys to simulated up and down d-pad keys using code
  like

  �...@override
    public boolean onKeyDown(int keyCode, KeyEvent event) {
       if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {
          KeyEvent ke = new KeyEvent(KeyEvent.ACTION_DOWN,
  KeyEvent.KEYCODE_DPAD_UP);
          dispatchKeyEvent(ke);
          return true;
       }
       return super.onKeyDown(keyCode, event);
    }

  Although this works fine with a ListView and with activity views that
  become scrollable because they are too large to fit on the physical
  screen, it somehow does not work at all for activity views that remain
  small enough to fit on the screen. I can test this by increasing the
  number of radio buttons in some activity view and then see how the
  above key remapping begins to work fine as soon as there are more
  controls than fit on the screen. I have tried all sorts of things with
  setting focus after making things focusable using setFocusable(true),
  setFocusableInTouchMode(true), requestFocus(), requestFocusFromTouch()
  and so on, but nothing seems to help. The above onKeyDown() executes
  in all relevant cases as shown by my Log.i() output, but it is the
  dispatchKeyEvent() that  in the described cases does nothing. All my
  activity views are surrounded by ScrollView/ScrollView in the XML
  of their respective layouts. More about the context of this problem at

 http://groups.google.com/group/eyes-free-dev/browse_thread/thread/374...
  (eyes-free-dev list).

  So the above code works sometimes, but I need a reliable/general
  solution. How can one reliably remap physical keys to perform key
  functions for which there are no physical keys on the Android device?

  Thanks!

  --
  You received this message because you are subscribed to the Google
  Groups Android Developers group.
  To post to this group, send email to android-developers@googlegroups.com
  To unsubscribe from this group, send email to
  android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
  For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 --
 Dianne Hackborn
 Android framework engineer
 hack...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support, and so won't reply to such e-mails.  All such
 questions should be posted on public forums, where I and others can see and
 answer them.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: How to simulate a (missing) DPAD

Thanks Mark. I can easily detect touch events by their coordinates,
but not so easily identify what UI elements lie underneath - unless I
define and layout each of these UI elements graphically myself in
terms of screen coordinates. I think your proposed TalkBackOverlayView
would require that too, if I understand you correctly. My main screen
already uses different touch screen events for gross positions like
center, top middle, left middle, bottom left and bottom right, and
speaks the relevant user actions. Here I did without an exploration
mode, although that should have been easily possible through handling
ACTION_DOWN and ACTION_UP events separately in dispatchTouchEvent().
This very basic level of touch screen use is indeed accessible for
blind persons, as are the keyboard shortcuts that I have defined for
phones with a physical keyboard.

However, at some point one would want to make good use of standard UI
elements (listviews, buttons, radio buttons, checkboxes etc) for which
Android determines the concrete layout instance, and render these
standard elements accessible rather than having to define a range of
dedicated touch views corresponding to each and every activity view
that sighted users would use. I have no ambition to reinvent the
Android layout framework. The iPhone, through VoiceOver, offers a
generic touch screen solution for this as part of the OS. I feel that
any accessibility hook for standard UI elements that I add at
application level to my specific Android app should be only an interim
solution and a stop gap until Android catches up and offers a
similarly general accessibility solution as part of the OS. Otherwise,
blind users will in the future at best have a few accessible point
solutions, but no general accessibility with phones that lack a
physical keyboard and/or d-pad.

Now while trying to bridge the current accessibility limitations for d-
pad-less Android phones, apparently even a simple key remapping is not
that, erm... simple, with the current set of event Listeners and
onWhatevers(). :-(

On Dec 17, 11:37 am, Mark Murphy mmur...@commonsware.com wrote:
On Fri, Dec 17, 2010 at 4:31 AM, blindfold seeingwithso...@gmail.com wrote:
This currently requires physical keys, because
Android still lacks the kind of touch event model of the iPhone where
(blind) users can explore the screen by touch and hear GUI elements
spoken without immediately activating whatever elements they are
touching or sliding over.

If this is your own app, I would think you could do this on your own.
Have a blind mode that puts a TalkBackOverlayView on top of the
regular UI. TalkBackOverlayView would use the same techniques as
GestureOverlayView to detect touch events and selectively pass them
through. In particular, in an exploration mode, it would behave as
you describe -- when the screen is touched, find out the widget
underneath it at those pixel coordinates, and announce what it is.

Offering this for other apps would require firmware mods, of course.

And, of course, I haven't tried this, nor have I looked at the
GestureOverlayView code to see how tough it would be to implement.
It's just an idea that popped to mind while reading your post.

--
Mark Murphy (a Commons
Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9
Available!

[android-developers] Re: How to simulate a (missing) DPAD

Hi Mark, walking the View tree with getLocationOnScreen() while
retrieving element labels might be possible, and is a good idea in
itself, but this is more the kind of thing that one would try for a
generic accessibility layer, such as for a screen reader that works
across all apps (currently limited by security restrictions), or as
part of the OS. For a single app it may be too much work for what
should be a temporary app-specific solution. Perhaps I am pessimistic,
but my estimate is that it would take a significant effort that may
run into unforeseen limitations along the road much like even my
simple key remapping attempt turned into a time waster. I once looked
at something similar to UI-tree walking to obtain icon names at the
mouse pointer on the Microsoft Windows desktop, but there it was a
royal pain and still did not quite yield the sought information.
Unfortunately Google rarely discloses what they are up to, so one
cannot know how much of the app-level accessibility patching and
bridging will become obsolete in what time frame. For instance, I made
my app's UI elements self-voicing before Google released TalkBack, but
by now that effort is mostly obsolete. Basically all blind Android
phone users and would-be users are now clamoring for something
equivalent to the iPhone touch screen experience, but that requires
changes to the OS, and we non-Google accessibility developers do not
know if or when these are forthcoming.

Thanks


The vOICe for Android
http://www.seeingwithsound.com/android.htm


On Dec 17, 1:00 pm, Mark Murphy mmur...@commonsware.com wrote:
 On Fri, Dec 17, 2010 at 6:52 AM, blindfold seeingwithso...@gmail.com wrote:
  Thanks Mark. I can easily detect touch events by their coordinates,
  but not so easily identify what UI elements lie underneath - unless I
  define and layout each of these UI elements graphically myself in
  terms of screen coordinates.

 Walk the widgets in the layout and figure out who is on the screen at
 your touch coordinates via getLocationOnScreen() (or maybe
 getLocationInWindow())? I'm probably being a bit simplistic, but I
 would think there should be some way to figure out what is underneath
 the touch coordinate.

 --
 Mark Murphy (a Commons 
 Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

 _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9
 Available!

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: How to simulate a (missing) DPAD

Hi Brill, you may be right in hindsight, but key remapping seemed like
such a simple and effective countermeasure that I expected it to work,
and it would have made more Android phone types accessible to blind
users. Alas...

On Dec 17, 3:04 pm, Brill Pappin br...@pappin.ca wrote:
 I'm not sure that is going to work all that well for you, but instead of
 emulating the DPAD, can you simply listen for the keys you are trying to
 remap instead of remapping them?

 I think its great that you are trying to solve a problem for a user that is
 having trouble with your app because of an unusual circumstance... however I
 also feel that the user in question should maybe take that problem up with
 whoever they got the phone from and get a new phone; you may be willing to
 make an effort, but most apps won't, so they really have the wrong phone.

 - Brill

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: HeaderView in ListView causing ClassCastException

2010-12-10 Thread blindfold

http://stackoverflow.com/questions/4393775/android-classcastexception-when-adding-a-header-view-to-expandablelistview
helped me out with addHeaderView() and the infamous
ClassCastException.

Basically you do TopSearch.setLayoutParams(new
ListView.LayoutParams(ListView.LayoutParams.FILL_PARENT,
ListView.LayoutParams.WRAP_CONTENT)); right before
lv.addHeaderView(TopSearch);

Regards

On Dec 10, 5:37 pm, bobetko bobe...@gmail.com wrote:
 I have added a view to the header of my ListView by following way:

         ListView lv = (ListView)getListView();
         View TopSearch =  (View) View.inflate(this, R.layout.search,
 null);
         lv.addHeaderView(TopSearch, null, false);

 And everything is fine until I make changes to data adapter and then
 try to execute:

        adapter.notifyDataSetChanged();

 This always crashes my application giving me following error:

 java.lang.ClassCastException: android.widget.HeaderViewListAdapter

 If I don't add header view to my list view, then everything works fine
 with no errors
 Any suggestions?

 Thanks.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Problem with toggleSoftInput() doing nothing after a third-party startActivityForResult()

2010-12-09 Thread blindfold

I have a problem with the soft keyboard after launching another
activity. Upon a touch event I use

InputMethodManager imm = (InputMethodManager)
getSystemService(INPUT_METHOD_SERVICE);
imm.toggleSoftInput(InputMethodManager.SHOW_FORCED, 0);

to pop up the soft keyboard, which works just fine.

However, after launching and returning from another (third-party)
activity via startActivityForResult(), the touch events again work
fine but the soft keyboard no longer shows up with the above lines. I
have this problem after launching the phone's browser, after launching
ZXing as well as after launching an Admob test ad. Apparently
something about the launched activity still lingers after returning
from these third-party activities. What must one do to restore a
proper state to get the soft keyboard to pop up again, or is this an
Android bug?

Curiously, the problem is cured after doing yet another
startActivityForResult() but then for one of my own activities. The
question is what exactly it is that I need to reset to regain proper
toggleSoftInput() behavior.

Thanks!

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Camera preview issue on SDK 2.3 emulator?

2010-12-08 Thread blindfold

Am I really the only one with this problem? Even the built-in camera
app gives me only a blank screen in the SDK 2.3 emulator, but after
taking a snapshot I do get a picture of the familiar green Android in
the Gallery.

Thanks

On Dec 7, 12:27 pm, blindfold seeingwithso...@gmail.com wrote:
 Just found that the CameraPreview sample that comes bundled with SDK
 2.3 compiles fine but also gives me a plain white preview screen in
 the SDK 2.3 emulator on Windows 7 64-bit, so apparently it is not
 (just) my app not playing by the new rules. Any ideas? Gingerbread
 hardware acceleration acting up?

 Thanks

 On Dec 7, 11:24 am, blindfold seeingwithso...@gmail.com wrote:

  In testing my camera app in the SDK 2.3 emulator, I find that it runs
  OK *except* that the live camera preview is missing and instead
  shows a plain white area. Is anyone else experiencing this?

  Despite the live preview not showing, I can still do image processing
  as expected and redraw the emulator's familiar built-in checkerboard
  video on the screen, but the direct preview is plain white despite the
  video data in the preview callback apparently being fine. Is there
  some change in SurfaceView/SurfaceHolder handling or something?

  My app runs fine in SDK 1.6 through 2.2 devices and emulators, and I
  wonder what is causing the preview issue with SDK 2.3. I'm not using
  any of the new camera API features of SDK 2.3, for backward
  compatibility, and I am not observing any exceptions being thrown.

  Thanks!

  The vOICe for Androidhttp://www.seeingwithsound.com/android.htm



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Camera preview issue on SDK 2.3 emulator?

2010-12-07 Thread blindfold

In testing my camera app in the SDK 2.3 emulator, I find that it runs
OK *except* that the live camera preview is missing and instead
shows a plain white area. Is anyone else experiencing this?

Despite the live preview not showing, I can still do image processing
as expected and redraw the emulator's familiar built-in checkerboard
video on the screen, but the direct preview is plain white despite the
video data in the preview callback apparently being fine. Is there
some change in SurfaceView/SurfaceHolder handling or something?

My app runs fine in SDK 1.6 through 2.2 devices and emulators, and I
wonder what is causing the preview issue with SDK 2.3. I'm not using
any of the new camera API features of SDK 2.3, for backward
compatibility, and I am not observing any exceptions being thrown.

Thanks!


The vOICe for Android
http://www.seeingwithsound.com/android.htm

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: New ADT and SDK breaks Eclipse (Again!)

2010-12-07 Thread blindfold

Confirmed. I had the same issue and solution (I'm on Windows 7 64-
bit).

On Dec 7, 9:46 am, Kostya Vasilyev kmans...@gmail.com wrote:
 07.12.2010 8:48, Zarah пишет:

  - Some errors where encountered when installing, failure to rename a
  file?  The dialog says close all anti-virus software, so I did that. I
  also closed down all instances of Windows Explorer.  I tried to run
  Unlocker on the folder in question, and it said only Eclipse is using
  the folder.  Here's the error from the SDK manager:
  Failed to rename directory C:\android-sdk-windows\platforms\android-7
  to C:\android-sdk-windows\temp\PlatformPackage.old02.
  Failed to rename directory C:\android-sdk-windows\platforms\android-3
  to C:\android-sdk-windows\temp\PlatformPackage.old02.

 Updating the SDK outside of Eclipse helps avoid these (run android.bat
 to launch the SDK/AVD manager).

 --
 Kostya Vasilyev -- WiFi Manager + pretty widget 
 --http://kmansoft.wordpress.com

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Camera preview issue on SDK 2.3 emulator?

2010-12-07 Thread blindfold

Just found that the CameraPreview sample that comes bundled with SDK
2.3 compiles fine but also gives me a plain white preview screen in
the SDK 2.3 emulator on Windows 7 64-bit, so apparently it is not
(just) my app not playing by the new rules. Any ideas? Gingerbread
hardware acceleration acting up?

Thanks

On Dec 7, 11:24 am, blindfold seeingwithso...@gmail.com wrote:
 In testing my camera app in the SDK 2.3 emulator, I find that it runs
 OK *except* that the live camera preview is missing and instead
 shows a plain white area. Is anyone else experiencing this?

 Despite the live preview not showing, I can still do image processing
 as expected and redraw the emulator's familiar built-in checkerboard
 video on the screen, but the direct preview is plain white despite the
 video data in the preview callback apparently being fine. Is there
 some change in SurfaceView/SurfaceHolder handling or something?

 My app runs fine in SDK 1.6 through 2.2 devices and emulators, and I
 wonder what is causing the preview issue with SDK 2.3. I'm not using
 any of the new camera API features of SDK 2.3, for backward
 compatibility, and I am not observing any exceptions being thrown.

 Thanks!

 The vOICe for Androidhttp://www.seeingwithsound.com/android.htm

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Market expanding to technically non-compliant devices?

2010-11-30 Thread blindfold

Yes, things are getting confusing if not messy. The Logitech TV Cam
accessory for the Logitech Revue Google TV adds a camera to Google TV
http://www.logitech.com/en-us/smartTV/accessories/devices/tv-cam but
it can reportedly not be used by Android apps: The TV Cam cannot be
accessed from other applications at this time 
http://forums.adobe.com/message/3256491#3256491

Great, so there *is* a camera for this Android device (Google TV) but
it cannot be used by regular Android apps. Now this probably means
that Android camera apps will simply remain invisible on the Android
Market for this Google TV, but for developers it is just as important
to know if a device is compatible with their app or not - to be able
to tell their customers. One should not have to scour web forums in
the hope of getting an indication of that. In other words, should it
not be *required* that Logitech clearly indicates on their website
that Logitech TV Cam does not work with third-party (and Google's!)
Android camera apps, and *only* works with their own proprietary video
call app? I currently cannot find this on the Logitech TV Cam product
page
http://www.logitech.com/en-us/smartTV/accessories/devices/tv-cam and
even if it is hidden somewhere in the small print that is hardly
practical for developers who need to be able to quickly tell
compatibility for a range of new devices to answer customer
inquiries.

Looks like there should be some additional requirements for
manufacturers here in order to be allowed to use the Google TV brand,
because everybody already knows that Google TV runs Android
http://www.google.com/tv/developers.html and if there is a camera
accessory everybody would assume that Android camera apps would run
fine and not be in for an unpleasant surprise or a heap of
uncertainty.

Thanks!


On Nov 30, 8:20 am, Spiral123 cumis...@gmail.com wrote:
 GoogleTV.  My Logitech Revue has no touch screen - assuming the market
 gets expanded to this device (yes please!) then I won't want to see
 any apps where I need to touch the screen.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Feature Graphic, High Resolution Application Icon and Promotional Video.

2010-11-25 Thread blindfold

Right, in my case too the uploaded feature graphic and hi-res icon
keep vanishing some time after a successful upload.

Looks like someone misconfigured the Monkey tool to write software
rather than test software.

On Nov 25, 11:10 am, sblantipodi perini.dav...@dpsoftware.org wrote:
 Hi,
 as stated in other thread the Feature Graphic, High
 Resolution Application Icon and Promotional Video are always removed
 after we upload them.

 Is there someone who know when we can finally upload this file without
 having to re-upload and re-upload it?

 Do you know also what URL should we use for Promotional Video?
 Is it good a youtube url or they need a direct link to a video file ?

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: can we create app to use phone camera as magnifier

2010-11-24 Thread blindfold

http://www.androlib.com/android.application.com-davidparry-magnifier-qmmmA.aspx

On Nov 24, 1:39 pm, Atik atik0...@gmail.com wrote:
 hi guys

 i need to know that can we use android phone camera as magnifier
 glass.
 i want to create such application, which will open the camera and zoom
 it to read some small text etc, it wont capture any picture neither it
 will record any video.

 pls suggest if any one have any ideas

 Thanks
 'Atik

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Can't Upgrade Apps Since Console Maintenance ?

2010-11-21 Thread blindfold

I also have Firefox 3.6.12 but for me the new images never showed
after pressing the Upload button. They do now after uploading via
Google Chrome. Don't know what's different.

On Nov 21, 10:19 am, Pent tas...@dinglisch.net wrote:
  Argh! Just found that I can upload PNG feature graphic and 512x512
  icon just fine with Google Chrome, but not with Firefox! Apparently
  the extended interface is not yet browser-neutral, because I had
  uploaded the other images in the past just fine with Firefox (which is
  my default browser).

 I used firefox, 3.6.12.

 Pent

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Can't Upgrade Apps Since Console Maintenance ?

2010-11-20 Thread blindfold

Well, I cannot upload a feature graphic or 512x512 icon, no matter if
I try PNG (with or without alpha) or JPEG. No error messages, but no
image shows up. I haven't tried uploading a new app version.

On Nov 20, 8:35 pm, Pent tas...@dinglisch.net wrote:
 I understand the maintenance window is long past, but the Upload
 Upgrade linky button just disappears when I click it for all my apps.

 I can upload assets without problem e.g. the new 512x512 icon.

 Anyone else ?

 Pent

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Can't Upgrade Apps Since Console Maintenance ?

2010-11-20 Thread blindfold

Argh! Just found that I can upload PNG feature graphic and 512x512
icon just fine with Google Chrome, but not with Firefox! Apparently
the extended interface is not yet browser-neutral, because I had
uploaded the other images in the past just fine with Firefox (which is
my default browser).

Regards

On Nov 20, 10:58 pm, blindfold seeingwithso...@gmail.com wrote:
 Well, I cannot upload a feature graphic or 512x512 icon, no matter if
 I try PNG (with or without alpha) or JPEG. No error messages, but no
 image shows up. I haven't tried uploading a new app version.

 On Nov 20, 8:35 pm, Pent tas...@dinglisch.net wrote:

  I understand the maintenance window is long past, but the Upload
 Upgradelinky button just disappears when I click it for all myapps.

  I can upload assets without problem e.g. the new 512x512 icon.

  Anyone else ?

  Pent



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Camera saving corrupted photos

2010-11-14 Thread blindfold

2.592 x 1.952 looks like an unusual (unsupported) image size to me.
Maybe try 2.592 x 1.944?

Regards

On Nov 14, 7:58 pm, Stephen Lebed srle...@gmail.com wrote:
 I can't figure out why I'm getting corrupted images when I save them
 in my app.  In fact the thumbnail seems to be fine, but the actual
 image is corrupted, as if the stride value is not being set
 correctly.  The following is the code I'm using the save the image,
 which is taken from other version of camera apps almost directly.  In
 other apps it seems to be saving images without problem.  This is
 called from a Camera.PictureCallback.onPictureTaken(byte[] data,
 Camera camera)

 File filename = new File(Test_SnapShotK.jpg);
 File exportDir = new File(Environment.getExternalStorageDirectory(),
 TestDir);

 if (!exportDir.exists()) {
         exportDir.mkdirs();
         Log.i(TAG, making directory  + exportDir.toString());

 }

 File file = new File(exportDir, filename.getName());

 try {
         FileOutputStream fileOutputStream = new FileOutputStream(file);
         fileOutputStream.write(data);
         fileOutputStream.flush();
         fileOutputStream.close();

 } catch (IOException e) {

         Log.e(TAG, e.getMessage(), e);

 }

 Since I can't attach the image I'm getting directly in this post, here
 is a link to it.

 http://www.mechnology.com/Test_SnapShotK.jpg

 Has anyone else gotten this problem and have been able to resolve it.
 I'm testing this on a G2 phone.  Any help is greatly appreciated.

 Stephen

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Camera saving corrupted photos

2010-11-14 Thread blindfold

Sounds like a G2/Android bug then, because still image results should
always be totally unrelated to any (screen) layout settings. Only
camera preview results can be linked to layout.

On Nov 15, 1:26 am, Stephen Lebed srle...@gmail.com wrote:
 It is a supported size on the g2.  I'm not specifying the size, its
 the default res for the camera.

 It looks like part of the problem is with

 getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
 WindowManager.LayoutParams.FLAG_FULLSCREEN);

 I use this in the onCreate method.  Again, I use this all the time,
 but when I comment out this line, I can save uncorrupted images. I'm
 still hunting for an answer.  It is related to my layout xml.

 On Nov 14, 12:53 pm, blindfold seeingwithso...@gmail.com wrote:

  2.592 x 1.952 looks like an unusual (unsupported) image size to me.
  Maybe try 2.592 x 1.944?

  Regards

  On Nov 14, 7:58 pm, Stephen Lebed srle...@gmail.com wrote:

   I can't figure out why I'm getting corrupted images when I save them
   in my app.  In fact the thumbnail seems to be fine, but the actual
   image is corrupted, as if the stride value is not being set
   correctly.  The following is the code I'm using the save the image,
   which is taken from other version of camera apps almost directly.  In
   other apps it seems to be saving images without problem.  This is
   called from a Camera.PictureCallback.onPictureTaken(byte[] data,
   Camera camera)

   File filename = new File(Test_SnapShotK.jpg);
   File exportDir = new File(Environment.getExternalStorageDirectory(),
   TestDir);

   if (!exportDir.exists()) {
           exportDir.mkdirs();
           Log.i(TAG, making directory  + exportDir.toString());

   }

   File file = new File(exportDir, filename.getName());

   try {
           FileOutputStream fileOutputStream = new FileOutputStream(file);
           fileOutputStream.write(data);
           fileOutputStream.flush();
           fileOutputStream.close();

   } catch (IOException e) {

           Log.e(TAG, e.getMessage(), e);

   }

   Since I can't attach the image I'm getting directly in this post, here
   is a link to it.

  http://www.mechnology.com/Test_SnapShotK.jpg

   Has anyone else gotten this problem and have been able to resolve it.
   I'm testing this on a G2 phone.  Any help is greatly appreciated.

   Stephen



-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Samsung Galaxy Camera flash-mode and zoom-supported oddities

2010-10-08 Thread blindfold

I have no Galaxy S Epic to test with, and I essentially use something
like

if (camera.getParameters().getFlashMode(camera.getParameters()) !=
null) parameters.setFlashMode(Camera.Parameters.FLASH_MODE_TORCH)

to turn on the torch, so from your description I gather that this
ought to work also on the Galaxy.

However, I used FLASH_MODE_OFF to turn the torch LED off, which works
fine on the HTC Desire with Android 2.2, but according to your
description this would fail with the Galaxy. You can try my app The
vOICe for Android (search Market for seeingwithsound, and toggle
the color identification on/off via the Menu key (second entry) to see
if indeed it fails to turn off the torch when done with the color
identification feature. You could use this to validate your analysis
of the Galaxy S Epic.

On Oct 8, 5:26 am, mjmeyer mjmeye...@gmail.com wrote:
 I've been stunned by how different Samsung's camera behaves compared
 to the other devices I've tested camera preview stuff with.

 Mind you, this is in 2.1 so the SDK 8 Camera.getZoomRatios() and
 Camera.isZooomSupported() are not available.

 Looking at the Camera.getParameters().flatten() result shows that the
 common zoom-supported that I see in HTC, N1, and Mototrolla devices
 is not there.

 Instead there's something called digi-zoom. I couldnt find any
 documentation or posts about its usage but a little experimenting
 revealed it takes numerals 1..10 as string and will zoom accordingly.
 I have no idea what the ratios would be.

 Also, there's some madness with the flash mode on the Galaxy S Epic
 that I have tested with.

 Calls to getSupportedFlashModes() return only auto,on,off. There is no
 torch supported.

 However, if you do
 params.setFlashMode(Camera.Parameters.FLASH_MODE_TORCH) it will turn
 the LED on!

 Sadly, subsequently setting it to FLASH_MODE_OFF or FLASH_MODE_AUTO
 does not turn the LED off! It's stuck on until Camera.release(), or
 maybe Camera.stopPreview(), I havent traced into it yet to see which
 actually turns it off.

 I suppose that's why Samsung doesnt return torch in the supported
 list. I'd prefer not to have to stop and restart the preview to turn
 it off for this model.

 Any suggestions or knowledge of apps that successfully turn torch on
 and then off on Galaxy?

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Method called after release()

2010-09-23 Thread blindfold

I also find the Method called after release() occasionally in my
camera app's crash logs with end users, and have thus far not been
able to track it down because I did not encounter it on my own phones
(ADP1 with Android 1.6 and HTC Desire with Android 2.2). Apparently
something camera related in android.hardware.Camera sometimes lives on
even after releasing the camera, or I overlooked something in doing a
join when cleaning up. Difficult to debug. You can try inserting
mCamera.setPreviewCallback(null) in between mCamera.stopPreview() and
mCamera.release(), ending it all with setting mCamera=null and
wrapping everything in a mCamera!=null check and see if that works for
you.

Regards

On Sep 23, 10:35 am, Pedro Teixeira pedroteixeir...@gmail.com wrote:
 No ideias for this?

 I just keep reading on google to release the camera.. and I've just  
 done that but I get the error anyway..

 On Sep 22, 2010, at 11:43 PM, Pedro Teixeira wrote:



  Hi, I'm getting this error ( in the end of this post)... which I guess
  I understand it's because I'm calling something after releasing it..
  but I can't find a wy to work it around... Here is the method:

  public void surfaceDestroyed(SurfaceHolder holder) {
             mPreviewRunning = false;
             mCamera.stopPreview();
             mCamera.release();
     }

  I've tried all combinations.. I've tried:
  mCamera.setPreviewCallback(null);
  This class, where the surfaceview is implemented can be accessed by 2
  different classes.. one that doesnt implement surfaceview and other
  that does.. the error just shows me when I go from the activity that
  uses the camera to the activity that also uses camera.. I don't know
  what else to do.. I've google it and can't find any answer. any
  suggestion?

  09-22 19:55:57.475: ERROR/AndroidRuntime(900):     Uncaught handler:
  thread main exiting due to uncaught exception
  09-22 19:55:57.605: ERROR/AndroidRuntime(900):
  java.lang.RuntimeException: Method called after release()
  09-22 19:55:57.605: ERROR/AndroidRuntime(900):     at
  android.hardware.Camera.stopPreview(Native Method)
  09-22 19:55:57.605: ERROR/AndroidRuntime(900):     at
  com.pedroteixeira.thennnow.cameraView.surfaceDestroyed
  (cameraView.java:
  184)
  09-22 19:55:57.605: ERROR/AndroidRuntime(900):     at
  android.view.SurfaceView.reportSurfaceDestroyed(SurfaceView.java:426)
  09-22 19:55:57.605: ERROR/AndroidRuntime(900):     at
  android.view.SurfaceView.updateWindow(SurfaceView.java:351)
  09-22 19:55:57.605: ERROR/AndroidRuntime(900):     at
  android.view.SurfaceView.onWindowVisibilityChanged(SurfaceView.java:
  182)

  --
  You received this message because you are subscribed to the Google
  Groups Android Developers group.
  To post to this group, send email to android-developers@googlegroups.com
  To unsubscribe from this group, send email to
  android-developers+unsubscr...@googlegroups.com
  For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 Pedro Teixeira

 www.pedroteixeira.org

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Can android support more than one sdcard?

Hi Dianne,

Thank you for confirming my expectations.

I hope your colleagues will consider device enumeration as being
important for limiting future fragmentation of a supposedly open
platform and for encouraging new application areas, going well beyond
nice.

Regards


On Sep 12, 12:40 am, Dianne Hackborn hack...@android.com wrote:
 Well you are totally missing my point.  Of course it would be *nice* to
 support an arbitrary number of everything.  To actually ship a product on
 time, though, you probably aren't going to be able to do so.

 The SD card is an especially good case of this, because it's not just a
 matter of adding an API -- you also need to figure out the whole UX around
 this, which is fairly non-trivial.

 Anyway, done with this thread.

 On Sat, Sep 11, 2010 at 1:51 AM, blindfold seeingwithso...@gmail.comwrote:



   A marketing or engineering department that can't accept limitations is an
   organization that will never ship a product.

  When you are a research department you aim to develop new products
  rather than shorten time to market. When even the basic building
  blocks are already highly restrictive it becomes much harder to
  innovate.

  Although this thread is mostly about having a second SD card, your
  comments seem to indicate a general attitude towards and lack of
  interest in generalized API support for enumerating peripherals:

   I'll only support one camera!  Okay.

  Not OK! If one wants to compete on the market one has to look at
  competitors that already sport two cameras, such as a front-facing
  camera. Think many Nokia phones, and Apple's iPhone 4G. (I added
  second camera support to my own Nokia Java MIDlet app back in 2006.)
  Do you want every Android phone manufacturer to invent and develop
  their own proprietary Android API extensions even to just keep up with
  existing functionality elsewhere? You encourage fragmentation!

  Also, please look across platform boundaries as well as look at
  broadening the scope towards gaming devices. What Microsoft is doing
  with Kinect (formerly Natal) involves either a stereo camera or a time-
  of-flight camera. Do you want individual Android device manufacturers
  to create proprietary API extensions here too? Why make it impossible
  to develop an Android counterpart of the Nintendo 3DS by sticking to a
  conventional single camera API, forcing proprietary extensions?

  Thanks!

  The vOICe for Android
 http://www.seeingwithsound.com/android.htm

  On Sep 11, 3:04 am, Dianne Hackborn hack...@android.com wrote:
   On Fri, Sep 10, 2010 at 2:33 PM, Doug Gordon gordo...@gmail.com wrote:
I am really surprised that the Android design would only account for
one of anything. In my experience, any time you say we're only going
to support one of feature X, the marketing or engineering departments
decide to add another X. In any case, having support for more than
one is the same as having support for any quantity.

   U...  I'll only support one touch screen!  Okay.  I'll only support
  one
   DPAD!  Okay.  I'll only support one CPU!  Okay.  I'll only support one
   graphics accelerator!  Okay.  I'll only support one SIM!  Okay.  I'll
  only
   support one headphone output!  Okay.  I'll only support one camera!
   Okay.

   A marketing or engineering department that can't accept limitations is an
   organization that will never ship a product.

   (And you don't note all of the complexity that comes from going from 1 to
  2
   -- how is this reflecting in the UI?  How does the user decide where they
   want their stuff to go?  How about telling them how much space is where?
    And now you've got to let them move stuff around.  I can make a good
   argument that multiple SD cards is just intrinsically a crummy user
   experience and should be avoided.  Heck even one SD card significantly
   complicates the UX.)

   --
   Dianne Hackborn
   Android framework engineer
   hack...@android.com

   Note: please don't send private questions to me, as I don't have time to
   provide private support, and so won't reply to such e-mails.  All such
   questions should be posted on public forums, where I and others can see
  and
   answer them.

  --
  You received this message because you are subscribed to the Google
  Groups Android Developers group.
  To post to this group, send email to android-developers@googlegroups.com
  To unsubscribe from this group, send email to
  android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com
  For more options, visit this group at
 http://groups.google.com/group/android-developers?hl=en

 --
 Dianne Hackborn
 Android framework engineer
 hack...@android.com

 Note: please don't send private questions to me, as I don't have time to
 provide private support, and so won't reply to such e-mails.  All such
 questions should be posted on public forums, where I and others can see and
 answer them.

-- 
You received this message because

[android-developers] Re: Can android support more than one sdcard?

Please stay on topic. Device enumeration is a generalization of the
ability to have and use more than one SD card. You have made it quite
clear now that you have little interest in that or in adding device
enumeration for other device classes.

On Sep 12, 9:54 am, Dianne Hackborn hack...@android.com wrote:
 Do you practice at being this way, or is it a talent?

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Can android support more than one sdcard?

Hi Mark,

I appreciate your thoughtful comments. Some things are fairly trivial
at API level, but hard at implementation level. Sometimes it is also
at API level not immediately clear which choices are most elegant and
future proof. I also realize that the Android team has been
exceedingly busy first realizing the core of what is currently needed
on most mobile devices, for the time being skipping certain
generalized features that have been available for quite some time on
other popular platforms, and that do have merit beyond the time to
market consideration. Ms. Hackborn's emotional and rather rude
response cut this discussion short, despite concrete examples of
existing implementations from Samsung as mentioned by Kostya and
Indicator. For cameras there exists the two-camera HTC Evo 4G, and
outside Android there exist two-camera phones from Nokia (I even have
an old Nokia 6680 with two cameras) and from Apple (iPhone 4G).
Therefore I felt that I am not just sketching some hypothetical
situation that awaits concrete examples of devices that are being sold
by the millions.

 -- New versions of the same methods are added to Environment that take
 some sort of identifier as a parameter, with some sort of
 getExternalStorageDevices() method to list them

Yes, I am aware of the organic growth option, but the zero-parameter
getExternalStorageDirectory() would have been redundant if support for
multiple devices had been foreseen and the parametrized method simply
limited in value range by letting a getExternalStorageCount() return
1 (or zero) until manufacturers support higher counts. The third-party
developer can then write code today that supports higher counts
without having to wait for a future version of Android that specifies
how getExternalStorageDirectory() gets an additional companion method
or overloads one of the parameters.

For zero risk with supporting a second camera one could have looked at
how Nokia supports additional cameras in Java ME using the capture://
locator, since the existing market has long given feedback on any
issues with that (such that one can at the same time avoid making the
same mistakes).

It largely boils down to the question what should come first, a
general future-proof API or an actual  implementation on a popular
device that needs an existing API to be generalized for more
widespread use. An actual implementation that is not supported by an
API is typically a bit ugly, brings legacy code issues later on, and
can discourage adoption of new features because third-party developers
will be less inclined to write brand-specific code to exploit such
features.

 No, she has made it quite clear now that she has little interest in
 doing any of that until there are concrete implementations ready to
 be, um, implemented.

OK, good to know. I guess I was hoping for the type of leadership that
Chris just mentioned.

Regards


On Sep 12, 12:43 pm, Mark Murphy mmur...@commonsware.com wrote:
 On Sun, Sep 12, 2010 at 2:59 AM, blindfold seeingwithso...@gmail.com wrote:
  I hope your colleagues will consider device enumeration as being
  important for limiting future fragmentation of a supposedly open
  platform and for encouraging new application areas, going well beyond
  nice.

 I imagine that they will add support for multiple forms of external
 storage as manufacturers request it (or, perhaps, where manufacturers
 contribute back code). As Ms. Hackborn indicated, an API for things
 like this is the tip of the iceberg. It's not also terribly relevant
 until the rest of the iceberg exists, and there's no sense in them
 spending time trying to design an API until they know what that API is
 going to need to contain.

 With respect to future fragmentation, the pattern for handling this
 is rather obvious. Let's take external storage:

 -- The zero-parameter getExternalStorageDirectory() and kin do what
 they do today, reporting on the default external storage

 -- New versions of the same methods are added to Environment that take
 some sort of identifier as a parameter, with some sort of
 getExternalStorageDevices() method to list them

 However, there are plenty of unknowns: what the identifier is
 (string or more complex object), what getExternalStorageDevices()
 returns (ArrayList or some Environment.DeviceRoster object), etc.
 Those details are impractical to design ahead of the full
 implementation. So they didn't try. This is not terribly surprising --
 in fact, it would have been more surprising had they spent a lot of
 time on it and skipped other functionality as a result.

 I am not aware of any compatible Android devices with multiple forms
 of external storage back in, say, January. There were some (e.g.,
 ARCHOS 5 Android tablet) that had multiple forms of external storage,
 but they were not in compliance with the compatibility definition in
 other areas. Hence, when Android 2.2 was being baked, particularly
 from the standpoint of low-level system stuff like external

[android-developers] Re: Can android support more than one sdcard?