appbooster/appbooster-sdk-android

Mobile A/B-testing SDK

appbooster-sdk-android's Issues

Uncompatible okhttp versions

При попытке установить SDK вылетает ошибка:
java.lang.NoSuchMethodError: No virtual method toString(Z)Ljava/lang/String; in class Lokhttp3/Cookie; or its super classe

Согласно описанным решениям проблемы (1, 2) приложению не хватает установленного модуля, который был бы совместим с версией библиотеки okhttp3, используемой под капотом Android SDK. Как можно увидеть, Android SDK не устанавливает под капотом недостающую библиотеку com.squareup.okhttp3:okhttp-urlconnection:4.8.1 и приходится устанавливать ее вручную уже в самом приложении, чтобы указанная выше ошибка убралась.

Такая ошибка вылетает не во всех приложениях, а только в тех, которые используют у себя более старые версии библиотеки okhttp3- возникает несовместимость версий okhttp3 (версия в приложении и версия в SDK).

Считаю, что необходимо добавить указанную зависимость именно в код Android SDK, чтобы перезапись недостающей библиотеки на новую/совместимую версию шла именно со стороны Android SDK, а не со стороны приложения, использующего в проекте одновременно SDK и библиотеку okhttp3 более старых версий.

Считаю, что просить юзера самому дописывать эту строчку было бы не правильно, а правильнее было бы дописать ее под капот Android SDK самим, так как:

• недовольство юзеров и лишние обращения к нам с вопросом “как исправить”
• лишняя инфа в доке аля “если возникла ошибка”
• версия com.squareup.okhttp3:okhttp-urlconnection:4.8.1 может изменится, если будет решено в новых версиях Android SDK повысить версии библиотек, указанных в SDK в качестве dependencies. Юзеру в этом случае каждый раз придется менять у себя в проекте версию библиотеки com.squareup.okhttp3:okhttp-urlconnection и придется каждый раз дописывать доку о новой версии библиотеки com.squareup.okhttp3:okhttp-urlconnection, которую юзер должен установить в зависимости от версии Android SDK
• удобнее менять версию недостающей библиотеки самому, чем просить юзера сделать это путем описания доки и ответа на его вопросы о возникающей ошибке

Illegal sdk token size causes

В Sentry прилетела ошибка Illegal sdk token size causes (девайс Xiaomi Mi 5 с версией Android 8.0.0).
Согласно более подробной информации имеется следующая цепочка исключений:

AppboosterSetupException
Illegal sdk token size causes

UnknownClassException
Unable to find an implementation for interface io.jsonwebtoken.io.Serializer using java.util.ServiceLoader. Ensure you include a backing implementation .jar in the classpath, for example jjwt-impl.jar, or your own .jar for custom implementations.

UnavailableImplementationException
Unable to find an implementation for interface io.jsonwebtoken.io.Serializer using java.util.ServiceLoader. Ensure you include a backing implementation .jar in the classpath, for example jjwt-impl.jar, or your own .jar for custom implementations.

Быстрый гугл сказал, что дело в том, что необходимо использовать некий jackson (а в SDK, как я понял, используется orgjson.

Вот ссылки касательно этого самого jackson’а:
https://www.gitmemory.com/issue/jwtk/jjwt/573/719051256
jwtk/jjwt#578
jwtk/jjwt#447
jwtk/jjwt#573 (comment)

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

method `getExperiments` return wrong experiments values

При внедрении SDK в один из проектов выяснилось следующее:
Метод getExperiments всегда возвращает список экспериментов с их начальными значениями, определенными для юзера при установке приложения, вне зависимости от того, какое значение выставлено в debug-меню для того или иного эксперимента.
Однако при получении значения через обращение к конкретному эксперименту ab["<TEST_KEY>"] мы получаем значение эксперимента, выставленное в debug-меню (другими словами, мы получаем корректное значение).

Do not fetch all available options on app start

Сейчас SDK запрашивает все возможные значения экспериментов, если debug: true, даже если debug-экран не вызывался.

Может получится, что кто-то из наших клиентов забудет включить debug-режим и все их клиенты будут запрашивать все возможные значения для A/B-тестов при каждом запуске прилы - и для них лишний трафик, и для нас лишняя нагрузка.

Нужно запрашивать experiments/options только при вызове debug-экрана.