Лидеры

Эмбаркадеро забыло включить в соответствующие Н файлы необходимые инструкции: _INIT_UNIT(Fmx_Pushnotification_Android); //для андроида _INIT_UNIT(Fmx_Pushnotification_Ios); //для ios Поэтому решением является вместо кода: #if defined(_ANDROID_) #include <FMX.PushNotification.Android.hpp> #endif #if defined(_APPLE) && (defined(arm) || defined(arm64_)) #include <FMX.PushNotification.IOS.hpp> #endif Написать код включения этих строк кода с учетом пространства имен: #if defined(__ANDROID__) #include <FMX.PushNotification.Android.hpp> namespace Fmx { namespace Pushnotification { namespace Android { _INIT_UNIT(Fmx_Pushnotification_Android); } } } #endif #if defined(_APPLE) && (defined(arm) || defined(arm64_)) #include <FMX.PushNotification.IOS.hpp> namespace Fmx { namespace Pushnotification { namespace Ios { _INIT_UNIT(Fmx_Pushnotification_Ios); } } } #endif Если бы Равиль не исследовал эту проблему, я бы не написала в тех.поддержку и билдер был бы в пролете с пушами...:)

это уже обсуждали, нужно заполнить расширенные настройки и добавить поле message, даже вроде в статье я об этом упомянул

Вы подменяете понятия. Озвученное - это (возможно) "самое разумное решение", если "надо сделать быстро, а дальше трава не расти" (вспоминаем картинку быстро-качественно-дорого), а никак не самое правильное. У индейцев есть как минимум одна плохая черта - они очень любят покушать ресурсы системы, особенно - посоздавать потоков. Посему система, построенная на тетеринге будет не очень масштабируемой в условиях интенсивного обмена. Небольшая ремарка - еще в первой версии появления нативных http компонентов официальные представители Embarcadero настоятельно стали рекомендовать отказаться от Indy. Самое правильное решение должно удовлетворять всем требованиям, предъявляемым к приложению, обладать хорошей способностью к модификации/устранению ошибок/надстраиваемостью функционала и быть легко масштабируемым. У тетеринга есть одно неоспоримое преимущество - это кроссплатформенность. В остальном правильность выбора его в качестве решения зависит от задачи.

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

>>Медленно работают эффекты на андроид << >> В моем проекте не используется эффектов << )) значит, вы жрете слишком много памяти. Мобильное приложение не десктоп и всегда требует оптимизации как вы можете на мелком экране показывать "огромное кол-во TImage" ??

Побуду в роли кэп'а ещё немного... Кто-то плохо изучил матчасть :http://docwiki.embarcadero.com/RADStudio/Berlin/en/Preparing_an_Android_Application_for_Deployment#Customizing_Your_AndroidManifest.xml_File (Ваш кэп) Вот вам данные по приложению, которое не требует ни одного разрешения но запиленное под версию Андроида 4.1 или более поздняя: Поддерживаемые устройства: 12439 Неподдерживаемые устройства: 2752 Проверяйте манифест, возможно там что-то лишнее есть... Сделайте Clean проекта и проверьте, как будут обстоять дела со списком устройств на маркете. Попробуйте запостить пустое приложение и посмотрите как там обстоят дела. Наблюдал в своих проектах и экспериментах, чем больше особенных разрешений (типа "связь", "GPS" и т.п.) требуется, тем меньше будет поддерживаемых устройств, что вполне логично... Но с необъяснимым ростом неподдерживаемых устройств не сталкивался. Нельзя исключать и глюк в Гугл плее. АП. Нашёл ссылку, которую хотел изначально дать: https://developer.android.com/google/play/filters.html?hl=ru p.s. Удачи в поисках проблемы

тыц: Как просмотреть и изменить список совместимых устройств, там смотрите, что написано в "Дополнительная информация". и ещё полезно будет Device Compatibility Если кратко, то проверяйте манифест.

Решение проблемы оказалось простое. Добавил всего две строчки кода и всё заработало. В OnUpdateObjects добавил ItemImage2.OwnsBitmap:=false; а после загрузки изображения ItemImage2.OwnsBitmap:=true;

В новой версии студии RAD Studio Berline, дизайнер стилей TStyleBook теперь показывает эти два свойства для каждого стилевого компонента. Таким образом открыв стиль в TStyleBook, вы можете сбросить значения этих свойств для снятия ограничений. Или же поменять их на свои. Без ручных правок текстового вида стиля.