Google android apps docs storage

Google android apps docs storage

Краткое описание:
Создание и редактирование документов.

Описание:
Бесплатное приложение «Google Документы» предназначено для создания и редактирования документов, а также для совместной работы с ними на смартфоне или плантешном ПК на базе Android.
Приложение «Google Документы» позволяет:

• создавать новые документы, а также открывать и редактировать существующие, которые были созданы через веб-интерфейс, на компьютере или мобильном устройстве;
• предоставлять доступ к документам и работать с ними одновременно с другими пользователями;
• редактировать документы даже без подключения к Интернету;
• добавлять комментарии и отвечать на них;
• не беспокоиться о том, что ваш труд пропадет даром, – все документы автоматически сохраняются по мере того, как в них вносятся изменения.

Вы можете работать с файлами на смартфоне или планшете даже без подключения к Интернету. В приложении Google Диск (Google Drive) можно просматривать разные типы файлов, а в приложениях «Google Документы» и «Google Таблицы» – редактировать документы и таблицы Google.

Чтобы сохранить файл для работы в офлайн-режиме, требуется подключение к Интернету.
В Google Документах настроить офлайн-доступ можно двумя способами:

• Нажмите на серую кнопку i рядом с названием файла (в списке или самом файле), а затем на панели подробных сведений, в разделе «Офлайн-доступ», поменяйте положение переключателя с Выкл. на Вкл.
• Нажмите на название и не отпускайте палец в течение 1–2 секунд. Затем в открывшемся меню выберите Офлайн-доступ.

Список файлов, доступных офлайн, находится в разделе «На устройстве». Он расположен на панели навигации в левой части экрана.

Отменить офлайн-доступ для файла можно одним из следующих способов:

• Нажмите на серую кнопку i рядом с названием файла (в списке или самом файле), а затем на панели подробных сведений, в разделе «Офлайн-доступ», поменяйте положение переключателя с Вкл. на Выкл.
• Нажмите на название и не отпускайте палец в течение 1–2 секунд. Затем в открывшемся меню выберите Удалить из памяти.

Работа в офлайн-режиме:

На Android-устройстве произошел сбой подключения к Интернету? Продолжите работу, перейдя в раздел На устройстве. Он расположен на навигационной панели приложений «Google Диск», «Google Документы» и «Google Таблицы».

В офлайн-режиме можно редактировать документы и таблицы. Они будут синхронизированы с копиями на Google Диске, как только восстановится подключение к Интернету. Прочие файлы, доступные офлайн, можно только читать, помечать звездочками и переименовывать.

Офлайн-доступ к файлу действует только для того приложения, в котором вы включили его. К примеру, если офлайн-доступ к текстовому документу включен в приложении «Google Диск», то файл будет доступен только для просмотра. Для его редактирования потребуется включить офлайн-доступ в приложении «Google Документы».

Требуется Android: 5.0+
Русский интерфейс: Да

