IssueTracker

To make life even more bizarre, I ran into another situation where camera.open()
worked in the sense that it didn't hang as in the previous example, but a following
camera.setParameters() did hang:

   Log.i("OIC", "JUNKcam5");                  
   try { camera.setParameters(parameters); }
   catch (Exception e) { Log.e("OIC", e.getMessage(), e); }
   Log.i("OIC", "JUNKcam6");        

then only gave as output

   JUNKcam5
   
In this case too, the built-in camera app would just hang with a black screen, and I
had to power off the phone to get back.

Regards

This issue is assigned to an engineer for further evaluation

Great. I still regularly run into this problem while developing my camera app, say
once or twice a day. It looks a bit like the camera does not always get released, and
once detached from a given app (when the app crashes or perhaps leaks some context
when it exits normally) no app can connect to it anymore, including my own app. I
still only know of the power cycle to get the camera back.

Could you attach the output of adb bugreport or at least adb logcat -v threadtime the
next time this happens? This'll assist with diagnosing the issue. Thanks.

I will do so when it happens again, but I remember that there was
never any error or warning in the LogCat output. It just stopped
giving new lines. Only "bisection" with my own inserted Log messages
let me identify the exact line where the app just froze, as described
before. It was always one of the camera.* commands, but not always the
same command. One thing that "helps" to run into the problem more
often is to recompile the app in Eclipse and launch the updated APK
via the USB cable while the program is still running on the phone:
Eclipse happens to just kill the app's process without letting it
first go through onPause() and onDestroy() to let my app properly
release the camera, and that certainly increases the probability of
the camera "hanging" until after a full power-cycle. Of course the
need for a complete power cycle to "reset" the G1 camera is
unacceptable under any circumstance.

Thanks

Since this is probably a low-level issue (very possibly below Android itself in
fact), some of the other logs captured by adb bugreport (e.g. the kernel log) are
likely to contain more information than logcat.

You are probably right, JBQ.

Well, with the "trick" to let Eclipse launch a recompiled APK (for exactly the same
code) while my program was still running on the phone, I managed to "hang" the camera
already in the second run. After this happened I ran adb bugreport > junkcam.txt. The
camera would not also not work anymore with other camera apps such as SnapPhoto or
the built-in Camera app, so I'll have to power-cycle my dev phone 1 for the umptieth
time now...

Attached is the adb bugreport output. Hope you will find a useful trace of what
happened with the camera.

Thanks

Superb, thanks. This'll hopefully help our camera experts figure out what might be
going wrong.

Thanks JBQ. Hope so too! I just started looking into the junkcam.txt results...

As you can see from searching for the string "setParameters()" in junkcam.txt, the
QualcommCameraHardware output is quenched in the second run right after this command,
and from the output after "openCameraHardware: call createInstance" reading
"createInstance: X return existing hardware" in the second run I gather that indeed
the camera had not been released. That by itself is no so strange because Eclipse
killed my process non-gracefully by not letting it release the camera hardware first,
but the bad consequence is now that the camera is no longer bound to the previous
instance of my (killed) app and my new instance cannot bind to it so it cannot
release it either. It looks like the camera is kind of "floating", thinking that it
is still bound to a process that is no longer there, and thus blocking access by any
other apps or app instances.

Clearly there ought to be a means for the camera to recover from such nasty deadlock
situations.

Regards

Thanks for the information, we appreciate the time you're spending on this in order
to help us.

This issue was fixed in the source code and the fix will be in a future release

Apparently the fix is either not in Cupcake or it is not 100% effective, because I
had the same problem yesterday on day 1 after flashing my ADP with the newly released
Cupcake firmware. I had to reboot the phone to get the camera back.

> This issue was fixed in the source code and the fix will be in a future release

