Android all talking about

Краткое описание:
Набор приложений для людей с ограниченными возможностями

Описание:
Специальные возможности для Android – это набор приложений для людей с ограниченными возможностями. Он позволяет управлять устройством Android, не глядя на экран (с помощью кнопок или внешнего пульта).

В Специальные возможности для Android входят следующие компоненты:

Меню специальных возможностей – большое экранное меню, позволяющее блокировать телефон, регулировать громкость и яркость, делать скриншоты и не только.
Функция «Озвучивание при нажатии», с помощью которой можно прослушивать название или описание объектов на экране или в фокусе камеры.
Функция Switch Access, которая позволяет управлять устройством Android с помощью внешних пультов или клавиатуры.
Программа чтения с экрана TalkBack, которая озвучивает текст и элементы интерфейса, а также обеспечивает звуковой и виброотклик.

Что нового в версии 8.1 Специальных возможностей для Android

Важно! Для установки этого обновления требуется Android 6 или более поздней версии. Как определить версию Android: https://support.google.com/android/answer/7680439.

Обновления в версии 8.1:

Улучшены подсказки об использовании TalkBack для локального контекстного меню.
Улучшен дизайн функции «Озвучивание при нажатии» для устройств с узким экраном.
Улучшена поддержка тёмной темы функцией «Озвучивание при нажатии» на устройствах с Android 10.
Удалены настройки TalkBack для функций «Изучение касанием», «Автопрокрутка списков», «Встряхнуть, чтобы начать чтение», «Перемещение фокуса между экранами», «Отключить подсветку экрана» и жесты для функции «Постукивание по краю».
Добавлены другие исправления и улучшения.

Узнайте больше об использовании Специальных возможностей для Android и других функций для людей с ограниченными возможностями: http://g.co/help/androidaccessibility.

Чтобы начать использовать набор приложений, выполните следующие действия:

Откройте настройки устройства.
Выберите «Спец. возможности».
Включите меню специальных возможностей, «Озвучивание при нажатии», функцию Switch Access или TalkBack.

Управление разрешениями

Телефон. Приложение «Специальные возможности для Android» следит за состоянием телефона и может адаптировать подсказки в зависимости от статуса вызова.
Сервис специальных возможностей. В связи со спецификой работы приложения оно отслеживает ваши действия. Кроме того, ему доступно содержимое окна и текст, который вы набираете.

Для того чтобы говорила по-русски, можно установить голосовой движок от svox.

Требуется Андроид:
4.1 — до версии 5.0.7 включительно
5.0 — до 7.3.0.238058557
6.0 — с 7.3.0.239841594
Русский интерфейс: Да

