Do you want to test the UI of your app or just run an instrumented test on ZXingCpp?

If it's the latter, you can add an AndroidJUnit4 test in app/src/androidTest like I do in my fork of the wrapper here. One key difference of my fork from the official wrapper is that it doesn't use an ImageProxy but the rather the data inside it, which makes testing a bit easier, of course.

Now, since the official wrapper requires an ImageProxy, you can use a mocking framework like Mockito to create a mocked ImageProxy object like it's done here.

My final goal is to run an espresso end to end UI test, I don't want to run unit test (This can be run easily with Mockito of course).

For instance, my feature open a screen which includes camera feature, scans barcode with ZxingCpp library, returns code and then do some stuff with it.

I can run espresso UI test for open my screen, bypass camera (so the decode library too) and go straight to my next screen with mock code.

But now I would like to not bypass camera and decode library but add their behavior into my UI test.

My first thought was to bypass camera frame and create an ImageProxy with bitmap or png file by myself, but it seams to be not possible.

Well, ImageProxy is just an interface, so you'd need to create your own implementation using that interface, and put your own test data into it. For ZXingCpp, only the luma channel (in plane 0) would be required, what's basically an uncompressed 8-bit grayscale image, just a byte array.

You can get this by converting your input image to the YUV format (e.g. with ImageMagick: convert frame.png -colorspace YUV frame.yuv) and then take the first width x height bytes of this file (e.g. dd if=frame.yuv of=luma bs=1 count=$((width * height))). Then load luma into a ByteArray, wrap this with a ByteBuffer, implement a ImageProxy.PlaneProxy, and return this for plane 0.

You can see here what ZXingCpp's BarcodeReader.read() really needs from an ImageProxy.

Now, while this should be feasible, it probably isn't worth the effort IMHO. You'd need a non-trivial amount of code just to test what ZXingCpp already tests anyway: that is reading a barcode 😉 So I would probably just bypass the camera and ZXingCpp in UI tests.