hello EGHDK

how can I help you today?

Okay, so I was really looking into something like MODE_WORLD_WRITEABLE yesterday, but then I saw it was depracted.

Maybe I can tell you what my end goal is... and you can advise?

I can try

That's all I ask =)

Okay, well my first question is that when I try to use MODE_WORLD_WRITEABLE it says that "This may cause some security holes..." something along those lines. Could you explain that to me? If you set something to WORLD_WRITEABLE why would that be bad.

because any app can write to that file (or directory, if you are using this on a directory)

So if I'm writing a temp file there... and that's the only reason I needed it (because I'm saving from the camera) that could still be bad?

assuming that this is based on your SO question, you are creating a world-writeable directory

Yeah, so I guess an application can be made to constantly write something to that file and overwrite my file?

I'm not even sure if that works, let alone in your scenario

though I am going to guess that what MODE_WORLD_WRITEABLE on getDir() does is set the Linux filesystem execute bit

which would mean that any process could list files in the directory, create files in the directory, and delete files from the directory

however, if the other app writes a file there, AFAIK it will wind up being owned by the other app from a permission standpoint, in which case you couldn't use the file yourself (no read or write permissions)

So... it doesn't really make it world_writeable. It also makes it world readable basically..?

do you have any Linux experience?

If I understand what you saying... world_writeable doesn't really get followed.

Yes actually!

Android is based on Linux, and Android filesystems are Linux filesystems

Yeah, in the emulator file explorer I can see that.

in a Linux filesystem, you have r/w/x bits for user, group, and world

so you see files with, say, rwxrwx---, meaning the user and group that own the file have full rights, and world does not

Yeah

my guess is that MODE_WORLD_WRITEABLE, on a directory, sets rwx for world

however, that only affects the directory itself

instead of -w-?

Oh!

I am not aware that Android uses ACLs, though in principle it could

ACL?

never mind

lol

so, with rwx on a directory, you can list the files in the directory, create new files in the directory, and delete files from the directory

however, the permission bits on the *files* in that directory are independent of the permission bits on the directory itself

Okay, so really quick because I did a lot of intro to linux stuff. So who is the user in android, and who is the group?

each app is installed as its own user ID, by default

and, AFAIK, group IDs are also per-app

Yeah, each app is a different user in Android I believe

so the camera app runs as a different Linux account than does your app

I remember reading that somewhere

Got it

but, with a rwx directory, the camera app can list, create, and delete files in that directory

but any file that it creates *should* be owned by the camera app, not you

Cool. Okay,so back to my original question.

so, unless Android does something funky, or the camera app does something funky, where "funky" = make a photo MODE_WORLD_READABLE, you wouldn't be able to use the photo anyway

Gotcha.

So all I want is to take a High quality image, taken by the camera saved into a directory. After that, I would like to read it into memory, and then delete the image in the directory. So that the image doesn't show up anywhere on memory for too long. How do you recomend I do this?

um, what's the point of taking the picture, then?

I just want to use the picture in the app and no where else.

you don't really even want to use it in your app, because you're deleting the file, and your app can go away whenever it is not in the foreground

which means the user takes the picture, and the picture goes "poof"

After I send my file, I erase it.

"send"?

So you mean if my activity goes into a paused state I can lose it?

sure

Yeah, I'm sending it to my server.

This app is just for my use. So I'm not putting it on the play store. That's why I have specific needs I guess.

any time your app is not in the foreground, your process is at risk of being terminated to free up memory for other apps

Gotcha.

now, back to what you're doing

the simplest thing is to have the camera take the picture, passing it a path to external storage

at least once upon a time, you could put an empty .nomedia file in a directory, and that would preclude that directory's contents from being indexed by MediaStore

if that still works, you could put a .nomedia file in getExternalFilesDir(null), and have the camera app store photos there

but I'd leave the photos there until you are *sure* that you are done with them

versus reading them into RAM, deleting the files, and praying

Gotcha.

Okay, can you explain to me getExternalFilesDir() because it seems like some phones default to different places?

getExternalFilesDir() -- a method on Context, and so therefore available to you in Activity or Service -- returns a directory that is unique for your app on external storage

if you were taking photos "for realz", that the user expected to keep, you'd do something different

but, in this case, the photos are particular to your app, in which case getExternalFilesDir() is more appropriate, as it doesn't clutter up the rest of external storage

"directory unique to my app" or directory unique to my phone. Wouldn't getExternalFilesDir return the same result in every app.

no

!

How is that?

you are confusing the getExternalFilesDir() method on Context with getExternalStorageDirectory() on Environment

Oh. So which one would be more appropriate in my situation from your point of view?

getExternalFilesDir()

quoting the documentation for getExternalStorageDirectory():

"Applications should not directly use this top-level directory, in order to avoid polluting the user's root namespace. Any files that are private to the application should be placed in a directory returned by Context.getExternalFilesDir, which the system will take care of deleting if the application is uninstalled. Other shared files should be placed in one of the directories returned by getExternalStoragePublicDirectory(String)."

Okay, and so that would give me what path exactly? data/data/com.myapp?

um, I think it will be Android/data/com.myapp, off of the root of external storage

at least for the primary user

on tablets with multiple users, the story gets more complicated

Okay, I think I have everything now. Why is always getting a directory to my app or the root of my storage always say "getExternal"... isn't it Internal memory? My phone (Galaxy Nexus) doesn't support micro sd

quoting the documentation for getExternalStorageDirectory():

"Note: don't be confused by the word "external" here. This directory can better be thought as media/shared storage. It is a filesystem that can hold a relatively large amount of data and that is shared across all applications (does not enforce permissions). Traditionally this is an SD card, but it may also be implemented as built-in storage in a device that is distinct from the protected internal storage and can be mounted as a filesystem on a computer."

and the "Traditional this is an SD card" has been out of date for a year or two

actually, pretty much out of date for all Android 3.0+ devices

internal = not directly accessible to most users

external = have USB cable, will travel

Okay, so getExternal will for the most part mean built in storage.

Like 16GB nexus 7 that doesn't accept micro sd

It has 16GB in ExternalStorageDirectory

roughly - because of OS and other app data

So basically, I don't have to be worried about using getExternalFilesDir().

since Android 3.0, internal and external storage usually reside on the same Linux partition

getExternalFilesDir() on Android 3.0 is all but guaranteed to point to a usable directory

(make that 3.0+)

How would I check for that though? What would happen if it was "unusable"

you are welcome to call getExternalStorageState() on Environment: https://developer.android.com/reference/android...

(or http://goo.gl/ukDItO since that link didn't work)

on Android 1.x/2.x, there were two main problems with external storage

1. they tended to be micro SD cards, which therefore might have been ejected

2. courtesy of the rules of USB Mass Storage Mode, if another computer had mounted the phone's external storage as a drive or volume, the phone couldn't access external storage at the same time

Gotcha. Okay Last question of today. I'm always so confused over how android is so "open" and yet it takes forever to get updates from a carrier AND something like a rom from cyanogen mod has to be made specifically for a specific model of a phone. Doesn't that defeat the purpose of being so open?

open is an adjective

(or perhaps a gerund...)

anyway

Android is open source

however, not everything else is

notably, drivers for GSM, CDMA, GSM, and related radios tend to be closed-source

That's... stupid. (For a lack of better words)

plus, because it is open source, device manufacturers tinker with it

you're welcome to buy out all the radio chipset manufacturers and change their policies

this is likely to be expensive

I should start to save.

that's a wrap for today's chat

Alright Thanks

next chat isn't until Tuesday August 6, at 4pm Eastern

See ya sooner than later.

have a pleasant day!