Android 4.0+:
версия: 1.4.272.12.34 Google Документы (Google Docs) (Пост алекс12 #41650348)
версия: 1.4.272.11.34 Google Документы (Google Docs) (Пост iMiKED #41553736)
версия: 1.4.272.10.36 Google Документы (Google Docs) (Пост $tomack #41494102)
версия: 1.4.272.09.34 Google Документы (Google Docs) (Пост iMiKED #41470764)
версия: 1.4.232.11.34 Google Документы (Google Docs) (Пост iMiKED #40857537)
версия: 1.4.192.11.34 Google Документы (Google Docs) (Пост алекс12 #40225177)
версия: 1.4.192.07.35 Google Документы (Google Docs) (Пост pyshnyi #40112499)
версия: 1.4.152.14.70 Google Документы (Google Docs) (Пост pyshnyi #39991048)
версия: 1.4.152.14.34 Google Документы (Google Docs) (Пост алекс12 #39600211)
версия: 1.4.112.11.34 Google Документы (Google Docs) (Пост алекс12 #38936291)
версия: 1.4.072.10.34 Google Документы (Google Docs) (Пост алекс12 #38158082)
версия: 1.4.032.08.36 Google Документы (Google Docs) (Пост #37918623)
версия: 1.4.032.08.34 Google Документы (Google Docs) (Пост #37488643)
версия: 1.4.032.07.72 Google Документы (Google Docs) (Пост #37435260)
версия: 1.4.032.07.35 Google Документы (Google Docs) (Пост #35332968)
версия: 1.3.492.11.34 //4pda.to/forum/d…-44921134-minAPI14.apk
версия: 1.3.492.11.30 Google Документы (Google Docs) (Пост #35332968)
версия: 1.3.422.15.35 Google Документы (Google Docs) (Пост #35332968)
версия: 1.3.422.14.35 //4pda.to/forum/d….docs.editors.docs.apk
версия: 1.3.352.11.15 Google Документы (Google Docs) (Пост #34553003)
версия: 1.3.313.11.15 //4pda.to/forum/d…2%FB_1.3.313.11.15.apk
версия: 1.3.313.11.14 //4pda.to/forum/d…ocs.editors.docs-1.apk
версия: 1.3.313.10.14 //4pda.to/forum/d…ocs.editors.docs-1.apk
версия: 1.3.251.21 //4pda.to/forum/d…ocs.editors.docs-1.apk
версия: 1.3.144.19 Google_Docs_1.3.144.19.apk ( 10.16 МБ )
версия: 1.3.144.18 Google_Docs_1.3.144.18.apk ( 9.58 МБ )
версия: 1.3.144.15 Google_Docs_1.3.144.15.apk ( 10.16 МБ )
версия: 1.3.144.14 Google_Docs_1.3.144.14.apk ( 9.58 МБ )
версия: 1.3.144.12 Google_Docs_1.3.144.12.apk ( 9.58 МБ )

Сообщение отредактировал iMiKED — Вчера, 06:15

Источник

Data and file storage overview

Android uses a file system that’s similar to disk-based file systems on other platforms. The system provides several options for you to save your app data:

• App-specific storage: Store files that are meant for your app’s use only, either in dedicated directories within an internal storage volume or different dedicated directories within external storage. Use the directories within internal storage to save sensitive information that other apps shouldn’t access.
• Shared storage: Store files that your app intends to share with other apps, including media, documents, and other files.
• Preferences: Store private, primitive data in key-value pairs.
• Databases: Store structured data in a private database using the Room persistence library.

The characteristics of these options are summarized in the following table:

Type of content	Access method	Permissions needed	Can other apps access?	Files removed on app uninstall?
App-specific files	Files meant for your app’s use only	From internal storage, getFilesDir() or getCacheDir() From external storage, getExternalFilesDir() or getExternalCacheDir()	Never needed for internal storage Not needed for external storage when your app is used on devices that run Android 4.4 (API level 19) or higher	No	Yes
Media	Shareable media files (images, audio files, videos)	MediaStore API	READ_EXTERNAL_STORAGE when accessing other apps’ files on Android 11 (API level 30) or higher READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE when accessing other apps’ files on Android 10 (API level 29) Permissions are required for all files on Android 9 (API level 28) or lower	Yes, though the other app needs the READ_EXTERNAL_STORAGE permission	No
Documents and other files	Other types of shareable content, including downloaded files	Storage Access Framework	None	Yes, through the system file picker	No
App preferences	Key-value pairs	Jetpack Preferences library	None	No	Yes
Database	Structured data	Room persistence library	None	No	Yes

The solution you choose depends on your specific needs:

How much space does your data require? Internal storage has limited space for app-specific data. Use other types of storage if you need to save a substantial amount of data. How reliable does data access need to be? If your app’s basic functionality requires certain data, such as when your app is starting up, place the data within internal storage directory or a database. App-specific files that are stored in external storage aren’t always accessible because some devices allow users to remove a physical device that corresponds to external storage. What kind of data do you need to store? If you have data that’s only meaningful for your app, use app-specific storage. For shareable media content, use shared storage so that other apps can access the content. For structured data, use either preferences (for key-value data) or a database (for data that contains more than 2 columns). Should the data be private to your app? When storing sensitive data—data that shouldn’t be accessible from any other app—use internal storage, preferences, or a database. Internal storage has the added benefit of the data being hidden from users.

Categories of storage locations

Android provides two types of physical storage locations: internal storage and external storage. On most devices, internal storage is smaller than external storage. However, internal storage is always available on all devices, making it a more reliable place to put data on which your app depends.

Removable volumes, such as an SD card, appear in the file system as part of external storage. Android represents these devices using a path, such as /sdcard .

Apps themselves are stored within internal storage by default. If your APK size is very large, however, you can indicate a preference within your app’s manifest file to install your app on external storage instead:

Permissions and access to external storage

On earlier versions of Android, apps needed to declare the READ_EXTERNAL_STORAGE permission to access any file outside the app-specific directories on external storage. Also, apps needed to declare the WRITE_EXTERNAL_STORAGE permission to write to any file outside the app-specific directory.

More recent versions of Android rely more on a file’s purpose than its location for determining an app’s ability to access, and write to, a given file. In particular, if your app targets Android 11 (API level 30) or higher, the WRITE_EXTERNAL_STORAGE permission doesn’t have any effect on your app’s access to storage. This purpose-based storage model improves user privacy because apps are given access only to the areas of the device’s file system that they actually use.

Android 11 introduces the MANAGE_EXTERNAL_STORAGE permission, which provides write access to files outside the app-specific directory and MediaStore . To learn more about this permission, and why most apps don’t need to declare it to fulfill their use cases, see the guide on how to manage all files on a storage device.

Scoped storage

To give users more control over their files and to limit file clutter, apps that target Android 10 (API level 29) and higher are given scoped access into external storage, or scoped storage, by default. Such apps have access only to the app-specific directory on external storage, as well as specific types of media that the app has created.

Use scoped storage unless your app needs access to a file that’s stored outside of an app-specific directory and outside of a directory that the MediaStore APIs can access. If you store app-specific files on external storage, you can make it easier to adopt scoped storage by placing these files in an app-specific directory on external storage. That way, your app maintains access to these files when scoped storage is enabled.

To prepare your app for scoped storage, view the storage use cases and best practices guide. If your app has another use case that isn’t covered by scoped storage, file a feature request. You can temporarily opt-out of using scoped storage.

View files on a device

To view the files stored on a device, use Android Studio’s Device File Explorer.

Additional resources

For more information about data storage, consult the following resources.

Videos

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник

Open files using storage access framework

Android 4.4 (API level 19) introduces the Storage Access Framework (SAF). The SAF makes it simple for users to browse and open documents, images, and other files across all of their preferred document storage providers. A standard, easy-to-use UI lets users browse files and access recents in a consistent way across apps and providers.

Cloud or local storage services can participate in this ecosystem by implementing a DocumentsProvider that encapsulates their services. Client apps that need access to a provider’s documents can integrate with the SAF with just a few lines of code.

The SAF includes the following:

• Document provider—A content provider that allows a storage service (such as Google Drive) to reveal the files it manages. A document provider is implemented as a subclass of the DocumentsProvider class. The document-provider schema is based on a traditional file hierarchy, though how your document provider physically stores data is up to you. The Android platform includes several built-in document providers, such as Downloads, Images, and Videos.
• Client app—A custom app that invokes the ACTION_CREATE_DOCUMENT , ACTION_OPEN_DOCUMENT , and ACTION_OPEN_DOCUMENT_TREE intent actions and receives the files returned by document providers.
• Picker—A system UI that lets users access documents from all document providers that satisfy the client app’s search criteria.

Some of the features offered by the SAF are as follows:

• Lets users browse content from all document providers, not just a single app.
• Makes it possible for your app to have long term, persistent access to documents owned by a document provider. Through this access users can add, edit, save, and delete files on the provider.
• Supports multiple user accounts and transient roots such as USB storage providers, which only appear if the drive is plugged in.

Overview

The SAF centers around a content provider that is a subclass of the DocumentsProvider class. Within a document provider, data is structured as a traditional file hierarchy:

Figure 1. Document provider data model. A Root points to a single Document, which then starts the fan-out of the entire tree.

Note the following:

• Each document provider reports one or more ‘roots’, which are starting points into exploring a tree of documents. Each root has a unique COLUMN_ROOT_ID , and it points to a document (a directory) representing the contents under that root. Roots are dynamic by design to support use cases like multiple accounts, transient USB storage devices, or user login/logout.
• Under each root is a single document. That document points to 1 to N documents, each of which in turn can point to 1 to N documents.
• Each storage backend surfaces individual files and directories by referencing them with a unique COLUMN_DOCUMENT_ID . Document IDs must be unique and not change once issued, since they are used for persistent URI grants across device reboots.
• Documents can be either an openable file (with a specific MIME type), or a directory containing additional documents (with the MIME_TYPE_DIR MIME type).
• Each document can have different capabilities, as described by COLUMN_FLAGS . For example, FLAG_SUPPORTS_WRITE , FLAG_SUPPORTS_DELETE , and FLAG_SUPPORTS_THUMBNAIL . The same COLUMN_DOCUMENT_ID can be included in multiple directories.

Control flow

As stated above, the document provider data model is based on a traditional file hierarchy. However, you can physically store your data however you like, as long as you can access it by using DocumentsProvider API. For example, you could use tag-based cloud storage for your data.

Figure 2 shows how a photo app might use the SAF to access stored data:

Figure 2. Storage Access Framework Flow

Note the following:

• In the SAF, providers and clients don’t interact directly. A client requests permission to interact with files (that is, to read, edit, create, or delete files).
• The interaction starts when an application (in this example, a photo app) fires the intent ACTION_OPEN_DOCUMENT or ACTION_CREATE_DOCUMENT . The intent can include filters to further refine the criteria—for example, «give me all openable files that have the ‘image’ MIME type.»
• Once the intent fires, the system picker goes to each registered provider and shows the user the matching content roots.
• The picker gives users a standard interface for accessing documents, even though the underlying document providers may be very different. For example, figure 2 shows a Google Drive provider, a USB provider, and a cloud provider.

Figure 3 shows a picker in which a user searching for images has selected the Downloads folder. It also shows all of the roots available to the client app.

Figure 3. Picker

After the user selects the Downloads folder, the images are displayed. Figure 4 shows the result of this process. The user can now interact with these images in the ways that the provider and client app support.

Figure 4. Images stored in the Downloads folder, as viewed in the system picker

Writing a client app

On Android 4.3 and lower, if you want your app to retrieve a file from another app, it must invoke an intent such as ACTION_PICK or ACTION_GET_CONTENT . The user must then select a single app from which to pick a file and the selected app must provide a user interface for the user to browse and pick from the available files.

On Android 4.4 (API level 19) and higher, you have the additional option of using the ACTION_OPEN_DOCUMENT intent, which displays a system-controlled picker UI controlled that allows the user to browse all files that other apps have made available. From this single UI, the user can pick a file from any of the supported apps.

On Android 5.0 (API level 21) and higher, you can also use the ACTION_OPEN_DOCUMENT_TREE intent, which allows the user to choose a directory for a client app to access.

Note: ACTION_OPEN_DOCUMENT is not intended to be a replacement for ACTION_GET_CONTENT . The one you should use depends on the needs of your app:

• Use ACTION_GET_CONTENT if you want your app to simply read or import data. With this approach, the app imports a copy of the data, such as an image file.
• Use ACTION_OPEN_DOCUMENT if you want your app to have long term, persistent access to documents owned by a document provider. An example would be a photo-editing app that lets users edit images stored in a document provider.

For more information on how to support browsing for files and directories using the system picker UI, see the guide on how to access documents and other files.

Additional resources

For more information about document providers, take advantage of the following resources:

Источник