No data access on android

Android 11 cannot access Android/data folder

Breadcrumb

Tonyy1206

Member

titanreign

Senior Member

I was trying to access /data/data/ and none of the mentioned file explorers could do it. However mounting as read/write adb shell su mount -o rw,remount / allowed me full access to browse and modify. When you’re finished make sure to remount as read only adb shell su mount -o ro,remount /

Another method I found was using the terminal in 3c toolbox I could issue the same mount command from above, and then use it’s built in file browser.

Hope this helps anyone finding this thread in the future.

sailorcanfly

Member

I was trying to access /data/data/ and none of the mentioned file explorers could do it. However mounting as read/write adb shell su mount -o rw,remount / allowed me full access to browse and modify. When you’re finished make sure to remount as read only adb shell su mount -o ro,remount /

Another method I found was using the terminal in 3c toolbox I could issue the same mount command from above, and then use it’s built in file browser.
View attachment 5441013

Hope this helps anyone finding this thread in the future.

Bijendra_Pin_Sharma

New member

I’m using Galaxy M21 2021 Edition which runs on Android v11. I’m using Oxford dictionary mod version which needs offline data files to be copied into Android/data folder.

Eventually I could copy it with the help of Total Commander app. Then I can use the dictionary for free but for few hours. As soon as the night passes the offline files I had copied in ‘Android/data’ folder vanishes every time.

So this method of copying the data files through total commander app does not work more than over a night.

I am seeking help from any of the experts to solve this issue so that I can use my Mod apps and it’s offline data files copied in ‘Android/data’ folder should not be vanished.

Источник

Android 11 storage FAQ

First introduced in Android 10, scoped storage is designed to protect app and user data and reduce file clutter. Since then, you’ve provided a lot of valuable feedback, which has helped us evolve the feature — thank you. Android 11 includes several notable enhancements that are based on your feedback. For example, we’ve enabled direct file path access to media files to improve compatibility of existing code and libraries. We understand that many apps, especially complex ones like Viber, require thoughtful planning to adopt scoped storage in order to continue supporting existing users, ensure adherence to current storage best practices, and maintain backward compatibility. Based on conversations with developers and lively discussions on public forums, we’ve prepared an FAQ to help you better understand various capabilities, behavior changes, and restrictions in scoped storage.

Does Scoped Storage allow apps to access files with file paths, using File API, for example?

• We recognize that some apps rely on code or libraries that access media file paths directly. Therefore on Android 11, apps with the read external storage permission are able to access files with file paths in the scoped storage environment. On Android 10 devices, this is not available to apps in the scoped storage environment unless they have opted-out by setting the android:requestLegacyExternalStorage manifest attribute. To ensure continuity across Android versions, if your app targets Android 10 or above, you should also opt-out. See scoped storage best practices for details.

How does the performance of file path access compare to Media Store APIs?

• The performance really depends on the exact use case. For sequential reads like in the case of playback of videos, file path access offers comparable performance to Media Store. However for random reads and writes, using file path can be up to twice as slow. For the fastest and most consistent read and writes we recommend Media Store APIs.

My app needs broad access to shared storage. Is Storage Access Framework the only option available?

• Storage Access Framework (SAF) is indeed one option that allows the user to grant access to directories and files. However, note that there are access restrictions to certain directories, such as the root and Android/data directories. While the majority of apps that need storage access can use best practices such as SAF or Media Store API, there could be cases where apps need broad access to shared storage or can’t do so efficiently with these best practices. For these cases, we have added the MANAGE_EXTERNAL_STORAGE permission to give access to all files on external storage, except the Android/data and Android/obb directories. To learn more about related Google Play guidelines, read the updated policy from the Policy Help Center.

What categories of apps should request the MANAGE_EXTERNAL_STORAGE permission?

• The MANAGE_EXTERNAL_STORAGE permission is intended for apps that have a core use case that requires broad access of files on a device, but cannot do so efficiently using scoped storage best practices. While it isn’t practical to enumerate all possible use cases, some use cases include file managers, backup and restore, anti-virus apps or productivity file editing apps.

