S
soul-adrift

  • 4 hours ago
  • Joined Jul 12, 2024
  • A short extract:

    In the field, I've found that many applications read the ranges from /proc/self/[s]maps to determine what they can access (usually related to obfuscation techniques).

    followed by:

    It seems that banking apps running on Android are known for this sort of behavior and could run into trouble if guard pages are installed — which is something that the Android runtime might well want to do as a general hardening measure.

    but there is fairly substantial discussion following in the lwn.net comments to that article.

    Use your browser search function with keyword banking if you want to quickly grep through the comments.

  • In the below the line comments of the lwn.net article:
    [https://lwn.net/Articles/1011366/]
    there's a lot of discussion about the way Android Banking Apps behave and what they are trying to achieve.
    There's a lot to wade through and perhaps off topic but at the same time it is interesting to read how increased security measures in a future kernel might trip up banking apps.
    I thought some here might find it interesting.

  • You are not alone in your frustrations - but this is, perhaps, best a problem to be tackled at the Google Pixel/AOSP level, not GrapheneOS.

    GrapheneOS gives us the extra tools to better control the background tasks (like Google Play Services) by DISABLING apps or putting them in RESTRICTED mode. I think this gives GOS much better battery life than plain Andoid, so I feel sure you are still in the best place.

    I have upgraded to a Pixel 8 Pro from a Pixel 5. I too am very disappointed by the 8pro battery life. I reckon the Pixel 5 has about 25% better battery life despite a 20% smaller battery.

    I can't be sure, but this seems to be a chip process node issue above all else. I am disappointed that even in screen off/sleep mode the Samsung 4nm seems so poor compared to a comparable TSMC node.

    Anyway, just letting you know I share your frustrations.

    • Notmyrealname Eagle_Owl

      Notmyrealname When I copy files from my pc to my phone, the file order (by file creation and modification date) gets all messed up. I tried normal copying (Fedora nautilus) and rsync and in both cases the file order is wrong. Any idea how to stop this?

      If I understand your problem correctly, then I had a similar experience last year; found some solutions, drafted a post for this forum, lacked time to do the checks necessary before posting. Here is the draft, if you could check it solves your problem then please post something that is more helpful than my input. My view is that the problem is caused by the desktop OS, not Android/GOS.

      To summarise for other folk passing by:

      Intention
      Backup photos on Phone onto (Linux) PC with a usb-c cable.

      Problem
      In a linux graphical file manager, with the phone auto-mounted by gvfs, then a naive copy of files from the GrapheneOS Pixel phone will not preserve the original photo file's date / time attributes.

      Documentation
      Best starting point might be here: https://wiki.archlinux.org/title/Media_Transfer_Protocol

      Solutions

      • gmtp : if this works for you, then gmtp gives you a nice graphical interface -- right-click > camera > download-files will offer not to replace existing files already downloaded.

        So, this gives you a one way sync for free, which is very nice and makes this the 'easiest' GUI solution.

        There are options to keep the date/time attributes: settings > Preserve file timestamps; enable this option to have downloaded files' timestamps modified to match those as on the device.

      • go-mtpfs : setup with command line from terminal each time, but then you will get a nice mount point device in your graphical file manager or use $ cp -an to preserve file attributes.
        eg. mount pixel/profile with:
        $ go-mtpfs pixel-profile &
        and unmount with:
        $ fusermount -u /home/user/pixel-mount-points/pixel-profile

      • jmtpfs : this integrates nicely with a graphical file manager using /etc/fstab.

    • unplugmaverick Nice catch, looks slightly inconvinient

      The step to do the app.apk backup is actually very quick and convenient:

      Amaze file manager installed now. It has an App Manager with a 'backup' option which seems to extract the selected app's apks into an Amaze/APK folder.

    • unplugmaverick Little more detail here too:

      tornsail UndercoverBozo Thank you for the pointer - and I have Amaze file manager installed now. It has an App Manager with a 'backup' option which seems to extract the selected app's apks into an Amaze/APK folder.

      In this case I get four apks - the main big one ...garmin.apps.explore.apk + ...garmin.apps.explore_arm64_v8.apk + two small _en.apk + _xxhdpi.apk

      I think this is called split apks and I guess I require some sort of split apk installer. I've not yet found a way to use Amaze to do this. Just installing the largest apk doesn't give a functioning app - whether using Amaze or the default filemanager.

      • Scott I have been seeing the same message using Firefox on my computers for the past few months. Did they get sold and listed as a business recently? I think this is to do with them trying to monetize their user base and hence becoming unfriendly to anti-tracking measure, ublock-origin, VPNs etc. So my theory would be this has nothing to do with GrapheneOS.

        • unplugmaverick

          is there any trustworthy way for me to retrieve and save the .apk files of certain apps I download, in order to reinstall them again if need be?

          I think the technique in the post linking here works for both owner and secondary profiles where an app is installed:

          https://discuss.grapheneos.org/d/12070-how-to-extract-the-apk-of-a-package-installed-in-a-secondary-profile/6

          tornsail My intention was to make a copy of an older app (free but commercial=Garmin), that was no longer available from the PlayStore, and install it on a second device and avoid using an apk mirror.

          • apk-extractor (from f-droid) did NOT work for me
          • Install Amaze file manager on device A (or may be Kanade or APK Explorer & Editor will work too, but I've not tested yet)
          • Use Amaze to backup the app to external USB storage
            (there's some hokey-pokey with storage permissions, but Amaze leads you through it)
          • On this occasion, the app was 4 apks (known as a split apk I think)
            I did not find a way to install the split apks using Amaze or the default filemanager
          • On device B install APK Explorer & Editor
          • Using APK Explorer & Editor select all the split apks for the app (four in this instance) on the external USB storage and then you will find the install option

          There might be something else here of interest to some people. I read in the forum quite frequently that some GrapheneOS users don't want to use the sandboxed PlayStore and head off to the Aurora Store despite the risks. Maybe people in that situation could use a secondary device to obtain their apps/apks direct from the PlayStore and then use this app backup technique to move the app to their primary device. Catch would be no easy updates of course.