Версия: 8.2.0.303936097 (6.0+) от 10/04/2020 (iMiKED)
Версия: 8.1.0.278818032 (6.0+) от 21/11/2019 (iMiKED)
версия: 8.0.0.247812625 из GP для 6.0+ Android Accessibility Suite (TalkBack) (Пост And_RU #86000330)
версия: 7.3.0.238058557 из GP для 5.0+ Android Accessibility Suite (TalkBack) (Пост And_RU #83355417)
версия: 5.2.0 build 50200023 (5.0+) Google TalkBack (Пост iMiKED #60857530)
версия: 4.4.1 х86 Google TalkBack (Пост bulat42 #47191530)
версия: 7.3.0.239841594 (6.0+,GP)Android Accessibility Suite
версия: 7.2.0.220693075 (GP) Android Accessibility Suite (TalkBack) (Пост dmtrdvdnk #79222909)
версия: 6.2.0.199837370 Сообщение №242, автор utf8
версия: 6.1.0.186797687 Google TalkBack (Пост And_RU #70695812)
Версия: 6.1.0.173161073 Google TalkBack (Пост igor2969 #66332668)
версия: 6.0.0 Google TalkBack (Пост igor2969 #62060702)
версия: 5.0.7 Google TalkBack (Пост iMiKED #55043994)
версия: 5.2.0 (5.0+) Google TalkBack (Пост iMiKED #59726640)
версия: 5.1.0 (5.0+) Google TalkBack (Пост Displax #55850160)
версия: 5.0.4 Google TalkBack (Пост CyberEgo #51979741)
версия: 4.5.1 Google TalkBack (Пост Ansaros #50504812)
Версия: 4.5.0 Google TalkBack (Пост Ansaros #49204592)
версия: 4.4.1 Google TalkBack (Пост Ansaros #46514402)
версия: 4.4.0 Beta 3 Google TalkBack (Пост VLADFIONOV #45156085)
версия: 4.4.0 Beta 2 Google TalkBack (Пост Alex0047 #44683656)
версия: 4.3.1 Google TalkBack (Пост Viktor245 #43481660)
версия: 4.3.1 beta 2 Google TalkBack (Пост Alex0047 #43135233)
версия: 4.3.1 beta Google TalkBack (Пост petya-hacker #42737034)
версия: 4.3.0-40300000 Google TalkBack (Пост petya-hacker #42523500)
версия: 4.2.0 (40200008) Google TalkBack (Пост #37768539)
версия: 4.2.0 Final Google TalkBack (Пост Alex0047 #40109917)
версия: 4.2.0 beta2 Google TalkBack (Пост petya-hacker #40031954)
версия: 4.2.0 beta1 Google TalkBack (Пост Alex0047 #39626549)
версия: 3.6.0 Google TalkBack (Пост #36972268)
версия: 3.5.2 Talkback (Пост #34330082)
версия: 3.5.1 Talkback (Пост #27855401)
версия: 3.5.0 https://4pda.to/forum/dl/post/3593014/TalkBack_3.5.0.apk
версия: 3.4.0 https://4pda.to/forum/dl/post/3216931/TalkBack_3.4.0.apk
версия: 3.3.2 Talkback (Пост #22110738)
версия: 3.3.1 https://4pda.to/forum/dl/post/2835363/com.google.android.marvin.talkback.apk
версия: 3.3.0 https://4pda.to/forum/dl/post/2651165/TalkBack_3.3.0.apk
версия: 3.2.1 https://4pda.to/forum/dl/post/2257410/TalkBack_3.2.1.apk
версия: 3.1.3 https://4pda.to/forum/dl/post/2159284/TalkBack_3.1.3.apk
версия: 2.7.9 https://4pda.to/forum/dl/post/1570659/TalkBack_v2.7.9.apk
версия: 2.7.7 https://4pda.to/forum/dl/post/1077651/com.google.android.marvin.talkback_2.7.7.apk
версия: 2.6.0 com.google.android.marvin.talkback.apk ( 131.84 КБ )

Сообщение отредактировал iMiKED — 05.10.21, 05:07

Источник

Android Accessibility — Resolving common Talkback issues

Many Android applications suffer from similar Talkback issues and at Microsoft To Do we run into these often as well. We use multiple strategies to make our app more accessible. This article covers a few scenarios where Talkback experience is improved.

A companion Github repository containing the sample code is available here. You can check it out and try running the demo app on your device to experience the issues and try the solutions yourself.

Combining views into groups

Not everything visible on the screen is meaningful; some views are used only for decoration, some images illustrate the text without adding additional information, and sometimes multiple views convey the meaning together but do not make sense separately. In these cases, the views can be combined to allow Talkback user to quickly navigate entire view, rather than having to skip through multiple different elements.

Example

Talkback reads the user element on the page as “User placeholder avatar”, “Name”, and then “Surname”. Each element can be navigated individually. The user icon is a placeholder which does not provide additional information. It takes three swipes to navigate through the element.

Solution

Content description is set on the entire group so Talkback reads only one label, containing all user information as “Name Surname”. Now navigation is done in only one swipe.

XML layout snippet

Content description is set on LinearLayout, child views are marked as not important for accessibility individually.

Action descriptions

As Talkback navigates the elements with click actions, the announcement generated will include some information, for example “Login, Button, Double tap to activate”. However, relying on default announcements is not always enough.

Example

A button with two actions generates an accessibility announcement of “Edit note, Double tap to activate, Double tap and hold to long press”.

Solution

Actions are modified to announce “Double tap to edit note, Double tap and hold to copy note”.

Code snippet

Custom actions are added in accessibility delegate, ensuring that it’s clear what happens when each action is carried out.

Roles

Talkback reads the element roles, such as Button, Switch, Checkbox, etc. This gets complicated when non-standard elements are used. For example, adding a click listener will add an action to Talkback announcement, but the role will generally not change, potentially causing confusion.

Example

The button is announced as “Login, Button”. Adding on a click listener to TextView does not include the “Button” announcement. In the last example, TextView is announced as “Button”.

Code snippet

Role is added by including it in the accessibility delegate. This is not an ideal solution; best practice is to use elements as intended, so using Button when Button behaviour is needed, which avoids the need to modify roles manually, as it is easy to miss some behaviour which comes by default. However, in some cases, this will help.

Updating information after state changes

Lint warning often reminds us about adding initial content descriptions, but for the elements with states, this might not be enough. It is important to remember to update accessibility information as well.

Example

The favorite button is not updated after the user taps on it, so the Talkback announcement still reads “Not favorite item, Button, Double tap to activate” after the user already added the item to favorites and the UI is updated to reflect this.

Solution

Favorite button content and action descriptions are updated so Talkback reads one of two states: “Not favorite item, Button, Double tap to add to favorites” and “Favorite item, Button, Double-tap to remove from favorites”.

Code snippet

When a tap event is received and the element state changes, the content and action descriptions are updated to reflect the current state of the item. This is especially important for elements which represent On/Off state, like the favorite button. Alternatively, an element which already supports On/Off states could be used in this scenario, like Switch or Checkbox. On the other hand, if more than two states are available, then custom elements make sense.

RecyclerView scrolling

If RecyclerView does not automatically scroll with Talkback navigation, it will make it very hard for Talkback users to know that there are more elements available. There is one common issue which usually causes this.

Example

The first RecyclerView allows user to see the first 5 elements and then navigation skips the rest. The second RecyclerView moves to the 6th element in the list and scrolls down to make additional elements available. The focus only moves away from RecyclerView when all elements are visited.

Layout snippet

If the following line is in the RecyclerView layout, removing it will fix the issue. It will also add additional in/out of list announcements to help the users navigate.

RecyclerView focus

As is the nature of RecyclerView, it can recycle the view holders if there are changes to the data. However, this can create focus issues if some view is no longer displayed or the view holder is reused in a different position. Understanding what is happening will help with keeping the focus unchanged.

Example

RecyclerViews allow the user to mark elements as deleted. In the first RecyclerView, once the delete icon is tapped and the element text is replaced with “Deleted ”, the focus returns to the top of the activity, so the user needs to navigate through the entire screen again to return to the original focus position. The second RecyclerView keeps the focus on the same element, shifting it from the icon to the name.

Code snippet

After the element is marked as deleted there is a short delay to allow RecyclerView time to reuse ViewHolders, then the desired position is found and focus is returned to that position. If the underlying data set is not changed and there is no refresh of the data in RecyclerView adapter, this could potentially be solved within ViewHolder itself. As always, the best solution is the one which addresses the specific need.

Conclusions

Accessibility is important for our team at Microsoft To Do. We spend a lot of time making sure every user can stay organised and accomplish more, independent of how they use their device. Most of our Android app releases include several accessibility improvements. We also work with our design team to consider accessibility requirements from the start.

Accessibility issues we encounter range from simple to tricky — it takes time and dedication to find and resolve them all. I hope this article helps you to solve some. Code snippets in the article have been simplified for clarity, so check the sample code for full implementations.

Is there a different way you would approach some of these? Let’s discuss it!

Источник

All About PendingIntents

PendingIntent s are an important part of the Android framework, but most of the available developer resources focus on their implementation details — a “reference to a token maintained by the system” — rather than their usage.

Since Android 12 includes important changes to pending intents, including a change that requires explicitly deciding when a PendingIntent is mutable or immutable, I thought it would be helpful to talk more what pending intents do, how the system uses them, and why you might occasionally want a mutable PendingIntent .

What is a PendingIntent?

A PendingIntent object wraps the functionality of an Intent object while allowing your app to specify something that another app should do, on your app’s behalf, in response to a future action. For example, the wrapped intent might be invoked when an alarm goes off, or when the user taps on a notification.

A key aspect of pending intents is that another app invokes the intent on your app’s behalf. That is, the other app uses your app’s identity when invoking the intent.

In order for the PendingIntent to have the same behavior as if it were a normal Intent , the system triggers the PendingIntent with the same identity as it was created with. In most situations, such as the alarm and notifications, this is the identity of the app itself.

Let’s take a look at the different ways our apps can work with PendingIntent s and why we might want to use them in these ways.

Common case

The most common, and most basic, way to use a PendingIntent is as the action associated with a notification:

We can see that we’re constructing a standard type of Intent that will open our app, and then simply wrapping that in a PendingIntent before adding it to our notification.

In this case, since we have an exact action we know we want to perform, we construct a PendingIntent that cannot be modified by the app we pass it to by utilizing a flag called FLAG_IMMUTABLE .

After we call NotificationManagerCompat.notify() we’re done. The system will display the notification, and, when the user clicks on it, call PendingIntent.send() on our PendingIntent , starting our app.

Updating an immutable PendingIntent

You might think that if an app needs to update a PendingIntent that it needs to be mutable, but that’s not always the case! The app that creates a PendingIntent can always update it by passing the flag FLAG_UPDATE_CURRENT :

We’ll talk about why one may want to make a PendingIntent mutable in a bit.

Inter-app APIs

The common case isn’t only useful for interacting with the system. While it is most common to use startActivityForResult() and onActivityResult() to receive a callback after performing an action, it’s not the only way.

Imagine an online ordering app that provides an API to allow apps to integrate with it. It might accept a PendingIntent as an extra of its own Intent that’s used to start the process of ordering food. The order app only starts the PendingIntent once the order has been delivered.

In this case the ordering app uses a PendingIntent rather than sending an activity result because it could take a significant amount of time for the order to be delivered, and it doesn’t make sense to force the user to wait while this is happening.

We want to create an immutable PendingIntent because we don’t want the online ordering app to change anything about our Intent . We just want them to send it, exactly as it is, when the order’s arrived.

Mutable PendingIntents

But what if we were the developers for the ordering app, and we wanted to add a feature that would allow the user to type a message that would be sent back to the app that called it? Perhaps to allow the calling app to show something like, “It’s PIZZA TIME!”

The answer to this is to use a mutable PendingIntent .

Since a PendingIntent is essentially a wrapper around an Intent , one might think that there would be a method called PendingIntent.getIntent() that one could call to get and update the wrapped Intent , but that’s not the case. So how does it work?

In addition to the send() method on PendingIntent that doesn’t take any parameters, there are a few other versions, including this version, which accepts an Intent :

This intent parameter doesn’t replace the Intent that’s contained in the PendingIntent , but rather it is used to fill in parameters from the wrapped Intent that weren’t provided when the PendingIntent was created.

Let’s look at an example.

This PendingIntent could be handed over to our online order app. After the delivery is completed, the order app could take a customerMessage and send that back as an intent extra like this:

The calling app will then see the extra EXTRA_CUSTOMER_MESSAGE in its Intent and be able to display the message.

Important considerations when declaring pending intent mutability

⚠️ When creating a mutable PendingIntent ALWAYS explicitly set the component that will be started in the Intent . This can be done the way we’ve done it above, by explicitly setting the exact class that will receive it, but it can also be done by calling Intent.setComponent() .

Your app might have a use case where it seems easier to call Intent.setPackage() . Be very careful of the possibility to match multiple components if you do this. It’s better to specify a specific component to receive the Intent if at all possible.

⚠️ If you attempt to override the values in a PendingIntent that was created with FLAG_IMMUTABLE will fail silently, delivering the original wrapped Intent unmodified.

Remember that an app can always update its own PendingIntent , even when they are immutable. The only reason to make a PendingIntent mutable is if another app has to be able to update the wrapped Intent in some way.

Details on flags

We’ve talked a bit about a few of the flags that can be used when creating a PendingIntent , but there are a few others to cover as well.

FLAG_IMMUTABLE : Indicates the Intent inside the PendingIntent cannot be modified by other apps that pass an Intent to PendingIntent.send() . An app can always use FLAG_UPDATE_CURRENT to modify its own PendingIntents

Prior to Android 12, a PendingIntent created without this flag was mutable by default.

⚠️ On Android versions prior to Android 6 (API 23), PendingIntent s are always mutable.

🆕 FLAG_MUTABLE : Indicates the Intent inside the PendingIntent should allow its contents to be updated by an app by merging values from the intent parameter of PendingIntent.send() .

⚠️ Always fill in the ComponentName of the wrapped Intent of any PendingIntent that is mutable. Failing to do so can lead to security vulnerabilities!

This flag was added in Android 12. Prior to Android 12, any PendingIntent s created without the FLAG_IMMUTABLE flag were implicitly mutable.

FLAG_UPDATE_CURRENT : Requests that the system update the existing PendingIntent with the new extra data, rather than storing a new PendingIntent . If the PendingIntent isn’t registered, then this one will be.

FLAG_ONE_SHOT : Only allows the PendingIntent to be sent once (via PendingIntent.send() ). This can be important when passing a PendingIntent to another app if the Intent inside it should only be able to be sent a single time. This may be related to convenience, or to prevent the app from performing some action multiple times.

🔐 Utilizing FLAG_ONE_SHOT prevents issues such as “replay attacks”.

FLAG_CANCEL_CURRENT : Cancels an existing PendingIntent , if one exists, before registering this new one. This can be important if a particular PendingIntent was sent to one app, and you’d like to send it to a different app, potentially updating the data. By using FLAG_CANCEL_CURRENT , the first app would no longer be able to call send on it, but the second app would be.

Receiving PendingIntents

Sometimes the system or other frameworks will provide a PendingIntent as a return from an API call. One example is the method MediaStore.createWriteRequest() that was added in Android 11.

Just as a PendingIntent created by our app is run with our app’s identity, a PendingIntent created by the system is run with the system’s identity. In the case of this API, this allows our app to start an Activity that can grant write permission to a collection of Uri s to our app.

Summary

We’ve talked about how a PendingIntent can be thought of as a wrapper around an Intent that allows the system, or another app, to start an Intent that one app created, as that app, at some time in the future.

We also talked about how a PendingIntent s should usually be immutable and that doing so doesn’t prevent the app from updating its own PendingIntent objects. The way it can do so is by using the FLAG_UPDATE_CURRENT flag in addition to FLAG_IMMUTABLE .

We’ve also talked about the precautions we should make — ensuring to fill in the ComponentName of the wrapped Intent — if a PendingIntent is necessary to be mutable.

Finally, we talked about how sometimes the system, or frameworks, may provide PendingIntent s to our app so that we can decide how and when to run them.

Updates to PendingIntent were just one of the features in Android 12 designed to improve app security. Read about all the changes in the preview here.

Want to do even more? We encourage you to test your apps on the new developer preview of the OS and provide us feedback on your experiences!

Источник