Unfiltered
The Dan Bongino Show (Mon. – Fri. 12p-3p ET)
Check out the 10T
Essential Official Android Thread
Tony D'Amato
It's all about the inches
Will look into it, but I always wanted a pixel and just never pulled the trigger. Kinda want that 7 pro.
At the same time oneplus seems to handle android even better than Google(w/o all the extra google software), so Im tempted to check that out. Even tho I hate tryin to get cases and accessories for my OnePlus phone.
Unfiltered
The Dan Bongino Show (Mon. – Fri. 12p-3p ET)
try the 6 first, should be under 400 on offerup.
Get a feel for the software.
you don't want a high end pixel first, they tend to have too many bugs, start small
Motorola coming for the crown
I got the 6A and can attest that the speakers aren't good.
Well, actually, the speaker, not plural. it's just one.
Well, actually, the speaker, not plural. it's just one.
Sounds about right...the one plus was probably a better option...the pixel has had too many issues. Maybe everything is made right by the pixel 7 in Oct.
Tony D'Amato
It's all about the inches
Unfiltered
The Dan Bongino Show (Mon. – Fri. 12p-3p ET)
maybe you can hand it back and jump on the regular 6 in the meantime.
S21 ultra...s22 Ultra....I got the A52 but I don't use it.
Oh shyt, my b. I got the regular 6. Which only has 1 speaker. The pro only has 1 as well.
I'm thinking of getting the 7 depending on the specs and trading this one in
Why an Android file manager can't open folders under /Android
File managers aren't supposed to be able to access folders under /Android, but a loophole let them. Android 13 closes that loophole.
blog.esper.io
Android 13 makes file managers less useful by fixing a loophole
Mishaal Rahman, 2 months ago 9 min readOne of the areas where many people agree Android is superior to iOS is file management. On Android, you have the option to use the Files by Google app (preinstalled on GMS devices), the AOSP Files app, or one of many third-party file managers available on Google Play and other app repositories. If you choose to download a third-party file manager app, then all you have to do is grant a permission to start browsing the contents of your device’s external storage to your heart’s content.
Right: Using MiXplorer to browse the external storage
However, there’s one folder on external storage that’s designed to be inaccessible to every app except the AOSP Files app. Even if a file manager app obtains “all files access”, it isn’t allowed to access /Android and its subdirectories /Android/obb and Android/data.
This is not a bug but rather an intentional restriction introduced in Android 11 as part of Google’s ongoing “Scoped Storage” efforts. Fortunately, file manager devs quickly discovered a loophole that let them access those restricted directories. Unfortunately, that loophole has been closed in Android 13, limiting the ability of third-party file managers to actually do their job. In this week’s edition of Android Dessert Bites, I’ll be sharing how this loophole worked and what Google did to close it.
Thanks for signing up for The Android Edge newsletter. Every week, my Android Dessert Bites column will share the latest news about the Android platform that matters to system engineers, app developers, and power users.
The SAF loophole that file managers jumped on
Before I talk about the loophole, though, I want to explain why its closure is important to users. The /Android/data subdirectory is where many apps store files. Within this subdirectory you’ll find folders named after the package names of apps installed on your device. An app can read and write whatever files it wants in the folder matching its package name, and it doesn’t have to ask for permission to do so.The Telegram app, for example, stores its cache under /Android/data/org.telegram.messenger/cache, so if there’s a particular file you forgot to save but wanted to retrieve, you might be able to find it there. Google Podcasts stores downloaded podcasts to /Android/data/com.google.android.googlequicksearchbox/files/Podcasts/Downloads, so if you, say, downloaded a bunch of episodes of Android Bytes on your phone and wanted to transfer those to your PC, you’d need to navigate to that location to grab those files. /Android/data isn’t the only place where apps like Telegram and Google Podcasts can store files, but it offers more space to do so than internal storage and is just as convenient to access, which is why it’s frequently used.
For many years, Google Play limited the size of APK files that devs could upload to be 100MB or less. Apps that ship with a lot of high quality assets (like games) could easily exceed this limit, so Google offered the ability to create APK expansion files that can be up to 2GB in size. These files are stored in /Android/obb with the .obb extension. It’s not uncommon to see Android gamers share .obb files in order to access some games early.
Though everyone’s setup is different, most readers have probably accessed a file or folder under /Android at one point in the past. When friend of the blog (and one-time Android Bytes guest) Braden Farmer posted on Reddit about Android 11’s file manager restriction, the post attracted over 100 comments from users expressing frustration with the change. It was noted quite quickly, however, that many file managers had rolled out updates enabling access to /Android/data and /Android/obb. All the user had to do was tap “use this folder” and then “allow” when requested, and the file manager would have access to those directories.
What file managers like MiXplorer are doing is using the Storage Access Framework (SAF) to request access to a particular directory’s contents. SAF was introduced all the way back in Android 4.4, while the ability to use SAF to prompt the user to choose a directory for an app to access was added in Android 5.0. This capability, thus, is quite old, so it’s not as if Google didn’t consider that apps would try to use SAF to request access to directories that are supposed to be restricted. In fact, Google explicitly blocked SAF directory access to /Android, but this implementation had a flaw: it didn’t block SAF directory access to subdirectories under /Android. In other words, while file managers couldn’t just use SAF to ask for access to all of /Android, they could use it to ask for access to /Android/data and /Android/obb, circumventing Android’s restrictions almost entirely.
The method behind this loophole is pretty simple to find online. This StackOverflow post sums it up quite nicely, though I first stumbled upon the method after reading this issue on the Amaze File Manager’s GitHub. One of the developers behind Amaze File Manager, TranceLove, published a proof of concept app that could access restricted directories in Android 11. Based on my understanding, the way it works is that, when constructing the intent to launch SAF, apps can set the initial location of the document chooser to be /Android/data or /Android/obb. This is intended functionality of SAF, but Google seemingly didn’t consider this when implementing Android’s restrictions on those directories. Oops.
Half a year after someone reported the existence of the loophole to Google, though, an employee said the issue will be fixed in a future Android release. That “future Android release” is now here in the form of Android 13, and I can confirm the loophole is closed through my own testing and code examination. As you can see in the video below, the loophole works on Android 12L but not on Android 13:
This is because Google updated the shouldBlockFromTree method in ExternalStorageProvider that I linked to before. The updated method adds a new condition to check if the directory that’s being launched matches one of the directories that should be hidden from apps. If there’s a match, then a flag will be applied to the directory that blocks it from being selected through SAF.
Because of this change, file managers will need to find another way to access files under /Android. One solution might be to use the Shizuku library to run as shell, since the shell user still has access to /Android. Shizuku isn’t a perfect solution, though, because the service doesn’t persist across reboots and on some devices, it’s killed when the device switches between WiFi and mobile data. Plus, Shizuku itself is a bit risky to rely on, because it’s something I can see Google restricting in a future release.
While waiting for file manager devs to implement a workaround, users can access /Android through one of the officially supported ways: the AOSP Files app (if you can’t find it, this app acts as a shortcut), MTP (ie. from your PC), or ADB shell (with or without a PC). Although I haven’t tested this myself, I suspect that file managers that have already been given access to subdirectories under /Android using the SAF loophole will retain that access when upgrading to Android 13, so one option would be to set up a file manager before upgrading.
While it’s understandable that Google is closing an obvious loophole to enforce behavior introduced in an earlier platform release, I still don’t agree with disallowing even file managers from having access to /Android. As I just mentioned, users can already access all content under /Android through the preinstalled Files app on most phones or from a PC using MTP or ADB. Thus, files saved to /Android are only hidden from other apps, not the user. I understand that’s the goal, but if the user wants to grant access to a file manager app so they themselves can access content that’s not intended to be hidden from them anyway, then I think they should be able to. Google Play already audits which apps can declare the MANAGE_EXTERNAL_STORAGE permission (the permission behind “all files access”), so why can’t those apps be trusted to actually access all files as the permission implies?
I've got a Pixel and downloaded Android 13 yesterday.
I think we've reached peak Android when most (all?) of the upgrades are minor UI tweaks. How is having a larger nav bar a highlight of an upgrade
The phone does what I need to do so I'm not complaining. The one thing I wanted (ability to schedule "Extra Dim" mode) wasn't implemented unfortunately but I wasn't researching Android 13 anyways so the entire upgrade popped out of nowhere for me.
If future updates are this miniscule, moving forward I'll probably root my phone once it is no longer eligible for security updates and ride it til the wheels fall off.
I think we've reached peak Android when most (all?) of the upgrades are minor UI tweaks. How is having a larger nav bar a highlight of an upgrade
The phone does what I need to do so I'm not complaining. The one thing I wanted (ability to schedule "Extra Dim" mode) wasn't implemented unfortunately but I wasn't researching Android 13 anyways so the entire upgrade popped out of nowhere for me.
If future updates are this miniscule, moving forward I'll probably root my phone once it is no longer eligible for security updates and ride it til the wheels fall off.