Companion and APK: How to access files on Android

OK

You are using the bennedum SQLite extension

This can work with absolute paths to database files. You use this block to specify the path to your database file:
image

I would suggest you move your database from assets to the ASD, then you can work with it from there.

So, I upload my DB and any other "external" files to Media, then I change DefaultFileScope to App (it was Asset, also if normally I set to Legacy) then I should be able to access my files. But it does not work. In practice I do not know where AI2 saves the Media files in the file system.

Path to assets in companion:
/storage/emulated/0/Android/data/edu.mit.appinventor.aicompanion3/files/assets/

Changing the DefaultFileScope has no effect on extensions.

Hello guys, I want to understand where AI2 stores the files added to Media and if it changes using Companion or apk, if Screen1.DefaultfileScope changes or not its behaviour and if the version o Android matters. The point is that many extensions work in a different way and need to know where are located some external files. Where can I find a guide to this general problem? Seems that the problem is related more to non media files, images, sounds and video do not give me problems, the problem arised with text, zip and database (sqlite) files. My end goal is to publish an app and a SQLite DB together, The DB contains configuration and setup data, we can assume its content will not change very often.

The files uploaded in the media section are the assets, which are read only, see also

This is independent on the scope or Android version

There is actually no such general problem...

And as already said in your other thread, usually you put your database into the assets and import it on first run of the app...
Taifun
PS: please do not create another thread with the same question again and again.. this is considered spam... thank you...
I will merge the 2 threads...

Ibid.

:question:

See also here:

Yes, I mean that if I upload a file in the Media and it is an image, sound or video I can access it simply writing its filename as is without anything else and works (i.e. left_arrow.png). Instead, with DB filenames it does not work. Also with text files it does not work (i.e. txt, md, csv).

I read some posts you wrote and also I seen a picture reassuming the situation, that is clear. It is not clear to me why if a DB is in the Media, and so it means it is in /storage/emulated/0/Android/data/edu.mit.appinventor.aicompanion3/files/assets/, is not found by AI2 or by the extension, seems that everything is right.

This path is useful when testing in companion, the assets folder is a special folder generated by the companion app to provide debugging access to media files. In compiled apps the path to assets/media files is different. Your sqlite extension may not be written to accept the // syntax for assets, therefore you would need to access the assets in another way, or as previous suggested, copy your assets to the ASD for ease of use.

The extension accept the path written as /storage/emulated/0/Android/data/edu.mit.appinventor.aicompanion3/files/assets/mydb.sqlite and works because it reads the tables and records already present. So, considering I did not want to modify the source code to manage test and production releases I have to find the best solution to deliver the DB inside the apk and for the application to know that the dB may be in one place or in the other. I do not know how I can delivery the DB in a different way than uploading it in the Media, is there a different option?

Do you need to edit the database, or just read from it ?

in this case I need just to read but I would prefer to have a solution that may work also to write. I am using an extension made by you that returns the assets path, does it return a different result working with companion or without? Because with companion it works perfeclty, if it returns the assets path accordingly if the app works with companion or without (I mean an apk installed on the phone) could be the simplest solution.

Try this

I made some tests and now the situation is a little bit more clear. I am able to test and debgu using Companion, the DB is located in /storage/emulated/0/Android/data/edu.mit.appinventor.aicompanion3/file/assets/mydb.sqlite This path is returned calling the methods of SQLite extension and also your tools extension. Testing the apk the results are different. Your tools extension (and another couple of similar extensions) return /storage/emulated/0/Android/data/appinventor.ai_massimomanca_es.TestSQLite/files and the SQLite1.DatabasePath returns /storage/emulated/0/android_asset
But android_asset does not exist and also I did not find any other mydb.sqlite DB anywhere else. So, where AI2 copies mydb.sqlite installing the apk? I need a good file finder tool working on Android...

The sqlite extension is out of date (not likely to be updated) and not handling the new compiled path to assets. It also cannot cope with being fed the PathToAssets blocks from Taifun's Tools extension, and crashes the app.

Because of this you should try as I suggested and copy the database to your ASD, as in my blocks above, then access it from there (which also gives you read/write)

Your alternative is to use Taifun's SQLite extension, which is up to date and full support is provided. I would recommend this course of action given your determination to access the database from assets when compiled.

(note: the File extension is also by Taifun, not me...)

1 Like

Is there really a new path to the assets for the APK?
Since when?

well it is not this! (which is embedded in the extension)

see the source code

Honestly, at the moment I am a little bit confused... I have too many different results. I am sure that someone depends by the extension(s) but someone is coming from Android 11. I think that the simpler thing from a management point of view is find a way so that uploading a DB on the Media it will work both with Companion and apk. It may be a little bit more complicated to realize but seems to me that is the way to solve and prevent any DB update problems.

Exactly, seems there is something wrong in the SQLite extension about default path management.