Android способы сохранения данных

Android Storage: Internal, External, Removable. Часть 1/3

Всем, кто, несмотря ни на что, сумел сделать правильный выбор.

Это перевод серии статей от Mark Murphy из CommonsWare, широко известного на stackoverflow, а так же автора книг “The Busy Coder’s Guide to Android Development”, “Android’s Architecture Components”. Некоторые термины оставлены не переведенными специально.

Internal Storage

Существует много путаницы в отношении модели хранилища Android. Путаницы стало значительно больше с изменениями Android 4.4 в Storage Model, и с тех пор ситуация не улучшилась. Есть бесчисленное множество вопросов на Stack Overflow и тому подобных ресурсах, где люди явно не совсем разбираются в различных моделях хранилищ Android.

То, что пользователи считают Internal Storage

В зависимости от модели вашего устройства пользователи в конечном итоге придут в «Настройки» —> «Хранилище на этом устройстве» (Settings —> Storage on their device) или в эквивалентном месте, и могут видеть экран, который описывает «Внутреннее хранилище».

Пользователь думает, что вся встроенная флешка — это «внутреннее хранилище» (Internal Storage). К счастью, Google начал менять этот термин с Android 8.0, перейдя к «general storage» вместо «internal storage».

Тем не менее, пользователи могут по-прежнему видеть «внутреннее хранилище» в таких местах, как окно проводника в Windows, когда их устройство подключено через USB.

Что Google считает Internal Storage

Увы, то, что видят пользователи это не то же самое, что Android SDK считает «внутренним хранилищем», что приводит к некоторой путанице. Если вы читали документацию на Android по внутреннему хранилищу, то это описание … как минимум туманно (прим. текст изменился со времени написания статьи):

Вы можете сохранять файлы непосредственно во внутренней памяти устройства. По умолчанию файлы, сохраненные во внутреннем хранилище, являются приватными для вашего приложения, и другие приложения не могут получить к ним доступ (также как и пользователь). Когда пользователь удаляет приложение, эти файлы удаляются.

По правде говоря, Android SDK определяет «внутреннее хранилище» как особый каталог, уникальный для вашего приложения, где ваше приложение может размещать файлы. Как было предложено в документации, эти файлы по умолчанию предназначены для чтения и записи для вашего приложения и запрещены для любого другого приложения (исключение: пользователи, работающие с файловыми менеджерами с привилегиями суперпользователя на rooted устройствах могут получить доступ ко всему).

В Context есть несколько базовых методов, которые предоставляют вам доступ к внутреннему хранилищу, в том числе:

• getCacheDir()
• getDir()
• getDatabasePath()
• getFilesDir()
• openFileInput()
• openFileOutput()

Другие методы будут опираться на них, такие как openOrCreateDatabase() . Другие классы также будут полагаться на них, такие как SQLiteOpenHelper и SharedPreferences .

Где хранится Internal Storage … Иногда

Если вы просматриваете различные сообщения в блогах, ответы на StackOverflow и книги, выпущенные в 2012 году или ранее, вам сообщается, что «внутреннее хранилище» вашего приложения находится по адресу: /data/data/your.application.package.name .

Внутри будут некоторые каталоги, автоматически созданные Android, поскольку вы используете некоторые из методов Context. Например, getFilesDir() возвращает объект File , указывающий на каталог files/ во внутреннем хранилище вашего приложения.

Где хранится Internal Storage … Остальное время

Однако не всегда внутреннее хранилище вашего приложения находится в указанном месте. Для разработчиков есть одно правило, которое вы должны усвоить из этой серии сообщений в блоге, это:

NEVER HARDCODE PATHS.

Время от времени я вижу, что разработчики делают что-то вроде этого:

File f=new File(«/data/data/their.app.package.name/files/foo.txt»);

Это не преступление, это хуже, это — ошибка.

Правильный ход, да и писать меньше:

File f=new File(getFilesDir(), «foo.txt»);

Что еще более важно, внутреннее хранилище не всегда находится в одном месте. Примечательно, что у нас есть понятие отдельных профилей пользователей (separate user profiles), начиная с Android 4.2 для планшетов и Android 5.0 для телефонов. Каждый пользователь получает свое собственное «внутреннее хранилище». Хотя вышеупомянутый каталог по-прежнему используется для основного пользователя, не гарантируется, что он же будет использоваться для вторичных учетных записей.

Исследуем Internal Storage

Device File Explorer tool в Android Studio 3.0+ может просматривать все внутренние хранилища на эмуляторе, а также внутреннее хранилище отлаживаемых приложений на продакшн устройствах.

В командной строке вы можете использовать adb с опцией run-as .

Например, чтобы загрузить базу данных из внутреннего хранилища основного пользователя на вашу девелоперскую машину, вы можете использовать:

adb shell ‘run-as your.application.package.name cp /data/data/your.application.package.name/databases/dbname.db /sdcard’

Обратите внимание, что:

• Вам нужно будет изменить пункт назначения туда, где на вашем устройстве монтируется внешнее хранилище (показано здесь как /sdcard/ , которое не будет одинаковым на всех устройствах)
• Возможно, вам придется использовать cat вместо cp на старых устройствах
• После того, как файл будет находиться на внешнем хранилище, вы сможете использовать adb pull , чтобы загрузить его на свой компьютер, или получить доступ к нему другими обычными способами (например, путем монтирования устройства в качестве диска).

Ограничения внутреннего хранилища

На старых устройствах Android 1.x и 2.x внутреннее хранилище обычно находилось в выделенном разделе файловой системы, и этот раздел обычно был довольно крошечным. HTC Dream (a.k.a., T-Mobile G1), оригинальное Android-устройство, обладал огромными 70 МБ встроенной памяти для использования всеми приложениями (это не опечатка, в то время мы измеряли память в мегабайтах).

К тому времени, когда вышли 2.3 устройства, внутреннее хранилище могло быть размером 1 ГБ.

Android 3.0 изменил модель хранилища, так как внутреннее хранилище стало больше объемом. У устройств, которые рекламируют как имеющее 4 ГБ, 8 ГБ, 16 ГБ и т.д. пространства для хранения, обычно имелось все это (минус существующее содержимое) доступное для внутреннего хранилища. Мы рассмотрим, что изменилось в Android 3.0 и его влияние на модель хранилища в следующих постах про внешнее хранилище.

Для Android 1.x и 2.x внутреннее хранилище было действительно только для небольших файлов, и вам нужно было использовать внешнее хранилище для всего остального. Android 3.0+ означает, что для большинства устройств и большинства пользователей внутреннее хранилище отлично подходит для файлов, которые не предназначены для обычного использования другими приложениями или доступны пользователю независимо от вашего приложения. Однако некоторые опытные пользователи обнаруживают, что даже on-board flash недостаточна для того, что они хотят хранить, поэтому они переходят на съемные хранилища… которые представляют собой банку с червями (прим. имеются в виду ἕλμινς) — источник многих непредсказуемых и сложных проблем.

F.A.Q. по Internal Storage

Должен ли я делать файлы во внутреннем хранилище World-Readable или World-Writeable?

О, $БОГИ, нет. Используйте FileProvider и обслуживайте этот контент с помощью реализации ContentProvider . После этого вы, по крайней мере, имеете возможность использовать систему разрешений Android для управления доступом к этим файлам, в отличие от вашего варианта, когда любое приложение в системе может испортить эти файлы.

Ну, а как насчет android:sharedUserId ?

android: sharedUserId — это атрибут, который вы можете поместить в манифест, который указывает логический идентификатор пользователя, который будет использоваться для вашего приложения. Любое другое приложение, которое установлено, которое подписывается одним и тем же ключом подписи и запрашивает тот же android:sharedUserId будет использовать одного и того же пользователя Linux с точки зрения безопасности. Эффект заключается в том, что эти два приложения смогут безнаказанно работать с файлами друг друга, так как эти файлы принадлежат одному и тому же пользователю Linux.

Этот атрибут реально предназначен для предварительно установленных приложений, таких как software suite предварительно загруженный производителем устройства, мобильным оператором или разработчиком модифицированной ROM прошивки. В частности, как только вы единожды установите свое приложение, вы не сможете затем безболезненно изменить свое значение android:sharedUserId не заблокировав при этом доступ пользователю к любым существующим файлам… поскольку Android не изменяет права владельца на существующие файлы при изменении учетной записи пользователя Linux, под которой запускается приложение.

Существуют различные риски при одновременном доступе нескольких процессов к файлам. Некоторые подсистемы, такие как SQLite, имеют встроенную логику для решения этой проблемы. Но если вы сами организуете свой собственный доступ к файлу (например, через File и Java I/O), вам нужно что-то делать с одновременным доступом, а это сложно.