Does using Storage Access Framework require Google Play policy approval?

• The Storage Access Framework has been in the platform since Android 4.4. Accessing files via Storage Access Framework gives users better control because the user is involved in picking files and it doesn’t require any user permissions. There’s no Google Play policy related to its usage.

Are there any further restrictions to using Storage Access Framework in Android 11 as compared to Android 10?

• Apps that target Android 11 (API level 30) and use Storage Access Framework will no longer be able to grant access to directories, such as the root directory of the SD card and the Download directory. Regardless of target SDK, Storage Access Framework on Android 11 cannot be used to gain access to Android/data and Android/obb directories. Learn more about these restrictions and ways to test the behaviors.

How can apps test out Scoped Storage changes?

• Apps can test out scoped storage behavior related to direct file path access or Media Store APIs via these compatibility flags. There’s also another compatibility flag to test the restrictions to access certain paths with Storage Access Framework.

Are apps in scoped storage limited to writing files into their app-specific data directories?

• In scoped storage, apps can contribute media files to Media Store collections. Media Store will put the files into well organized folders like DCIM, Movies, Download, and so on based on file type. For all such files, apps can also continue to have access via File APIs as well. The OS maintains a system to attribute an app to each media store file, so apps can read/write files that they originally contributed to the Media Store without needing storage permissions.

What is the guidance around using the Media Store DATA column since it’s been deprecated?

• On Android 10, apps in the scoped storage environment cannot access files using the file path. To be consistent with this design, we deprecated the DATA column then. Based on your feedback on the needs to work with existing native code or libraries, Android 11 now supports file path access for apps in scoped storage. Accordingly, the DATA column could actually be useful for some scenarios. For inserts and updates into the Media Store, apps in Scoped Storage should use DISPLAY_NAME and RELATIVE_PATH columns. They can no longer use the DATA column for this. When reading Media Store entries for files that exist on disk, the DATA column will have a valid file path, which can be used with the File API or NDK file libraries. Apps should however be prepared to handle any file I/O errors from these operations and should not assume the file is always available.

For apps that have opted out of Scoped Storage, when will they have to be compatible with Scoped Storage?

• On devices running Android 11 or higher, apps will be put into Scoped Storage as soon as they target Android 11 or higher.

What is the recommended way to migrate data that we currently store outside of Scoped Storage?

• preserveLegacyExternalStorage flag allows an app to retain legacy storage access on upgrades even while targeting Android 11. However beware that on new installs on Android 11, this flag has no effect. Please make code changes to adapt to Scoped Storage before targeting Android 11. Learn more about data migration best practices.

Are there any exceptions for Android/obb directories given that some package installers, like app stores, need access to it?

• Apps that hold the REQUEST_INSTALL_PACKAGES permission can access other apps’ Android/obb directories.

We hope you find this FAQ useful in planning your adoption of scoped storage. Please visit our best practice documentation for more information.

Источник

How to Access Private App Data on Android (No Root)

Often companies developing ParentalControl or DLP solutions require access to private data from software, installed on Android devices. For example, messages from Skype/KIK/Viber, etc., or even an access to a browsing history are both good examples of such tasks. By default (and this is what is used most often due to security) all Android apps save data in a so-called

Sandbox – a storage area which other applications cannot access. And if an app doesn’t provide an API to get the data (or simply places the data in memory card where other applications can access it), then this data seemingly cannot be accessed. In this article I want to show one simple and fairly elegant way to access private data of third party applications.

Proposed solution

The main idea behind the solution is very simple – to parse a layout tree of an active page and extract the necessary data.

One caveat is that, while this solution works well starting with Android 4.3 and older (including the latest Android N), to get a clean data without junk you will need to take your time to study each target application. There is no need for ROOT-access, since with it you would be able to read directly from a sandbox.

I will explain this approach based on one particular task: writing an Android app that can be used to monitor:

• Firefox browser history on Android 6.0 (public API for this was closed even for built-in browser)
• Skype instant messages (there was no official way to get access to them)

Basically, both tasks are very similar, since you’re trying to achieve the same thing, e.g., get access to personal data.

Android has a so called AccessibilityService – a built-in service and a set of API to develop applications for people with disabilities (mostly, people with eyesight and hearing problems).

This service is allowed to

• Subscribe to screen state change events, such as when screen focuses on a particular element of layout, when text changes, when image scrolls, etc.
• Read all content from the active screen

Therefore, our task is fairly simple – to write our own app similar to AccessibilityService, that will track any changes on the screen and react to them accordingly (for example, by saving all accessed web link to browsing history, or writing Skype messages into a log )

1. Create service class in Java as always
2. Declare our service in the manifest as an AccessibilityService and specify the config file for it. In the end, record about a service should look like this:

Create configuration file with parameters that our service should use (

Here let us look into more detail, since these attributes show the system what kind of data we want to receive in our service.

android:accessibilityEventTypes – it states that we want to receive all accessibility events, because it’s important to not miss anything 😉

android:accessibilityFlags – here we tell the system that we want to receive all the data about information displayed on the screen: layout element id, insignificant View, basically, anything.

android:canRetrieveWindowContent – this is the most important attribute! It prompts the system to provide us with the layout three with all the data.

Now, the rest is simple. We receive an AccessibilityEvent in the onAccessibilityEven parameter.

Here we can find out the name of application that initiated the event (getPackageName) and what exactly happened (getEventType), which is something that can prove useful when filtering events.

Secondly, we can call root tree node (getSource) and go through the whole tree (getChild, getChildCount), gathering information about each element of the tree, including its class (getClassName), id (getViewIdResourceName), and even text (getText). getText method is exactly what returns messages from instant messengers or URLs from browsers.

The main difficulty in gathering the data lies in the necessity to filer various tree nodes based on the class name, id, nesting, and maybe some other criteria, specific to a particular applications.

Received results

In this example, I went across the screen layout three to search for address bar simply by the element id. I also went through it to see the structure of the screen tree and dicover a pattern that will allow me to gather Skype messages.

For example, if user opens Skype and sees the following screen:

Then our parser can take it apart and get the messages (you can identify incoming and outgoing ones based on the structure of the tree)

Below is an example of our application log for this screen:

Advantages of this approach

1. This approach is very simple and reliable!
2. We can use this approach to both capture user data (Skype, Viber, Twitter, WhatsApp, Facebook, etc.) and control user actions (for example, prohibit user from changing particular device settings).
3. No need for any permissions in manifest.
4. Public API that potentially doesn’t prohibit distribution via Google Play (There is at least one other app that I know off that uses this approach to get browser history – Qustodio).
5. AccessibilityService is still active even after reboot.
6. There is a potential for controlling the screen of the device.

Disadvantages of this approach

1. Since this approach relies on screen parsing, there is a need for an ability to parse the screen and identify the necessary information. This will heavily vary based on the application you decide to target.
2. The need to create logic for storing data, since different pieces can be accessed at different times (for example, random scroll of the Skype chat, or switching between different chats).
3. Parsing large volumes of data can affect battery life. You need to carefully set time intervals between receiving events, and correctly filter target applications for monitoring.
4. User needs to explicitly (only once) activate AccessibilityService in the device settings (Settings → Accessibility → $TARGET_ACCESSIBILITY_SERVICE$ → Enable).
5. When target apps are updated you may need to update your parser. If the structure of the layout three changes, or even if developer simply decides to change controls id, you will need to adapt the logic of your parser to these changes.

A word of warning

Android security policy directly states that access to private data can be illegal, which puts certain limitations on gathering such data, including the possibility of being prosecuted by law. Therefore, use this method to obtain data consciously and thoughtfully and make sure that you abide by laws and respect privacy of others.

Get the project source code: GitHub repository.

Источник