Dynamic resolution

[LamprosPitsillos]

Is your feature request related to a problem? Please describe.
Using waydroid on tiling window managers is really inconvenient , require that either you leave the whole space for waydroid or doing other hacky solutions.

Describe the solution you'd like
That the android system will adjust to the resolution (available space ) that is given to it .

Describe alternatives you've considered
An alternative could be for the prop set to modify the running instance live instead of needing a restart.

 waydroid prop set persist.waydroid.height 500
 waydroid prop set persist.waydroid.width 943 

Then users could script and use this feature to achieve what i was talking about.

Information about my system :

❯ waydroid --version
1.4.1

OS: NixOS 23.11
WM: Hyprland (Wayland) v0.27.0 
CPU: Intel(R) Core(TM) i5-8250U (8) @ 3.4 Gz
GPU 1: Intel UHD Graphics 620
GPU 2: NVIDIA GeForce MX150

[TriMoon]

Did you try: https://docs.waydro.id/usage/waydroid-prop-options

• waydroid prop set persist.waydroid.multi_windows true/false (bool)
  Enables/Disables window integration with the desktop

[LamprosPitsillos]

Did you try: https://docs.waydro.id/usage/waydroid-prop-options

• waydroid prop set persist.waydroid.multi_windows true/false (bool)
  Enables/Disables window integration with the desktop

