SurfaceView Apps don't resize

[android-testing]

Following apps fail to resize in Tieto(Jabol) MultiWindow solution.

• Puzzle Trooper
• Fruit Ninja
• Plants Vs Zombies
• Pop Star for Android (by PopDaddy Games)

[darkenk]

It seems like FruitNinja is using SurfaceView::setFixedSize. Commenting this function cause FruitNinja to resize properly (I don't know if this is a proper fix for such case, for me it's like workaround). PuzzleTrooper is another case. It resize properly (SurfaceView is resized), but only part of SurfaceView is used for rendering. Maybe app is checking renderable area only on activity start? According to PvZ, this is not free app, so I didn't check it.
To sum app, this is not trivial case. I need to consider some other solutions like prohibit of displaying fullscreen app in window or something like that.

[android-testing]

Yes, commenting SurfaceView.setFixedSize() does fix the resize issue for FruitNinja app but as you said not the PuzzleTrooper app. I also agree that PuzzleTrooper does resize but not its content. In my view, this is where most of the apps specially Games will fail to resize. I also agree that this is not the trivial case. But I believe that it makes sense to investigate further into SurfaceView resize issue to make this solution work fully.

[android-testing]

Another interesting fact I found is that FruitNinja app starts resizing without commenting SurfaceView.setFixedSize() method when user locks the device and unlocks again. At this point of time, if user initiates resizing either from left/right controls, app does resize. I think that might give some clue? But obviously that is not happening with Puzzle Trooper or PvZ app. I downloaded cracked PvZ app but testing Puzzle Trooper gives the exact result as PvZ.

[darkenk]

Are you able to reproduce it in 100%? I also experience that behavior, but in my case it was only twice. Could you please paste adb shell dumpsys window to http://pastebin.com/ when FruitNinja is able to resize?

[android-testing]

Yes, I tried many times and it did work all the time. I can't paste the dumpsys logs to pastebin,com as it allows only 500 KB of data and the log file is 1.9 MB. I sent you the log file on your email. Please check and let me know if you want anything else.

[android-testing]

Hello Darek,

I also tested Pop Star app and that too doesn't re-size like other apps I
mentioned on GitHub. I did update the list of SV apps which are not
working on GitHub issue section too.

Let me know if there is any update on this issue. FYI - Rockchip
multi-window solution does re-size Pop Star app which is shown in this
video.

http://www.youtube.com/watch?v=FfR1Jvyin0Y

So there might be some clue or what Rockchip is doing something different
than yours.

Thanks,

On Mon, Jul 28, 2014 at 6:34 PM, Dariusz Kluska notifications@github.com
wrote:

Are you able to reproduce it in 100%? I also experience that behavior, but
in my case it was only twice. Could you please paste adb shell dumpsys
window to http://pastebin.com/ when FruitNinja is able to resize?

—
Reply to this email directly or view it on GitHub
#1 (comment)
.

[darkenk]

Thanks for update. Unfortunately, I cannot reproduce resizing as you do. Could you please turn on DEBUG_SURFACE_TRACE, DEBUG_WINDOW_TRACE, DEBUG_VISIBILITY, DEBUG_LAYOUT in WindowManagerService.java, turn DEBUG in SurfaceView.java and put Log.e(LOG_TAG, "setFixedSize: " + width + "x" + height, new RuntimeException()); into SurfaceHolder::setFixedSize at the beginning? Before running FruitNinja please erase logcat (adb logcat -c). Please put logs into pastebin or something like that. According to Rockchip, I think they use compatibility mode. I was able to resize fruit ninja using compatibility mode, but it looks ugly.

[android-testing]

Sure, will provide you the logs.

Regarding fixing resize of Fruit Ninja app, these are the options I did try in SurfaceView.java and app does resize but obviously with some performance issue as framework keeps updating the screen.

In SurfaceView.setFrame() method, if you make any one of below changes, then Fruitninja app resizes but not PvZ, PuzzleTrooper or Pop Star apps (not sure why they don't resize but FruitNinja does):

• mReportDrawNeeded = true;
• mUpdateWindowNeeded = true;
• updateWindow(true, false);
• updateWindow(false, true);
• updateWindow(true, true);

So if you try any one of the options, then FruitNinja app resizes well. Let me know if above findings provide any insights.

[darkenk]

Thanks for your findings, it gave me idea, which works somehow. If you add
mRequestedWidth = 380;
mRequestedHeight = 480;
in setFrame(), and change updateWindow to updateWindow(true, true) this will cause to resize PopStar. This is reasizing using compatibility mode. Unfortunately, touches are in wrong positions. This is just a hack, which can help to find other solution.

[android-testing]

Logs of resizing FruitNinja app on nexus 7 (http://sebsauvage.net/paste/?c5df3e05dadc7a6a#WDCVmHpp8QeyXdX+2YkLP073qjxG81YxfBiWudZTOAA=)

Pastebin doesn't allow to share logs if log size crosses more than 500 kb. I found Zerobin very useful.

Steps to reproduce:

• Launch device and activate Jabol from settings on Nexus 7.
• When device starts, it remains in portrait mode. Launch FruitNinja in portrait mode.
• Device gets rotated by itself and FruitNinja app runs in landscape mode.
• Lock/unlock the device and initiate the resize of FruitNinja from right/left UI controls.
• Fruit Ninja app resizes when device locked/unloked by user but it doesn't resize when launched initially.

[android-testing]

BTW - How to run any app in compatibility mode programmatically without hard-coding anything? You did mention about Rockchip runs app in compatibility mode. But which class should be modified to run app in compatibility mode?

FYI - I also figured that if you add below code in onMeasure() of SurfaceView class, then also FruitNinja app resizes:

mRequestedWidth = width;
mRequestedHeight = height;
mWinFrame.set(new Rect(0,width, 0, height));

But obviously issue remains open for PvZ and PuzzleTrooper apps. And Pop Star app resizes well but as you said the user input goes to wrong location on screen.

[darkenk]

Thanks for logs. According to my knowledge, compatibility mode is turn automatically by android, when app does not support certain screen dimensions. More info here: http://developer.android.com/guide/practices/screen-compat-mode.html. I don't know exactly whether Rockchip use compatibility mode, but I think so (apps on their movies looks like they were started in compat mode). According to class, I recommend looking at WindowManagerService.java and related.

[android-testing]

Did you find anything interesting in the logs? I did dig into WindowManagerService.java and other classes but can't see the root cause of why SV apps don't resize. I doubt that if we run those apps in Rockchip's solution, they may fail too. But don't have rockchip device to confirm. So not 100% sure about this. Do you have any other info on this issue? Thanks