I want to write a file classificator - something like the linux file command does. The main feature should be to detect the target OS (especially Android). It has to work on compiled/native files (ELF file format). For executables I currently check the interpreter (/system/bin/linker) to guess it is android. For shared objects I do not have such a criteria yet. I there a way to do that?
Related
I am wondering if it is possible to update qml android application remotely by changing qml file. To do this :
Qml should be read from the filesystem of the device dynamically instead embedding into the apk.
Is it possible?
Yes it is possible, you will only embed a small loader, possibly including an updater into the APK, which can load a QML file from the device filesystem.
On startup you can check for a new version, if available download and save it and only then load the QML file.
Note that for any non-trivial application you will most likely need to define external files as an external module so you can have your custom external types resolve properly.
I have android application which uses a lot of c++ native code. Application needs to work with files located on sdcard(read, create, append). But Kitkat+ denied writing to sdcard for 3rd party applications. Android 5 introduced new API which allows that again.
How to use the new SD card access API presented for Android 5.0 (Lollipop)?
All examples and documentation what I found are mostly for Java side. Examples for native code don't exist or are very unclear. So I want ask few questions.
The link above contains valuable example how to get DocumentFile which can return ParcelFileDescriptor. From this object I am able to receive native file descriptor - ParcelFileDescriptor.getFd(). It's integer which I am sending to c++ code through jni.
In c++ I am opening file with fdopen(fd).
My questions are :
Is fdopen function correct way how to open the file with new api? Or the DocumentFile already opens the file and I should only use fd in further operations.
It's enough to close the file descriptor inside native code with fclose? or should I close it on java side with ParcelFileDescriptor.detachFd(). Or both.
Thank you
EDIT : I getFD and detachFD works. But I never found answer how to correctly replace ftruncate, which needs write access too, and I did not found ftruncate version which takes file descriptor like a input
1) yes, use file descriptors and fdopen
2)
Open the ParcelFileDescriptor.
getFd().
Pass the Fd to native code.
Close the ParcelFileDescriptor. (this is closing your java reference)
Fd is just an int representing a linux id for a file. In native:
Fdopen
Do stuff
Fclose (note this is closing your native file pointer)
The two closes are doing different things.
Note: You still need the SAF permission for the file or a higher root.
Try Below Links:
Android - writing/saving files from native code only:
Android - writing/saving files from native code only
Android NDK Write File:
Android NDK Write File
File Operations in Android NDK:
File Operations in Android NDK
I'm porting a C++ Linux application to Android using NDK and testing using the emulator. The application tries to create an /etc/myApp directory and fails because the component /etc does not have the necessary write file system permissions required to create.
Should my application be able to create such a directory? I used adb to inspect and try to make the directory from the shell and it fails too:
mkdir failed for myApp, Read-only file system
Does the file system being read only in adb mean it is also read-only for my application?
Can my application expect to create this directory and if not, is there another location that is more appropriate?
No, you should not be able to do that. Android apps are not permitted to write to system directories.
You should probably create this directory within your app's private storage area. Generally it is best to discover the path of that from Java (don't hardcode it) and then pass it through to the native side.
Depending on your needs for the file, the ExternalStorage might also be an option, especially during development where you might need to easily modify it manually - though keep in mind that others things will be able to change it there, too. Again, you should determine the path on your particular device in Java and then pass that through to the native code.
I am currently porting a library from Linux to Android and I am having some trouble.
The lib has an extension system : it will look for all the files with a particular extension in the folder /usr/local/lib/{thelibname}/extensions/, check if they are dynamic libraries, and load them and call a handler if it is the case.
However, I don't think it is possible to tinker with the base filesystem folders in Android.
I looked into assets but they did not convince me, it looks like they are more intended for images, audio, etc...
Is there another way to embed some files in an .apk and load them afterwards by enumerating a DIR* and calling dlopen ?
The other possibility would be to put the extensions with the app data but I don't know if there is a standard path for this that I could hardcode in the lib, is there? And I don't how to put some stuff in the data at the installation of the apk ? (I use QtCreator for the generation of the APK)
Okay, I found another question which helped me to solve my problem :
How to integrate native runtime library with dlopen on NDK?
You can easily load extension libraries from anywhere in the file system, including shared folders like /sdcard/ and her children. Any app (and native libraries therein) can gain full read access to /sdcard/ with READ_EXTERNAL_STORAGE permission.
This way you can establish a folder where the extensions will be updated not necessarily by a single APK (note the changes for WRITE_EXTERNAL_STORAGE in KitKat).
If you want to deploy all extension libraries as part of the APK, it's easiest to put them in the standard folder that is used to pack the APKs (for ADT, it's ${project_root}/libs/armeabi) and then they will be automagically installed in /data/app-lib/${app_package}. This approach allows to prepare an APK for multiple architectures, preparing appropriate files in ${project_root}/libs/x86, etc.
Note that all libraries must have lib prefix and .so suffix, so e.g. mylib.so or libcrypto.so.6 will not work, even though theoretically such libraries can be loaded by dlopen().
Your app has read access to the /data/app-lib/${app_package} directory, so you can scan it either from C code, or from Java. In Java, its easy to resolve the ${app_package} even if you don't want to hardcode this name. Simply call getApplicationContext().getPackageName().
In C, you can use /proc/${pid} to find the full path to your shared library, and this way you will also know the path to the extensions.
hello guys i need small help in understanding file system of android
Now in windows for example we create files using paths like "c:/mytextfile.txt" or "c:/folder/mytextfile.txt".Now how can i access files and folders in android i mean whats the path like.
Does the phone support file browser instead of relying on third party apps??
Android does not have a native file browser, but there are numerous third-party ones (Astro comes to mind). The filesystem of Android is that of Linux; the path separator is / and the FS grows from a single root called /. So, you have your app packages under /data/apps, and so forth. Unless the phone is jailbroken ("rooted"), you won't get to see the whole filesystem - permissions get in the way. This applies to all Android applications, they are sandboxed - that is, they don't get access the whole filesystem. There are API calls to get the path to the current application's sandbox directory.