Mark M. | has entered the room |
Mark M. | turned on guest access |
Alesandro | has entered the room |
Mark M. |
hello, Alesandro!
|
Mark M. |
how can I help you today?
|
Alesandro | |
Nov 10 | 4:00 PM |
Mark M. |
I will try my best, though most of the camera2 API is beyond what I have used
|
Mark M. |
what is your first question?
|
Alesandro |
View paste
|
Paul | has entered the room |
Mark M. |
(BTW, hello, Paul -- I will be with you shortly!)
|
Paul |
Greetings all.
|
Alesandro |
View paste
|
Mark M. |
um, well, I hesitate to suggest "alcohol", though that is a popular way of dealing with scaling the TextureView :-)
|
Mark M. |
frankly, this stuff makes my head hurt
|
Mark M. |
I have a mostly-working approach in my CWAC-Cam2 library
|
Mark M. |
and it takes me hours to make sense of my own code if I have to go in and try making changes to it
|
Mark M. |
fortunately, it has been many months since I needed to work on that code
|
Nov 10 | 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. | |
Mark M. |
that is my equivalent of the matrix stuff from the Google sample that you cited
|
Mark M. |
I have not tried the Pixel C since it was upgraded to 7.0
|
Mark M. |
on 6.0, it was a disaster
|
Mark M. |
(IIRC)
|
Mark M. |
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
|
Mark M. |
Paul: your turn! do you have a question?
|
Nov 10 | 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.
|
Paul |
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
|
Mark M. |
that's another app
|
Mark M. |
Espresso can only test your app
|
Mark M. |
you would need to use UI Automator
|
Paul |
Does UIAutomator help at all?
|
Mark M. |
yes
|
Mark M. |
that is for integration testing
|
Mark M. |
which is really what you're doing here
|
Paul |
Yes.
|
Mark M. |
testing this completely with UI Automator should work
|
Mark M. |
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
|
Mark M. |
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
|
Nov 10 | 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
|
Mark M. |
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.
|
Alesandro |
It seems as only the RAW formats used by the old camera API have framework functions to do this conversion.
|
Alesandro |
View paste
|
Alesandro |
View paste
|
Nov 10 | 4:20 PM |
Mark M. |
no, sorry
|
Mark M. |
I have managed to avoid YUV entirely
|
Mark M. |
if there were built-in APIs for this, Eddy Tavala surely would have mentioned it
|
Alesandro |
View paste
|
Mark M. |
not personally
|
Mark M. |
I just know that he's Google's camera2 guy, at least on Stack Overflow
|
Mark M. |
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
|
Mark M. |
I am sorry that I could not be of greater assistance on this question
|
Nov 10 | 4:25 PM |
Mark M. |
let me see if Paul has a follow-up question, and I will return to you shortly
|
Mark M. |
Paul: do you have another question?
|
Mark M. |
OK, if either of you come up with another question, go right ahead
|
Nov 10 | 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
|
Mark M. |
who-hoo!
|
Mark M. |
:: 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
|
Mark M. |
but, it's conceivable that you could figure out how to leverage that preview code
|
Mark M. |
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
|
Nov 10 | 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
|
Alesandro |
View paste
|
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
|
Mark M. |
this is memory intensive and a bit slow on some devices
|
Mark M. |
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 |
Nov 10 | 4:40 PM |
Lawrence K. |
Hello!
|
Nov 10 | 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...
|
Lawrence K. |
At the bottom your describe how to grant permissions for ACTION_IMAGE_CAPTURE, which is what I'm doing.
|
Lawrence K. |
But my code works without doing that.
|
Lawrence K. |
I add no permissions to my intent and the camera app is able to write just fine.
|
Lawrence K. |
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.
|
Lawrence K. |
My min is 14 (4.0).
|
Mark M. |
OK
|
Lawrence K. |
Okay then, I'll test with an old version if I can.
|
Lawrence K. |
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
|
Mark M. |
however, you'll need the other scenarios if you're going all the way back to 14
|
Mark M. |
(where the 14/15 scenario, using PackageManager, really stinks)
|
Lawrence K. |
Maybe I can bump to 16, then.
|
Lawrence K. |
I think 14/15 is less than 1% of my users.
|
Lawrence K. |
Yeah 0.5%.
|
Mark M. |
the "stinks" part is that you have to blindly grant rights to all camera apps
|
Nov 10 | 4:45 PM |
Mark M. |
which offends my tender sensibilities
|
Mark M. |
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
|
Mark M. |
well...
|
Mark M. |
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.
|
Lawrence K. |
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
|
Mark M. |
it will give you more consistent results, as you are not dealing with N possible third-party camera apps
|
Mark M. |
which is why I wrote the library
|
Mark M. |
the library itself is not perfect
|
Mark M. |
and varying camera hardware means that my library may give you a different set of inconsistent results
|
Mark M. |
IOW, YMMV
|
Lawrence K. |
If I bump to 16, and target 24, am I reasonably safe?
|
Lawrence K. |
(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
|
Mark M. |
er, know
|
Mark M. |
no exception gets raised in your app, since it is the other app that crashes
|
Mark M. |
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
|
Mark M. |
and so, in the fullness of time, most camera apps will support content:
|
Mark M. |
where "the fullness of time" is measured in years
|
Nov 10 | 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
|
Alesandro |
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
|
Mark M. |
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
|
Mark M. |
your plan reduces risk
|
Mark M. |
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.
|
Lawrence K. |
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!
|
Nov 10 | 5:00 PM |
Mark M. |
and that's a wrap for today's chat
|
Mark M. |
the transcript will go up on https://commonsware.com/office-hours/ shortly
|
Mark M. |
the next chat is Tuesday, also at 4pm US Eastern
|
Mark M. |
have a pleasant day!
|
Lawrence K. | has left the room |
Mark M. | turned off guest access |