Can Android Instant Apps access the file system? - android

Can a Google Play (android) Instant App access the filesystem of the phone it's running on (assuming the user gives permission). Are they capable of running CRUD operations as well as downloading, uploading and making modifications such as unzipping folders?

Related

Is there a location to keep app files after app uninstallation in Android Q, except Media collections or Downloads

According to https://developer.android.com/preview/privacy/scoped-storage, an app with sandboxed view can just access files located in app-specific directory or Media collections or Downloads in Android Q.
I'm just confused if I want to keep app files after app being uninstalled where can I write my files, except Media or Downloads directory.
Writing files in inappropriate location is bad, so this question is just to find if it's possible when app works with scoped storage.
I want to keep app files after app being uninstalled where can I write my files
Use the Storage Access Framework (e.g., ACTION_CREATE_DOCUMENT or ACTION_OPEN_DOCUMENT_TREE). This will allow the user to choose where your app writes the user's data on the device, and most locations that the user might pick will remain around after your app is uninstalled.

Google Drive SDK for Android, Drive.SCOPE_FILE, and Multiple Devices

I'm using the Google Drive SDK for Android, with the Drive.SCOPE_FILE scope. I install the app on multiple devices.
The app saves files onto drive. I can add files from either device, and the files show up in the web interface for drive, exactly like you'd expect.
Each device can only access the files it created, and not the files created by the same app on another device. (And vice versa, for the files created on the second device, and not seen on the first.)
I know the File Scope only allows access to files created by the app (and files specifically chosen via the file chooser), but I had assumed that the app would be able to load files created by the app, even when installed on multiple devices.
Is this the expected behavior?
The same user/app pair should have access to the same files on any device. There may be some propagation delay after opening an existing file with the app.

Authenticating .apk downloads

Am trying to deploy an apk file from a webserver (IIS6), I have the mime type configured correctly and all is working when the folder allows anonymous access. However, I would like to force a challenge/response for the download of the .apk. Even with clear text authentication set on the folder and/or .apk file, no mobile device is being challenged for access to the file and because of this fails to d/l the file. When trying to access the file from a desktop browser I get challenged as expected. Is this capability not supported in the Android OS? Have been trying this with different 2.x Android versions but not ICS as of yet on both tablets and phones.
M

Android: Gaining access to other app files through app on non rooted phone

Does anyone know if it is possible to access the data files from another app on your app? Really just copying a directory plus contents. This is for a backup system. I am trying to create a backup system that works decently on non rooted phones. I currently can only copy data from my own app. I can't navigate further up the file system. Getting a permission denied.
No. AFAIK, Not possible on non-rooted phones. Android restricts access to only your app specific content.

App to SD functionality on Android

I'm getting more and more requests about being able to use an App to SD feature that must be part of Android 2.2, but I really have no experience with it. I also don't know where to find any documentation regarding how to make my apps compatible with this feature. People have told me my apps cannot be moved to the SD card.
My mind is also telling me that this is a really bad idea for paid apps that don't have license protection of any kind.
Has anyone had any experience with this, know of any documentation, or have any tips regarding what would stop an app from being compatible with this feature?
Note: I do not use copy protection on my apps.
You can allow your app to be installed to the SD card using the android:installLocation manifest attribute. This can be set to preferExternal or auto, depending on whether you would like to recommend that it be installed on the SD card, or simply allow it. By default, applications cannot be installed to the SD card for backwards-compatibility reasons, so you must opt-in to this feature if you want your users to be able to use it.
From the documentation:
When your application is installed on the external storage:
There is no effect on the application performance so long as the external storage is mounted on the device.
The .apk file is saved on the external storage, but all private user data, databases, optimized .dex files, and extracted native code are saved on the internal device memory.
The unique container in which your application is stored is encrypted with a randomly generated key that can be decrypted only by the device that originally installed it. Thus, an application installed on an SD card works for only one device.
The user can move your application to the internal storage through the system settings.
Thus, you shouldn't worry about license protection too much; there is encryption built into the feature. You also generally shouldn't worry about license protection because any form of copy protection or DRM tends to be more harmful to honest users than to pirates. As long as someone is able to use your app, someone will be able to pirate it; it is well nigh impossible to create an unbreakable DRM scheme. If your app is already in internal storage, it's likely already pirated. Most users are honest, however, and will buy the app from the Market, so you won't really gain much from stopping piracy (most people who download pirated apps are those who don't have access to paid apps in the Market; it's still not available in many countries).
Anyhow, the upshot is that this should be about as secure as your app already is, and just allows users more flexibility in where to store their app. It's not enabled by default in case of bugs that cause applications that aren't expecting it to break, but it should be perfectly safe to enable.
Here you go.
And documented here.
The Android platform now allows
applications to request installation
onto the device's external storage
media (such as the SD card), as an
alternative to installation onto the
device's internal memory.
Application developers can express the
preferred installation location for
their applications by means of a new
attribute of in the
manifest file,
android:installLocation. The attribute
supports three values: "internalOnly",
"preferExternal", and"auto". At
install time, the system checks the
value of android:installLocation and
installs the application .apk
according to the preferred location,
if possible. If the application has
requested external installation, the
system installs it into a private,
encrypted partition in the external
media. Once an application .apk is
installed externally, the system lets
the user change the storage location
of the .apk and move it onto the
device's internal memory if needed
(and vice versa), through Manage
Applications in the user settings.
By default, the system installs all
applications onto the device's
internal memory, except for those that
explicitly request external
installation. This means that the
system will always install legacy
applications onto internal memory,
since they do not have access to
theandroid:installLocation attribute.
However, it is possible to configure
and compile a legacy application such
that it is installed internally on
older versions of the platform and
externally on Android 2.2 and later
platforms, if necessary.
Note that requesting installation onto
the device's external media is not
suitable for all applications,
particularly because the external
media may be removable and
unmounting/remounting may disrupt the
user experience and system settings.
For more information about setting a
preferred install location for your
application, including a discussion of
what types of applications should and
should not request external
installation, please read the App
Install Location document.Install Location document.

Categories

Resources