Office Hours — Today, November 10

Yesterday, November 9

Mark M.
has entered the room
Mark M.
turned on guest access
Alesandro
has entered the room
Mark M.
hello, Alesandro!
how can I help you today?
Alesandro
View paste
Hi Mark,

I have two questions on working with the camera 2 API.
Nov 10
4:00 PM
Mark M.
I will try my best, though most of the camera2 API is beyond what I have used
what is your first question?
Alesandro
View paste
My app is using the camera 2 API to display a preview of the front facing camera.
I do apply a transformation matrix to the texture view like it is done in the Google example code (https://github.com/googlesamples/android-Camera2Raw).
Paul
has entered the room
Mark M.
(BTW, hello, Paul -- I will be with you shortly!)
Paul
Greetings all.
Alesandro
View paste
This does work on all device orientations on my Nexus 5X but not on my Pixel C.
If switching to the front facing camera and turning the tablet to either side the sample code shows a stretched preview.
Any suggestions?
Mark M.
um, well, I hesitate to suggest "alcohol", though that is a popular way of dealing with scaling the TextureView :-)
frankly, this stuff makes my head hurt
I have a mostly-working approach in my CWAC-Cam2 library
and it takes me hours to make sense of my own code if I have to go in and try making changes to it
fortunately, it has been many months since I needed to work on that code
4:05 PM
Mark M.
other than "take a look at how I did it", there is not a lot that I can suggest
Alesandro
I could try if your code works on my Pixel C.
Mark M.
that is my equivalent of the matrix stuff from the Google sample that you cited
I have not tried the Pixel C since it was upgraded to 7.0
on 6.0, it was a disaster
(IIRC)
you might try just running my demo-playground/ app first on your Pixel C, to see how if fares
Alesandro
Why was it a disaster? Isn't the problem on all tablets?
Mark M.
tablets in general seem to have less testing done on their camera implementations
Alesandro
Maybe you should answer Pauls question now and I will try it on the device.
Mark M.
if my sample app's preview does not work, then my algorithm probably will not help you
Paul
I'll take that opening. :-)
Mark M.
Alesandro: I'll be back with you shortly
Paul: your turn! do you have a question?
4:10 PM
Paul
OK, my question is how you would deal with the following: you want to test a options menu entry using a connected check test (Espresso). The option menu entry provided feedback to the app by sending mail to the developer. The issue is that the mail tool is selected via an Intent and requires a "send" or "cancel" in the mailer app.
Are you with me so far?
Mark M.
yes
Paul
So I am struggling with how to get Espresso to control the mail tool.
Mark M.
it can't
that's another app
Espresso can only test your app
you would need to use UI Automator
Paul
Does UIAutomator help at all?
Mark M.
yes
that is for integration testing
which is really what you're doing here
Paul
Yes.
Mark M.
testing this completely with UI Automator should work
I do not know how readily you can blend Espresso and UI Automator
Paul
That was my next question. :-)
Mark M.
in principle, it could work, insofar as both can run under the same JUnit runner
Paul
I'll google it and see where it leads.
Mark M.
but you might wind up with some custom IdlingResource to get Espresso to wait until your UI Automator code completes
or something like that
Paul
Not a problem. I've written idling resources already.
Mark M.
probably some folk have tried it, and hopefully somebody wrote about it
4:15 PM
Paul
Worst case, I'll post a question to Stack Overflow and answer it myself if need be.
Mark M.
a fine, upstanding solution!
Paul
Thanks for sharing your info.
Mark M.
sorry I didn't have a complete solution for you
let me swing back to Alesandro for his other camera2 question, and I'll return to you in a bit
Paul
Not a problem. Just knowing it is not trivial is a very good thing.
Mark M.
Alesandro: back to you! I think you said that you had two camera2 questions?
Paul
I'm all done and will catch you soon, no doubt.
Alesandro
I need to convert the RAW camera image, which is using YUV_420_888 format because of camera2 API, to a bitmap.
It seems as only the RAW formats used by the old camera API have framework functions to do this conversion.
View paste
The only thing I have found is this snippet on stack overflow:
http://stackoverflow.com/questions/36212904/yuv-420-888-interpretation-on-samsung-galaxy-s7-camera2
View paste
Sadly this code does not work on my Pixel C and probably not on some other devices too.
Do you know any other ways to do this preferably using build in android APIs?
4:20 PM
Mark M.
no, sorry
I have managed to avoid YUV entirely
if there were built-in APIs for this, Eddy Tavala surely would have mentioned it
Alesandro
View paste
I would love to do so too but I have to apply some algorithms to the image and using jpeg directly is too slow.
Btw do you know Eddy?
Mark M.
not personally
I just know that he's Google's camera2 guy, at least on Stack Overflow
and that 80% of his answers are waaaaaaaaaaaaaaaaaay too complicated for my little brain to understand :-)
Alesandro
I also do not have a background in image processing which makes dealing with this topic really hard.
Mark M.
agreed
I am sorry that I could not be of greater assistance on this question
4:25 PM
Mark M.
let me see if Paul has a follow-up question, and I will return to you shortly
Paul: do you have another question?
OK, if either of you come up with another question, go right ahead
4:30 PM
Paul
has left the room
Alesandro
Not a new question but if it is ok for you we could talk once more about the texture view problem.
Mark M.
sure... bearing in mind that I may not be a lot of help :-(
Alesandro
View paste
I played with the Cam2 Picture Playground a bit on my Pixel C.
Sadly I have not looked into this project before.
But it seems to work :)
Mark M.
who-hoo!
:: does happy dance ::
Alesandro
Even if you can not remember but yo nailed it!
Mark M.
now, my overall project is not going to be much help to you -- for example, it does not deal with RAW images
but, it's conceivable that you could figure out how to leverage that preview code
note that the preview code is aimed at a "full-bleed preview", where we're willing to crop the preview to get the image to fill the entire TextureView
4:35 PM
Mark M.
if your preview is more like the one from the Google sample, where you want to have some blank space to allow the entire preview to fit on the screen, my algorithm may not work "out of the box"
Alesandro
View paste
Currently I do not crop the preview but I will have a look at it.