OK, I've now had this bad problem several times again on my ADP with Cupcake
(1.5_r1), so it is apparent that the problem was *not* fixed! Only power cycling
brings the camera back, or else no camera application can access the camera. This is
a guarantee for a miserable user experience. :-(

I've the same problem on android 1.5 (camera open error) someone can give me the clue?
Thanks.

it seems that 1.6(Donut) still has the same problem.
I've confirmed at ADP1 + Donut.  
I don't know/see what is the trigger of this problem but after that,
all camera apps never works until reboot(power off -> power on).

I have seen the same behaviour on the Nexus One.
Camera.open hangs. I cannot start any other camera app, killing the process doesn't
do anything for the camera lock. I have to restart the device.

If I use my application nicely, it works, but when doing the monkey test pressing
home and my application icon around 20 times in fast pace, this is one of the issues
I'm seeing.

I have not seen this with the built in Camera app, perhaps it is doing something
different.

Same problem with my HTC Desire, After camera hangs, opening the built in camera apps quietly exit.
Using latest 2.1 Android.
Sometime my app completely hangs. Only a restart bring the camera back to life.

For the record, I am having the same issue right now with Google Glass (which means I'm using Android 4.4.2, API 19; the Glass firmware is XE22). Still I don't understand if this is the fault of some specific devices, or of the Android platform.

Me and my father experience this odd bug for like 2 weeks , i have an s3 Neo he has an s5 . If i try to open the camera to take a picture my phone freezes and a lock of the screen + waiting or restart of the device is required

Experiencing the same issue on my DOMO Slate S5 device with Android version 4.4.2. What do you suggest the next steps should be here?

I am facing this issue for several times and there is no log or any crash or error in the logcat i want to run camera as service and my service file is attached with this comment. i am testing this code on my Samsung Galaxy Grand Prime plus. my phone just freeze or hang and did not respond to any command. until unless i need to restart it by removing the battery. Otherwise if i am running my application while debugging just stopping this app will make my device in normal state. I am using Android Studio 3.2 Canary 17.

It has been almost 2 years since this has been opened. Can someone tell me why this is still an issue? What is the status report google?

If you want to load that JS file without document.write, set the callback parameter like so:

http://maps.google.com/maps/api/js?sensor=false&callback=googleCallback

You'll see that it loads the js with a different getScript function:

  function getScript(src) {
    var s = document.createElement('script');
   
    s.src = src;
    document.body.appendChild(s);
  }

Can someone give a clear example on how to load google maps correctly? This issue has to be solved by now.

[Comment deleted]

To help us evaluate fixing this issue, are these issues with CSP purely in the context of Chrome extensions, or use of CSP generally on the web (through use of the Content-Security-Policy header)?

I included a gist at #23 with a failing test for a normal website (i.e. no Chrome plugin)

Has there been any update here?  

Allowing 'unsafe-eval' is a deal-breaker, and far from ideal.

As the last comment was in May 2015: this is *STILL* an issue.

It basically requires every public website (not even an 'extension' which needs to use the hackish sandboxing stuff) that utilizes a proper CSP header to include 'unsafe-eval' and a very long list of image sources too.

The eval() usage is still in the API. As others noted, after more than two years, maybe time to drop usage of Google Maps API, as it makes sites insecure.

This issue is on our roadmap. It's clear that CSP is important, and is indeed a deal-breaker.

This won't be simple for us to fix. We'll keep everyone posted with our progress.

This is insane - Google Maps is incompatible with Google Apps. The sandboxing technique is not viable for me. I'm going to have to use a different map tool in my Chrome app.

hmm this totally sucks... people with template solutions like smarty will totaly bomb if they want to integrate a remote apis... i presume some how templaters like smarty inline the javascript codes and links from the template files... utterly diabolical google chrome cant use google maps api? and templaters cant load there apis :(

[Comment deleted]

The problem is bigger then you realize :(

This should be the solution for web developers but of course as per usual chrome fails to come correct at the critical hurdle.. img-src .. and please feel free to put me straight if you know why this is or what I might of done wrong.

The snippet bellow is to get leaflet map working for instance *not even google maps* every thing works and seems to make sense untill img-src fowls up.

<meta http-equiv="Content-Security-Policy" content="
default-src http://mydomain.com/jobtracker;
connect-src http://mydomain.com http://*.mapbox.com/;
font-src http://mydomain.com http://*.mapbox.com/ data:;
frame-src http://mydomain.com http://*;
img-src http://* data: filesystem: blob:;
media-src http://mydomain.com http://*;  
object-src  http://mydomain.com http://mapbox.com;
script-src 'unsafe-inline' 'unsafe-eval'  http://mydomain.com http://*;
style-src 'unsafe-inline' http://mydomain.com http://*;
" />

Can you fix it please google!! ;(
I should invoice google for the loss of productivity...

forgive me for being kind of sick of these security features that google keeps asserting on to us each time forgetting or overlooking something trivial but important and thus setting our projects weeks and causing regressions

Just so you all know even with the `CSP disable extension` activated you still need to provide a full CSP header with every single remote resource white listed to have a hope in hell of dealing with this I even changed my whole setup to SSL and it still persists so please do explain to me how a SSL connection can be man in the middle'd????

How can I close this ticket? It will not be fixed.
All this talk is just useless noise in my mail.

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

Just to let everyone know, we've been working on a solution. We'll have something to announce soon.

The experimental version of the Maps API now no longer uses eval() or document.write. You can therefore load the API without the unsafe-eval and unsafe-inline CSP directives.

sadly i have to report still does not work for me :(

<meta http-equiv="Content-Security-Policy"
      content="default-src *;
               script-src 'self' 'unsafe-inline' 'unsafe-eval'
                           https://mysite.com:*
                           https://*.gstatic.com
                           https://*.googleapis.com
                           https://*.gstatic.com
                           https://*.googleapis.com
                           https://*.google.com
                           ;
               style-src  'self' 'unsafe-inline'
                           https://mysite.com 
                           https://*.gstatic.com
                           https://*.googleapis.com
                           https://*.gstatic.com
                           https://*.google.com
                           https://*.googleapis.com;
">
<script type='text/javascript' src='https://maps.google.com/maps/api/js?v=3.exp&sensor=false&callback=googleCallback'></script>

function googleCallback() {
alert('that will be the day');
}

Can you post the error you're getting? It seems to be working fine for me.

Refused to load the script 'https://maps.google.com/maps/api/js?v=3.exp&sensor=false&callback=googleCallback' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' 'unsafe-eval'".

[Comment deleted]

Is there any update on a resolution to this issue?

Change your Content-Security-Policy:
- delete 'unsafe-inline' and 'unsafe-eval'
- keep https://*.google.com, etc., on your whitelist

Regarding #49
When I load your HTML in Chrome, there are no errors in the console.

Regarding #51
The error message is different from the HTML you posted.
The error message doesn't list https://*.google.com as an allowed script-src, and this is why the browser rejects the script. If you use the meta tag from your previous post, it works correctly.

Regarding #53
There are a number of different issues being discussed here, which one are you referring to? If you can be specific, we can probably help you :-)