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 https://github.com/tieto/multiwindow_for_android/issues/1#issuecomment-50335058 .

[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

[darkenk]

Sorry for late reply, but I was quite busy with other tasks. I found nothing in logs which can move me closer to solution. Have you tried with previous version of Tieto Multiwindow (jb 4.2.2)? If not could you please try? Previous version is on branch tieto_multiwindow. In previous solution Configuration is handled differently. Configuration is a structure which holds information eg. about screen dimension. Maybe this will force application to restart. I'll try to find some time during this week to focus on resize issue.

[darkenk]

I've focused on PuzzleTrooper. It is using cocos2d framework. At first glance it is using Cocos2dxGLSurfaceView as implementation of SurfaceView. The size is handled in onSizeChanged method which pass this screen size to Cocos2dxRenderer. Unfortunatelly Cocos2dxRenderer implements only onSurfaceCreate and not onSurfaceChange (this method is empty).

[android-testing]

Well, trying 4.2.2 won't make much difference as far as I understand this issue. Note that changing configuration for different size of windows is not the best solution as it opens another bag of worms.

Re: your comment on PuzzleTrooper app, then it means that there is no way to resize such apps as we can't control 3rd party apps/implementation. Hence, I can conclude that there is no 100% working solution for such apps while resizing them. In such cases, I'm not sure how we can notify the framework to magically resize the window?

[darkenk]

I've made some modification of Configuration and the result was ability to downscale PuzzleTrooper. Now I've focused on compatibility mode, but without any success. The compatibility mode can be toggled using setFrontActivityScreenCompatMode() in AMS, but this need some extra modifications in CompatibilityInfo.java. I haven't figured out yet what kind of modification need to be done. If you have time, please look at this file. Maybe you will find something interesting.

[android-testing]

Sounds interesting but can you share what changes you have applied to downscale PuzzleTrooper app? So I can reproduce the same result from my end.

Sure, I'm looking into CompatibilityInfo.java class and update you if I find anything useful.

[darkenk]

Downscaling PuzzleTrooper application introduce huge lagging in whole system. I've stopped working on this issue for now. I think only reasonable solution is give user a possibility to launch application in fullscreen for apps which are not able to resize.

[android-testing]

Can you tell me how are you downscaling Puzzle Trooper app? I will look into this issue. But would like to know how exactly are you down scaling the app.

Also, if we go for the approach of launching such apps which are not able to resize in full screen, then how to detect such apps? Which properties, flags etc. are different for such apps than regular apps which do resize?