Вам также нужно обрабатывать ситуацию, когда одно приложение деинсталлируется, удаляя файлы, которые использовало другое приложение. В модели hub-and-spoke, например, с приложением и набором плагинов, возможно, это не так рискованно. В других моделях, где приложения более равноправны, вы не можете позволить себе потерять данные своего приложения только потому, что пользователь решил удалить какое-то отдельное приложение.

Наконец, вы не знаете, что может принести будущее. Прямо сейчас вы можете рассматривать свой набор приложений в виде набора с тесной связью. Кто-то, кто приобретает эти приложения или приобретает вашу фирму, может пожелать пойти другим путем. Использование возможностей совместного доступа к данным, которые более слабо связаны, например ContentProvider , дает вам большую гибкость. В идеальном мире ваше приложение должно относиться к другим приложениям как к достаточно надежному, но не всегда доступному ресурсу, так же, как к вашему собственному веб-сервису.

Как запретить пользователям rooted устройств доступ к моим файлам во внутреннем хранилище?

Просто не помещайте файлы во внутреннее хранилище. Пользователи rooted устройств могут получить доступ к тому, что им нужно на устройстве, поэтому единственный способ предотвратить их доступ к вашим данным — не иметь их на устройстве.

Некоторые разработчики попытаются зашифровать свои файлы с помощью жестко запрограммированного пароля, чтобы пользователи rooted устройств не могли использовать эти файлы. Это создаст эффект «лежачего полицейского» на короткое время. Все, что требуется, — это один заинтересованный в реверс-инжиниринге вашего приложения человек, определивший, как расшифровать эти файлы, а затем написавший сообщение в блоге или форуме о том, как это сделать.

В целом, относительно мало людей с rooted устройствами — я оцениваю их на уровне менее 1%. ИМХО, вы преуспеете больше, сосредоточив свою инженерную работу на написании лучшего приложения, вместо того, чтобы тратить время на защиту от рутованных устройств.

Источник

Хранение данных в Android

В прошлом своем посте я писал о создании всплывающих менюшек, сегодня же мы поговорим о более важной теме такой, как хранение данных. В android есть несколько способов хранения данных: общие настройки, бд и тд. В этом посте я расскажу о том как хранить данные в БД.
В качестве БД android использует встраиваемую SQLite. SQLite очень быстрая база, поэтому ее использование на мобильной платформе не приводит к резкому уменьшению производительности. Перейдем к описанию кода. Гугл позаботился о наших нервах и написал небольшой класс утилиту SQLiteOpenHelper.

public class DbOpenHelper extends SQLiteOpenHelper<

private static final int DB_VERSION = 1;
private static final String DB_NAME = «test» ;

public static final String TABLE_NAME = «users» ;
public static final String LOGIN = «login» ;
public static final String PASSW = «passw» ;
private static final String CREATE_TABLE = «create table » + TABLE_NAME + » ( _id integer primary key autoincrement, »
+ LOGIN + » TEXT, » + PASSW + » TEXT)» ;

public DbOpenHelper(Context context) <
super(context, DB_NAME, null ,DB_VERSION);
>

@Override
public void onCreate(SQLiteDatabase sqLiteDatabase) <
sqLiteDatabase.execSQL(CREATE_TABLE);
>

@Override
public void onUpgrade(SQLiteDatabase sqLiteDatabase, int i, int i1) <
>
>

* This source code was highlighted with Source Code Highlighter .

При создании экземпляра класса DbOpenHelper будет проверено, существует ли база с именем test, если существует, то будет вызван метод onUpgrade, если нет то onCreate в котором мы создаем таблицу users(обычно в этом методе создают таблицы и инициализируют их значениями по умолчанию). У класса SQLiteOpenHelper есть методы getReadableDatabase и getWritableDatabase, которые возвращают экземпляр класса SQLiteDatabase. С помощью этого экземпляра мы и будет работать с БД. У него есть все нужные нам методы: insert, update, query, delete и тд.
Напишем небольшое приложение сохраняющее логин и пароль в базу

public class TestActivity extends Activity <

EditText loginEditText = null ;
EditText passEditText = null ;
Button saveButton = null ;

@Override
public void onCreate(Bundle savedInstanceState) <
super.onCreate(savedInstanceState);
setContentView(R.layout.main);

loginEditText = (EditText) findViewById(R.id.login);
passEditText = (EditText) findViewById(R.id.passw);
saveButton = (Button) findViewById(R.id.btn1);

saveButton.setOnClickListener( new View.OnClickListener() <
public void onClick(View view) <
DbOpenHelper dbOpenHelper = new DbOpenHelper(TestActivity. this );
SQLiteDatabase db = dbOpenHelper.getWritableDatabase();
ContentValues cv = new ContentValues();
cv.put(DbOpenHelper.LOGIN,loginEditText.getText().toString());
cv.put(DbOpenHelper.PASSW,passEditText.getText().toString());
db.insert(DbOpenHelper.TABLE_NAME, null ,cv);
db.close();
loginEditText.setText( «» );
passEditText.setText( «» );
>
>);
>
>

* This source code was highlighted with Source Code Highlighter .

Источник

Android с нуля: как хранить данные приложения локально

Russian (Pусский) translation by Ellen Nelson (you can also view the original English article)

Когда доходит до сохранения данных приложений локально, разработчики Android определённо избалованы выбором. Помимо прямого доступа к внутренним и внешним областям хранения Android-устройства, платформа Android предлагает базы данных SQLite для хранения реляционных данных и специальные файлы для хранения пар ключ-значение. Более того, приложения для Android также могут использовать сторонние базы данных, которые предлагают поддержку NoSQL.

В этом уроке я покажу вам, как использовать все эти параметры хранения в приложениях для Android. Я также помогу вам понять, как выбрать наиболее подходящий вариант хранения данных.

Вам проще учиться по видео? Почему бы не посмотреть наш курс:

1. Хранение пар ключ-значение

Если вы ищете быстрый способ хранения нескольких строк или номеров, вам следует рассмотреть возможность использования файла настроек (preferences). Активити и службы Android могут использовать метод getDefaultSharedPreferences() класса PreferenceManager , чтобы ссылаться на объект SharedPreferences , который может быть использован и для чтения, и для записи в файл настроек по умолчанию.

Чтобы начать запись в файл настроек, вы должны вызвать метод edit() объекта SharedPreferences , который возвращает объект SharedPreferences.Editor .

Объект SharedPreferences.Editor имеет несколько интуитивных методов, которые можно использовать для хранения новых пар ключ-значение в файле настроек. Например, вы можете использовать метод putString() , чтобы поместить пару ключ-значение со значением типа String . Аналогично, вы можете использовать метод putFloat() , чтобы поместить пару ключ-значение, чьё значение типа float . Следующий пример кода создаёт три пары ключ-значение:

После того, как вы добавили все пары, вы должны вызвать метод commit() объекта SharedPreferences.Editor , чтобы сохранить их.

Чтение из объекта SharedPreferences гораздо проще. Всё, что вам нужно сделать, так это вызвать соответствующий метод get*() . Например, чтобы получить пару ключ-значение, чьё значение является String , вы должны вызывать метод getString() . Вот фрагмент кода, который извлекает все значения, которые мы добавили ранее:

Как вы видите из кода выше, второй параметр всех методов get*() ожидает значение по-умолчанию, которое является значением, которое должно быть возвращено, если ключ не существует и файле настроек.

Обратите внимание, что файлы настроек ограничены только строками и примитивными типами данных. Если вы хотите сохранить более сложные типы данных или двоичные данные, вы должны выбрать другой вариант хранения.

2. Использование базы данных SQLite

Каждое приложение для Android может создавать и использовать базы данных SQLite для хранения больших объемов структурированных данных. Как вы уже знаете, SQLite не только лёгкая, но и очень быстрая. Если у вас есть опыт работы с системами управления реляционными базами данных и вы знакомы как с SQL, что является сокращением для Structured Query Language, и JDBC, что является сокращением для Java Database Connectivity, это может быть предпочтительным вариантом хранения.

Чтобы создать новую базу данных SQLite или открыть уже существующую, вы можете использовать метод openOrCreateDatabase() внутри своей активити или службы. В качестве аргументов вы должны передать имя своей базы данных и режим, в котором вы хотите её открыть. Наиболее часто используемый режим MODE_PRIVATE , который гарантирует, что база данных доступна только для вашего приложения. Например, вот как вы можете открыть или создать базу данных с именем my.db:

После создания базы данных вы можете использовать метод execSQL() для запуска SQL-инструкций. В следующем коде показано, как использовать оператор SQL CREATE TABLE для создания таблицы названной user, которая имеет три столбца:

Хотя можно вставить новые строки в таблицу с помощью метода execSQL() , лучше использовать метод insert() . Метод insert() ожидает объект ContentValues , содержащий значения для каждого столбца таблицы. Объект ContentValues очень похож на объект Map и содержит пары ключ-значение.