I just did , it yielded random results . What i mean is that the window of the application is re-sizable but not the operating system behind it. Leading to the window staying , for the most part the same size, if not stretched.
If i click on the maximize for the small window of the app i get what was supposed to be what i wanted, but sadly not. The window instead stretches and deforms the image because the resolution is not changing just the dimensions in which the window is rendered ( i think..) , leading to a distorted image ( and input since the coordinates now now don't match)

[TriMoon]

The Resolution of your display is controlled by your host operating system, not waydroid...

[LamprosPitsillos]

The Resolution of your display is controlled by your host operating system, not waydroid...

By saying operating system i mean the waydroid virtualization layer , the android operating system.
And by resolution i mean the resolution known to waydroid, the same resolution set by persist.waydroid.height/width

So again, what i was talking about in simple terms is that , if my window (containing waydroid) is W width and H height , waydroid is still operating at the resolutions set by props

[TriMoon]

I think in this case you need to adjust the DPI of your android using wm density 🤔
You need to use that command inside an adb session or maybe the waydroid command also supports it no idea...

Links i used to do the research for this:

• https://www.technipages.com/android-how-to-change-display-dpi/
• https://developer.android.com/training/multiscreen/screendensities
• And more via: https://duckduckgo.com/?t=ffab&q=android+DPI&ia=web

[LamprosPitsillos]

I think in this case you need to adjust the DPI of your android using wm density 🤔 You need to use that command inside an adb session or maybe the waydroid command also supports it no idea...

Links i used to do the research for this:

• https://www.technipages.com/android-how-to-change-display-dpi/
• https://developer.android.com/training/multiscreen/screendensities
• And more via: https://duckduckgo.com/?t=ffab&q=android+DPI&ia=web

Thank you for your time but DPI is for display density. Even for a really small DPI , the Android OS will still believe that its resolution is Width X Height and will try and display its contents accordingly

[TriMoon]

Yes it will indeed but the window manager of the host that is finally responsible of displaying the pixels from Android, will scale/transform them to it's own's final-screen's DPI.
So you might want to try and test anyhow, being it lower or higher as your normal desktop's DPI 😉

1. Program A says i want to display 1(one) pixel.
   (The program running inside Android)
2. Program B says to display 1(one) pixel from A on this screen with y DPI, i need to display pA*y pixels.
   (The Android system running inside the host
3. Program C says to display 1(one) pixel from B on this screen with z DPI, i need to display pB*z pixels.
   (The window manager running on your host

Obviously when y and z are same, like under normal circumstances, it is all 1:1.

[I-Want-ToBelieve]

Since the window displaying waydroid seems to be different from other windows using qt or gtk, it does not have client window decoration or server window decoration. I had to nest it into another wayland compositor named cage. This allows it to indirectly possess kwin's server-side window decoration.

The problem now is the adaptive resolution. I can adjust the window size of the cage, but the resolution of waydroid does not respond to external changes, showing some unused black blocks

Now there is an indirect solution which is to run waydroid in the background and then use scrcpy to get the display, the only downside might be the lag and not as sharp as waydroid's display

[I-Want-ToBelieve]

I checked some information about Android resolution modification.

adb shell wm size 650x1200

Based on the information obtained so far, the existing interfaces have many limitations.

To achieve the expected Dynamic resolution, it may be necessary to modify the Android source code and expose the corresponding upper-layer API.

[LamprosPitsillos]

To achieve the expected Dynamic resolution, it may be necessary to modify the Android source code and expose the corresponding upper-layer API.

So it's possible, if you can ,please link the resources you found, thanks

[AleksanderBobinski]

Before we delve deeper into Android source code are there any docs on how Waydroid displays applications?

[I-Want-ToBelieve]

Take a look at this Dynamic resizing based on window size has been implemented in Android Virtual Devices (AVDs). There must be some kind of adaptive resolution API in Android to support this behavior

https://stackoverflow.com/a/59568877

[I-Want-ToBelieve]

You can use the adb shell wm size command to modify the resolution, but the Override size can only be up to twice the Physical size.
If you can lift this restriction, or find an API that can change Physical size instead of the Override size, you should be able to achieve dynamic resolution.

~ took 6m51s 
❯ adb shell wm size 
Physical size: 650x1200
Override size: 1300x2400

[I-Want-ToBelieve]

Android runs in lxc, and waydroid mounts /run/user/1000/wayland-0 and /run/user/1000/pulse/native to lxc. I don’t know how Android communicates with wayland in lxc.

❯ cat /var/lib/waydroid/lxc/waydroid/config_session
lxc.mount.entry = tmpfs /run/user/1000 none create=dir 0 0
lxc.mount.entry = /run/user/1000/wayland-0 run/user/1000/wayland-0 none rbind,create=file 0 0
lxc.mount.entry = /run/user/1000/pulse/native run/user/1000/pulse/native none rbind,create=file 0 0
lxc.mount.entry = /home/i.want.to.believe/.local/share/waydroid/data data none rbind 0 0

[I-Want-ToBelieve]

[I-Want-ToBelieve]

Check this out https://www.collabora.com/news-and-blog/blog/2019/04/01/running-android-next-to-wayland/

He said he made a SPURV HWComposer

SPURV HWComposer integrates Android windows into Wayland. It does so by implementing a HWC-to-Wayland bridge.

HWC is the Android API for implementing display & buffer management, and what it essentially does in interpret all of the different display buffers that Android applications produce, and organizes them into one cohesive Desktop.

This protocol is conceptually not unlike the Wayland protocol, which allows for the HWC to be translated into Wayland. This is essentially what the SPURV HWComposer does.

Additionally it deals with input, like touch screen events and passes them along from Wayland to Android, this however is unrelated to the HWC API.

[I-Want-ToBelieve]

Not sure if there is such a bridge in lxc. If it does not have a bridge, how is it displayed?

[I-Want-ToBelieve]

WayDroid renders the graphical buffer in LXC with direct Wayland support

[I-Want-ToBelieve]

https://www.reddit.com/r/linux/comments/36nlbo/discussionwhy_did_developers_not_go_with_the/

SurfaceFlinger in Android just like Wayland compositor in GNU/Linux

https://stackoverflow.com/a/5699511

SurfaceFlinger is not what draws your window. It allocates a frame buffer for your window, which the framework running in your application draws directly to without interacting with SurfaceFlinger. The only interaction SurfaceFlinger is involved with when you draw your window is to composite the final new frame buffer to the screen once you are done drawing a frame.

https://stackoverflow.com/a/4246174

[I-Want-ToBelieve]

The next step should be to see how WayDroid gets the graphics buffer from LineageOS and how to render the graphics buffer in the wayland compositor.

https://docs.waydro.id/development/compile-waydroid-lineage-os-based-images

[I-Want-ToBelieve]

I spent some time configuring the development environment in NixOS and added a 2T SSD.

The Android source code and the intermediate files generated by compiling it took up a lot of disk space.

Follow the steps in the WayDroid documentation to execute the following commands

wget -O - https://raw.githubusercontent.com/waydroid/android_vendor_waydroid/lineage-18.1/manifest_scripts/generate-manifest.sh | bash

This script downloads three xmls, one of which indicates that Waydroid has replaced libdrm mesa3d minigbm these three graphics-related projects

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <!-- Remove replaced Projects -->
  <remove-project name="platform/external/libdrm" />
  <remove-project name="platform/external/mesa3d" />
  <remove-project name="platform/external/minigbm" />
  <remove-project name="LineageOS/android_packages_apps_SetupWizard" />
  <remove-project name="device/google/cuttlefish" />
  <remove-project name="device/google/cuttlefish_kernel" />
  <remove-project name="platform/prebuilts/vndk/v29" />
</manifest>