Hi there

hello, Kai!

(sorry if there was a delay from when you arrived -- I was distracted)

I have a couple of questions about scoped storage

how can I help you today?

oboy

Like when I target API Level 30 but I run on Android 9, does anything about scoped storage apply?

no

scoped storage started with Android 10

Or will there be some kind of emulation when using the new apis

what new APIs are you referring to?

LIke the call to get the external storage volume

The new MediaStore collections

And so on

I am rather confused about scoped storage, as you might get ;-)

if the method is new to API Level 29, you can only use them on Android 10 and higher

and so you do something else on the older devices

so, for example, you might use MediaStore on Android 10+ where you might use Environment.getExternalStoragePublicDirectory() on older devices

So effectively I might have to do some kind of if (apiLevel < 29) ... switch?

yes

That feels so... old.

you mean, compared to having ...Compat classes handle that?

Like something you had to do in times of kitkat and that you shouldn't do anymore nowadays

Yes.

I do not know if they plan on a Jetpack library to try to hide the differences or not

since the differences are substantial, my guess is that they will not

So there is no "one size fits all" solution this time?

...Compat strategies tend to work for either minor changes or where the library can offer a backport

it depends a *lot* on exactly what you are doing and where you want to do it

If I only knew... I am about to find that out.

bear in mind that android:requestLegacyExternalStorage="true" on <application> works for Android 10, and will do so indefinitely

Or in the process, rather.

and it also works on Android 11 until you need targetSdkVersion 30 next year sometime

Ok. I don't think we need that though. "getExternalFilesDir()" should continue working as always and we use that for a lot of storing

plus, Android 11's "raw paths" means that reading external storage works mostly as it did back on Android 9.0

yes, getExternalFilesDir() is stable

But you have to opt into "raw paths" with some kind of special permission

Which I would like to not do if possible.

just READ_EXTERNAL_STORAGE

Isn't "raw paths" connected to READ_EXTERNAL_STORAGE?

yes

(at least, for read operations)

*write* operations in arbitrary locations are a bigger problem

I think we only need to write within our own storage.

in that case, you're probably not going to get hit much by scoped storage effects

How would I write to an SD card?

with difficulty

Currently the user can select if he wants to store the app files on an sd card and that should continue to work.

By "app files" I mean files that the app will download from a server.

getExternalFilesDirs() (note the plural) should still work

where the second and subsequent locations returned by that method are on removable storage

and you can read and write those without permissions

if you need to write to arbitrary locations on removable storage, ACTION_CREATE_DOCUMENT is probably your best option

Ok, then nothing will change in that regard, hopefully.

Another thing I am confused about is if I need to change everything to URIs or if I can still do something like File(getExternalFilesDir() + "my_name" + fileName);

I'm not a fan of + for assembling paths, but for filesystem locations that you can work with, File() is fine

How would you assemble the file path?

Java or Kotlin?

Java

the simplest I'd do is new File(getExternalFilesDir(), "my_name/" + fileName);

you don't know whether getExternalFilesDir() will come back with a trailing / or not

(BTW, I'm assuming my_name was a directory name)

Yes.

How would I test if my app supports scoped storage if I have no device with Android >= 10?

And the emulator doesn't work for me.

then you will need to buy a device, I guess

used on eBay, cheap models on Amazon, etc.

I guess my company will have to do that.

I shall request a Pixel 4a

that's a reasonable choice: not too expensive, and likely to get upgrades for a couple of years

Exactly

Will the "Documents" location not gonna be used anymore? I think it's not part of the MediaStore collections and there seems to nothing in the API to write to it, short of using "raw paths" and such.

Ah, I even read that X)

I don't know whether Google is backing away from Documents, or if it was an oversight, or what

Huh. An Oversight would be something.

the fact that they didn't add it in Android 11 suggests that it wasn't an oversight

so, probably they're just not emphasizing that location anymore

it will be interesting if devices that ship with Android 11 have that directory at the outset

I used it heavily personally, for PDFs, word files and such.

Wouldn't know where else to put those kind of file.s

And Downloads is for Downloads, not for things I want to keep. So not having Documents anymore is a bit of a strange thing.

agreed

Is it safe to keep using File() internal to our app or is it a good idea to move everything to uris?

you asked that earlier :-)

if you can work with the filesystem location, File() is fine

Kinda, I am still confused though by an article they wrote with "Viber" where they mention changing to some sort of internal ContentProvider.

I don't know what that would buy you, other than unnecessary complexity

Ok

pffft

that is pointless on two levels

:D

first, I am skeptical that standardizing on a Uri is necessary

second, even if it is... file: is a valid Uri scheme

so running everything through a FileProvider is really unnecessary

Ok

So seems like there isn't too much change needed for our app :)

But I say that now. Let's see what happens when I try and use it on a device with Android 11.

And have all kind of things break on me.

I agree that storage is a lot more complicated than it used to be

And it's a bit complicated in our app to begin with ;-)

Now I have to find all the places where we use storage, try to see if there is any change needed and implement it if necessary.

hopefully, it's a relatively short list of places

Not too many. The hard part is finding them all and not missing one.

Or rather that is what I am a bit afraid about.

Ah well. The live of a legacy Android app dev ;-)

life

in Android Studio, you can do "Find Uses" for the File() constructor

by default, it will scan your libraries as well, but it still might be useful

sorry, "Find Usages"

(which is a really awkward name, now that I think about it...)

What would you call it?

"Find Uses", apparently :-)

I guess that is like "utilize"

"use" would be too simple

"Usages" just seems contorted

So everyone uses "utilize" nowadays.

well, you used "uses" rather than "utilizes" :-)

Isn't a "usage" diffeent from a "use"?

I hate "utilize"

If it's used where you would use "use" normally.

probably, but I can't think of anywhere else where I see "usage" in a plural form

Ah well

I hope I know everything I need about Scoped Storage now X)

OK, that's all for today's chat

next one is Tuesday at 7:30pm US Eastern

Have a good one

And thanks for the answers

you too!

you're welcome!