@vigneshlin Not quite. It will be a Blink rendering engine in most cases on recent devices.
But Turbo mode in 'Opera Mini' loads the default WebView that comes with your Android OS.
While turbo in 'Opera for Android' uses the full custom Opera Blink rendering engine. Generally that means Turbo mode in 'Opera Mini' is slightly less capable with eventual feature restrictions and not the evergreen/edge version of 'Opera for Android'.

A couple things I noticed:

1 - Can't force reload a page yet. Will need a forced proxy refresh.

2 - Text Size has no effect yet. In my case, it uses the Amazon WebView FireOS font size settings as default font size. (be aware of that)

Found the answer to this from @andreasbovens. I guess we have no choice to deal with Opera Mini doing its own thing.

It does but their calculation of the viewport-width is very inconsistent (at least on Android). Hence the viewport is often not matching the device.

Opera Mini for Android seem to have a major issue with the correct determination of the 'viewport-width' size.
I have tested Opera Mini for over a year now, and whether on an SDK emulator or actual device, it's always incorrect.

Here is a use case on a Fire HD Tablet (Amazon Kindle Fire HD 7" 4th Gen):

The physical screen is 1280x800 1.5 DPR. Which at a Portrait Orientation should result in a layout Screen Size of 534 x 854 px.
Hover Opera Mini for Android (both 8 and 9 beta) returns a viewport-width of 381px with a DPR of 2.1, screen.width of 381px and window.outerwidth of 800px.

So the math 800/2.1 is correct, but where does it pull a docElem.clientWidth of 381px from the device data? I don't see how you get to that result.