Вот два объекта ContentValues , которые вы можете использовать с таблицей user :

Как вы могли догадаться, ключи, которые вы передаете методу put() , должны соответствовать именам столбцов в таблице.

Когда объекты ContentValues готовы, вы можете передать их методу insert() вместе с именем таблицы.

Чтобы отправить запрос в базу данных, вы можете использовать метод rawQuery() , который возвращает объект Cursor , содержащий результаты запроса.

Объект Cursor может содержать ноль или несколько строк. Самый простой способ перебрать все его строки, так это вызвать метод moveToNext() внутри цикла while .

Чтобы получить значение отдельного столбца, вы должны использовать такие методы, как getString() и getInt() , которые ожидают индекс столбца. Например, вот как вы получите все значения, вставленные в таблице user :

После того, как вы получите все результаты вашего запроса, убедитесь, что вы вызвали метод close() для объекта Cursor , чтобы освободить все ресурсы, которые он хранит.

Аналогичным образом, когда вы закончили все операции с базой данных, не забудьте вызвать метод close() для объекта SQLiteDatabase .

3. Использование внутреннего хранилища

Каждое приложение Android имеет свой собственный внутренний каталог хранения, взаимодействующий с ним, в котором приложение может хранить текстовые и двоичные файлы. Файлы внутри этого каталога недоступны для пользователя или других приложений, установленных на устройстве пользователя. Они также автоматически удаляются, когда пользователь удаляет приложение.

Прежде чем вы сможете использовать внутренний каталог хранилища, вы должны определить его местоположение. Для этого вы можете вызвать метод getFilesDir() , который доступен как для активити, так и для служб.

Чтобы получить ссылку на файл внутри каталога, вы можете передать имя файла вместе с указанным вами расположением. Например, вот как вы получите ссылку на файл alice.csv:

С этого момента вы можете использовать свои знания о классах и методах I/O (ввода/вывода) Java для чтения или записи в файл. В следующем фрагменте кода показано, как использовать объект FileOutputStream и метод write() для записи в файл:

4 . Использование внешнего хранилища

Поскольку внутреннее хранилище устройств Android обычно фиксировано и часто довольно ограничено, некоторые устройства Android поддерживают внешние носители данных, такие как съемные микро SD-карты. Я рекомендую использовать этот вариант хранения для больших файлов, таких как фотографии и видео.

В отличие от внутреннего хранилища, внешнее хранилище может не всегда быть доступно. Поэтому, перед его использованием, вы должны всегда проверять, смонтировано ли оно. Для этого используйте метод getExternalStorageState() класса Environment .

Как только вы убедитесь, что внешнее хранилище доступно, вы можете получить путь к файлу внешнего хранилища для своего приложения, вызвав метод getExternalFilesDir() и передав null в качестве аргумента. Затем вы можете использовать путь для ссылки на файлы внутри каталога. Например, вот как вы можете ссылаться на файл с именем bob.jpg в каталоге внешнего хранилища приложения:

Попросив пользователя предоставить вам разрешение WRITE_EXTERNAL_STORAGE , вы можете получить доступ для чтения/записи ко всей файловой системе во внешнем хранилище. Затем вы можете использовать известные общедоступные каталоги для хранения ваших фотографий, фильмов и других мультимедийных файлов. Класс Environment предлагает метод getExternalStoragePublicDirectory() для определения путей этих общих каталогов.

Например, передав этому методу значение Environment.DIRECTORY_PICTURES , вы можете определить путь к общедоступному каталогу, в котором вы можете хранить фотографии. Аналогично, если вы передадите этому методу значение Environment.DIRECTORY_MOVIES , вы получите путь к общедоступному каталогу, в котором могут быть сохранены фильмы.

Вот как вы можете ссылаться на файл bob.jpg в каталоге общих изображений:

Когда у вас есть объект File , вы можете снова использовать классы FileInputStream и FileOutputStream для чтения или записи на него.

Заключение

Теперь вы знаете, как максимально использовать возможности локального хранилища, предоставляемые Android SDK. Независимо от выбранного вами варианта хранения операции чтения/записи могут потребовать много времени, если задействованы большие объемы данных. Поэтому, чтобы убедиться, что основной поток пользовательского интерфейса всегда остается отзывчивым, вы должны рассмотреть возможность запуска операций в другом потоке.

Чтобы узнать больше о сохранении данных приложения локально, обратитесь к официальному руководству API хранения данных.

Источник