Вы можете не читать, а просто посмотреть мой доклад на прошедшем DroidCon.
Но специально для тех, кто любит читать хабр больше чем смотреть youtube — добро пожаловать под кат. Там мы пройдемся по чеклисту действий, которые каждый обязательно должен сделать в своем приложении, а потом посмотрим на новые возможности для разработчиков в sdk 23.
Всё нижесказанное относится только к приложениям с targetSdk = 23 и выше! Как будут вести себя приложения с более старыми sdk на зефирке готов обсудить в комментариях.
К сожалению длина статьи не смогла вместить эти три важнейших изменения в Android Marshmallow. Пожалуйста, прочтите о них в отдельной статье.
Теперь Android приложения каждую ночь, пока девайс на зарядке, будут сливать в пользовательский Drive все настройки. Вернее, те которые мы разрешим.
Зачем?
Пользователь при покупке нового сразу восстанавливает из Google Play не только все приложения, но и их настройки.
Чем плохо для нас?
В облако и на новые девайсы улетают из shared preferences данные аккаунтов и ключи GCM (пуши перестают работать). Нужно это предотвратить!
По дефолту бэкапятся все папки нашего приложения и все SharedPreferences. Не сохраняются лишь:
— пути на SD карте, не находящиеся в android/data/...
— getCacheDir()
— getCodeCacheDir()
— getNoBackupFilesDir()
Последняя папочка специально для этого как раз и создана.
Чтобы предотвратить часть файлов от бекапа пишем вот такую xml, где перечисляем все данные, которые не желаем пускать в бекап:
<android:fullBackupContent="@xml/mybackupscheme"><full-backup-content>
<exclude domain=
["file" | "database" | "sharedpref"| "external" | "root"] path="string”>
</full-backup-content>
Чтобы определить наоборот лишь те файлы, которые хотим пустить в облако:
<android:fullBackupContent="@xml/mybackupscheme"><full-backup-content>
<include domain=
["file" | "database" | "sharedpref"| "external" | "root"] path="string”>
</full-backup-content>
Если в бекап таки ушли ненужные для восстановления данные, мы можем сделать вот такую хитрость: в классе наследнике Application переопределить метод onRestoreFinished() и в нем удалить нежелательно восстановленные записи.
! Уберите из бекапа ключи Google Cloud Messages !
Подробнее: http://ift.tt/1Peg9xj
Пример: http://ift.tt/1LUetoU
Если вы еще используете Apache Http client и напрочь отказываетесь перейти на современные аналоги, например, OkHttp, то вам срочно нужно добавить в build.gradle:
android { useLibrary 'org.apache.http.legacy' }
Теперь из sdk выпилили OpenSSL: libcrypto.so и libssl.so заменены на BoringSSL.
Если вы вдруг не знали до сегодняшнего дня о Notification.Builder, а использовали для содания нотификаций notification.setLatestEventInfo(), хватит, он удален. Прочитайте хотя бы мою статью, а лучше официальные доки, как правильно создавать и обновлять уведомления.
Теперь пользователь может отформатировать sd-карточку, превратив ее в почти внутреннее шифрованное хранилище. И тем самым у него появится переносить приложения на нее. Чем это грозит для нас?
Если мы не используем в приложении стандартные методы и константы для получения путей (getFilesDir(), getCacheDir() и т.д.), а хардкодим пути к внутреннему хранилищу, то после перемещения файлов на карту точка монтирования сменится, и все наши старательно прописанные пути перестанут быть валидными.
Подробнее: http://ift.tt/1LUetFa
Доступ к мак адресам устройств в округе теперь возможен только при сканировании методами WifiManager.getScanResults() BluetoothLeScanner.startScan() и при запрошенных пермишенах ACCESS_FINE_LOCATION или ACCESS_COARSE_LOCATION. А вот методы WifiInfo.getMacAddress() и BluetoothAdapter.getAddress() вернут всегда пустышку 02:00:00:00:00:00. это сделано в целях повышения секьюрности пользователя. Жаль не все обновятся на marshmallow, да и кастомные прошивки вряд ли сохранят это ограничение.
Из Android Keystore provider выкинули поддержку DSA-шифрования.
Теперь состояния WifiConfiguration объектов наши приложения могут менять только, если они сами их создали.
У камеры хорошие изменения по работе с доступом к сервису. Если приложение ушло в фон, а другое приложение наоборот вышло на первый план, то ему отдастся приоритет, а первое лишится сервиса. А еще, теперь можно использовать из разных приложений одновременно доступ к разным камерам устройства.
- Теперь корректно реализована обработка прав на newInstance().
- Динамический линкер теперь понимает различия между soname библиотеки и ее путем, а еще появился поиск по soname.
- Починили флаг dlopen(3) RTLD_LOCAL.
С обязательными изменениями в нашем приложении покончено. Перейдем к основным фичам, которые нам предоставляет новый SDK.
App Linking
Многие разработчики встраивают в свои приложения фильтры url-схем, чтобы пользователю было предложено открыть определенный url с помощью приложения. Теперь появилась возможность лишить возможности других разработчиков обрабатывать url вашего сайта. Допустим если вы делаете банкинг, то точно не хотите, чтобы другие приложения, кроме приложения-клиента вашего банка могли открываться по нажатию пользователем на ссылку.
В манифесте нужно добавить вот такого вида фильтр:
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category
android:name="android.intent.category.BROWSABLE" />
<data android:scheme="http" android:host="www.android.com" />
<data android:scheme="https" android:host="www.android.com" />
</intent-filter>
И положить JSON на свой сайт (http://ift.tt/1LUerx5), вставив sha256 из кейстора, которым подписано приложение.
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
Единственное, о чем стоит помнить: если ваше приложение не будет установлено, то выскочит диалог «открыть с помощью» и приложение злоумышленника сможет открыться.
Подробнее: http://ift.tt/1Peg9xn
Fingerprint API
Наконец-то в Android появилась нативная поддержка сенсоров отпечатков пальцев. Теперь с помощью класса android.hardware.fingerprint.FingerprintManager проверяем наличие в устройстве сенсора isHardwareDetected(), запрашиваем разрешение USE_FINGERPRINT, и если у пользователя есть откатанные пальчики hasEnrolledFingerprints(), показываем стандартный диалог авторизации по отпечатку authentificate().
Confirm Credentials
Теперь у нас есть возможность перепроверить, что сейчас устройство в руках у его владельца, показав экран разблокировки перед важным действием в приложении, например, при попытке открыть папку "/отдых в Адлере 2007/".
Text Selection
Теперь контекстное меню для действий с выделенным текстом появляется непосредственно рядом с кареткой, для добавления своих действий мы так же можем воспользоваться меню, описанным в menu.xml, и добавить его с помощью метода startActionMode(Callback, ActionMode.TYPE_FLOATING).
Direct share
Важным дополнением в Marshmallow является возможность добавлять одному приложению до восьми различных объектов в стандартный диалог шаринга:
Главное не захламить диалог бесполезными вариантами шаринга. Старайтесь не злоупотреблять.
Подробнее: http://ift.tt/1LUerxd
Пример: http://ift.tt/1Peg9NH
Voice Interaction
Важная, но не так подробно освещенная фишка, в отличии от «Now on tap» . Наше приложение, будучи запущенным из Google Now может вести диалог с пользователем с помощью класса android.app.VoiceInteractor.
Подробнее: http://ift.tt/1LUetFo.
На этом список не заканчивается. Более мелкие нововведения можно прочитать тут.
Обязательно пройдитесь по всем пунктам выше. Проверьте autobackup, doze mode и запросите все пермишены. На все вопросы буду рад ответить в комментариях.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий