App is writing into the MAIN AndroidOS directory instead of /Android/data/com.fr3ts0n.ecu.gui.androbd/

[ieffuie4]

Describe the bug

Now i understand why AndrOBD ask for such a deep file access permissions and cant work without it. Its writing in the MAIN Android directory. This is really nothing a app should do. This should really be fixed. Doing so is for sure just wrong.
After i did this #271 (comment) i gave the AndrOBD really deep file access permissions. Now AndrOBD could in theory delete my whole phone, read all my pictures, access the files of every other app, and so on.
AndrOBD wants for no reason to create a directory here:
/com.fr3ts0n.ecu.gui.androbd
Not where it should be: /Android/data/com.fr3ts0n.ecu.gui.androbd/

You do not have to ask the user/AndroidOS for granting additional file access permissions when you want to write into the app-own directory: /Android/data/com.fr3ts0n.ecu.gui.androbd/
Please take a look into this Android 5.0+ app sourcecode that do NOT ask the user for any additional file access permissions: https://github.com/libre-tube/LibreTube

To Reproduce

#271 (comment)

Expected behavior

Do not ask for any file access permissions and just use the default directory /Android/data/

Important details on your environment:

• Android OS version: 14
• AndrOBD version: 2.7.0
• OBD adapter type: not related
• Connected vehicle make, type, year, engine size: not related

[serppower]

Is this fixed?

[fr3ts0n]

No, issue is still open

[ieffuie4]

There was no new test build or any code change since the report. Yes, its still there.

[porteusconf]

Wow... seems like a major security/stability issue, so i am surprised app is allowed at Play store (v2.0.0) and F-droid (v2.6.14). (Perhaps suggest you can get newer versions using f-droid vs playstore.) Anyways, I can barely read let alone write java so I doubt I can help solve. But I did grep the source code and perhaps observations below are relevant.

TL/DR The code uses deprecated variables, and likely needs to be migrated to Intents which may also solve some permissions issues (details below)...

Saw a comment below from lines 71-83 of File helper.java suggests they want to store files in <user data location>/<package name> which I hope and agree should be /Android/data/com.fr3ts0n.ecu.gui.androbd/

	/**
	 * get default path for load/store operation
	 * * path is based on configured <user data location>/<package name>
	 *
	 * @return default path for current app context
	 */
	static String getPath(Context context)
	{
		// generate file name
		return Environment.getExternalStorageDirectory()
			+ File.separator
			+ context.getPackageName();
	}

A wild guess as to why it is actually incorrectly using main AndroidOS root may be related to issues discussed at sites below...

At https://www.geeksforgeeks.org/external-storage-in-android-with-example/ it says

"getExternalStorageDirectory(): This method is not recommended. It is now absolute and it is used to access external storage in older versions, API Level less than 7."

Note that GetExternalStoragePublicDirectory and Environment.getExternalStoragePublicDirectory are also now deprecated. See https://blog.tinaciousdesign.com/migrating-from-get-external-storage-public-directory-in-android-10-and-11 where they recommend migrating to Intents, saying:

Benefits of using intents
No permissions required
User has full control over the files
No permissions required
What's great about using the intent system is that no extra permissions are required. You do not need access to read and write to storage if you are using intents.

https://stackoverflow.com/questions/73655147/android-os-environment-getexternalstoragepublicdirectory-is-deprecated-alternat

https://stackoverflow.com/questions/7597058/android-setget-environmental-variables-in-java was more about setting env , so this comment may not be relevant:

"Think about what problem you're trying to solve, and if it can be done without using environment variables. They're not a good fit in Java, and are even worse on Android.