Can you say some words on the option "Skip orientation normalisation"?
View paste
Is it the code which does determine how the image is actually rotated?
(I solved this problem already.)
Mark M.
the default behavior of the library is to look at the EXIF orientation header and try rotating the image itself, to eliminate the need for the header
this is memory intensive and a bit slow on some devices
so, the skip option disables that default behavior, so the library saves the image as it gets it, which means sometimes you get the EXIF orientation header and sometimes not, depending on camera hardware
Alesandro
ok
Lawrence K.
has entered the room
4:40 PM
Lawrence K.
Hello!
4:40 PM
Mark M.
Alesandro: let me take a question from Lawrence, and I'll be back with you shortly
Alesandro
sure
Mark M.
Lawrence: hi! do you have a question?
Lawrence K.
Hi Mark. I was reading this page: https://commonsware.com/blog/2016/08/31/grantin...
At the bottom your describe how to grant permissions for ACTION_IMAGE_CAPTURE, which is what I'm doing.
But my code works without doing that.
I add no permissions to my intent and the camera app is able to write just fine.
Is it because of android:grantUriPermissions="true" in the <provider>?
Mark M.
what version of Android are you testing on?
Lawrence K.
24
Mark M.
that's already covered then
Lawrence K.
My concern is that this won't work on other versions.
Mark M.
quoting myself from that blog post, "And, as of Android 5.0, it also handles EXTRA_OUTPUT on ACTION_IMAGE_CAPTURE, ACTION_IMAGE_CAPTURE_SECURE, and ACTION_VIDEO_CAPTURE."
Lawrence K.
google's own sample code for this doesn't do anything with permissions.
Mark M.
their sample code assumes that they are running on Android 5.0+
Lawrence K.
Sorry I didn't read it carefully.
My min is 14 (4.0).
Mark M.
OK
Lawrence K.
Okay then, I'll test with an old version if I can.
Thank you!
Mark M.
in my example, the addFlags() for >= LOLLIPOP is superfluous, but I like having it there, as this whole issue is largely undocumented
however, you'll need the other scenarios if you're going all the way back to 14
(where the 14/15 scenario, using PackageManager, really stinks)
Lawrence K.
Maybe I can bump to 16, then.
I think 14/15 is less than 1% of my users.
Yeah 0.5%.
Mark M.
the "stinks" part is that you have to blindly grant rights to all camera apps
4:45 PM
Mark M.
which offends my tender sensibilities
however, on those older devices, using a content: Uri in general is risky business
Lawrence K.
Ugh, should I use file: for that?
Mark M.
Google's own camera app did not support that until this summer
well...
to be honest, if you're using ACTION_IMAGE_CAPTURE, the safest thing is to keep your targetSdkVersion below 24 and stick to file for a while
Lawrence K.
I wanted to support multi-window.
Should I use your cam2 instead?
Mark M.
yeah, well, that's the downside of having a targetSdkVersion below 24
Lawrence K.
I was trying to avoid such a drastic change.
Mark M.
that's an option
it will give you more consistent results, as you are not dealing with N possible third-party camera apps
which is why I wrote the library
the library itself is not perfect
and varying camera hardware means that my library may give you a different set of inconsistent results
IOW, YMMV
Lawrence K.
If I bump to 16, and target 24, am I reasonably safe?
(1.2% on 16)
Mark M.
the problem is that if you supply a content: Uri, and the third-party camera app can't handle it, you have no way to k now
er, know
no exception gets raised in your app, since it is the other app that crashes
as a developer, you could see stack traces from the other app in LogCat, perhaps, but that doesn't do you a lick of good at runtime in production
Lawrence K.
I suppose it's not too hard to stick with file: if SDK < 24, right?
Mark M.
most camera apps should support file:, since that's what was used primarily until this summer
and so, in the fullness of time, most camera apps will support content:
where "the fullness of time" is measured in years
4:50 PM
Alesandro
I will leave now and play with cam2 lib a bit - thanks Mark!
Mark M.
Alesandro: OK, best of luck!
Alesandro
thanks
bye
Alesandro
has left the room
Mark M.
Lawrence: I really really really really wish that the ACTION_IMAGE_CAPTURE protocol gave us some way of detecting what schemes the camera app supported for the Uri
that's a big limitation of passing a Uri in an extra
Lawrence K.
Okay so my plan is file: for SDK < 24 and content: for SDK >= 24, and not do any of the permission stuff on your page.
Mark M.
if ACTION_IMAGE_CAPTURE had us pass the Uri in the data facet of the Intent (e.g., setData()), this would be much simpler
your plan reduces risk
if the user installs some third-party app and routes your ACTION_IMAGE_CAPTURE request to it, and that app does not handle content:, you're out of luck
Lawrence K.
I already get the proper external storage write permissions for the right SDK values, so file: should always work < 24.
Where "always" is in quotes.
Mark M.
most of Android app development is in quotes
Lawrence K.
Keeps you employed! :-)
Mark M.
there are fringe benefits, to be certain :-)
Lawrence K.
Okay thank you Mark, I'll give that a shot.
Mark M.
you're welcome!
5:00 PM
Mark M.
and that's a wrap for today's chat
the transcript will go up on https://commonsware.com/office-hours/ shortly
the next chat is Tuesday, also at 4pm US Eastern
have a pleasant day!
Lawrence K.
has left the room
Mark M.
turned off guest access

Yesterday, November 9

 

Office Hours

People in this transcript

  • Alesandro
  • Lawrence Kesteloot
  • Mark Murphy
  • Paul