[Question] getprop in a confined app?

pparent

Hi,

In order to adapt properly the scaling of my app I would need to do

/usr/bin/getprop ro.sf.lcd_density

The problem is that if I do that inside a confined app I get

aa-exec[6536]: ./launcher.sh: 12: /usr/bin/getprop: Permission denied

But if I copy the binary /usr/bin/getprop inside my app install repo in /opt/click.ubuntu.com/ and call it then it works well. The thing is I want to make something clean, and not dumping a binary from the phone inside my app, not even knowing if it will work for every phone.

Is there a way to do without copying the getprop binary in my app install dir? Otherwise is there a way to download the getprop binary from official ubports build sources? Where does this binary come from?

Thank's a lot in advance!

lduboeuf

@pparent
I doubt a confined app can access Android properties.
For the "where does it came from" :
https://gitlab.com/ubports/development/core/packaging/libhybris/-/blob/ubports/latest/debian/control?ref_type=heads#L153

pparent

@lduboeuf said in [Question] getprop in a confined app?:

I doubt a confined app can access Android properties.

I can garanty you that if it embeeds a local copy of /usr/bin/getprop then it can.

pparent

@lduboeuf said in [Question] getprop in a confined app?:

For the "where does it came from" :
https://gitlab.com/ubports/development/core/packaging/libhybris/-/blob/ubports/latest/debian/control?ref_type=heads#L153

Thank's but it there a way to download the compiled version in a similar fashion that it would be doable with lauanchpad in official Canonical Ubuntu ?

pparent

This is outdated:

https://launchpad.net/ubuntu/xenial/+package/libhybris-utils

pparent

said in [Question] getprop in a confined app?:

libhybris-utils

Ok I've found

apt download libhybris-utils:arm64

Inside the clickable containre allows to download the deb package, then you can extract from it the getprop binary.

kugiigi

Can't you get the density somewhere else? For example in QML, you use Screen.

pparent

@kugiigi

Well I've tried with density from qt, but it does not seem to give coherent results across devices.

gpatel-fr

@pparent said in [Question] getprop in a confined app?:

coherent results !

well, concerning Fairphone specs, not sure if coherence is an appropriate word. For example, on the Fairphone site and so everywhere on the web, you can read that FP5 screen is 6.46 inches; that is, about 16.4 cm unless they have special dutch inches.
I have a Fairphone 5 and it is no more than 16 cm in total, including the somewhat 10mm of margins in the height direction, so real meaningful screen height is more about 15cm, that is, what you could imply from the mentioned density on third party sites, so 5.88 inches (2700 / 459 = 5.88). BTW getprop returns 480 dpi on my FP5.
It's difficult to square up all these numbers and I wonder if the FP4 is any better.

pparent

@gpatel-fr

Here are the datas I have for vollaphone 22 and vollaphone x23

                          Official PPI    Qt sensity      getprop density
    Vollaphone  22        410	            252	            480
    Vollaphone X23        282	            216	            320

Getprop seems always official value rounded up to the closest possible value for android (that seem to be only a handfull of values), but seem quite coherent in proportion, contrary to qt density.

gpatel-fr

@pparent

Sorry for the delay, it has taken some time for running a basic QT program on UT without any prior experience.

yes you are right about Android rounding values, however it's not possible that QT takes values from Android since for QT it runs on a standard Linux system.

about the 'bad' values in QScreen, I have found that the 'name' property is 'XWAYLAND0', so QT is connecting to the X server part of Mir to get at the screen properties. I have found this comment in QT sources (qtbase/src/3rdparty/wayland/protocols/xdg-output/xdg-output-unstable-v1.xml)

   <event name="logical_size">
      <description summary="size of the output in the global compositor space">
        The logical_size event describes the size of the output in the 
        global compositor space.
    
        Most regular Wayland clients should not pay attention to the
        logical size and would rather rely on xdg_shell interfaces.
  
        Some clients such as Xwayland, however, need this to configure
        their surfaces in the global compositor space as the compositor
        may apply a different scale from what is advertised by the output
        scaling property (to achieve fractional scaling, for example).

for sure I don't understand the implications well enough to qualify this result as an 'Ubuntu touch bug', but some sort of rescaling in the Lomiri touch code could explain that the physical size of my FP5 is all over the place according to QScreen (21.4cm instead of 16cm)

pparent

@gpatel-fr

Well anyway I think the best thing to do would be that every port register the real DPI value of their screen, and then the value is accessible to the app via an environment variable. It would allow non-Qt app to scale correctly as easily as possible.