Anatoliy

Дошло. Картинки я грузил из базы. Я неправильно их записывал в список TSkinImageList.
Использовал метод CreateFromBitmapAndMask()
вот так переделал
procedure AddPhoto(Image: TBlobStream; const sDescr: string = ''); Var pic: TDrawPicture; begin pic := TDrawPicture.CreateFromStream(Image); pic.Caption := sDescr; ImageList.PictureList.Add(pic); end; к сожалению, нет метода CreateFromBitmap()
 

А что значит сбросить? Я вместо 0 поставил, например, 200. Компонент стал весь 200х200. Но крутилка в центре не масштабируется.
 
P.S. Сорри, WrapMode = Stretch помогло

Он использует  фиксированный размер. Это зависит от стиля. В данном случае стиль для Андроида и йос именно фиксированного размера. Связано это прежде всего с тем, что эти стили растровые. Если вы хотите снять это ограничение, вы можете отредактировать дефолтный стиль и сбросить значения FixedWidth и FixedHeight.

Восстановили этй функцию.

Тогда TZNativeDrawFigureArc замените на TArc. Может на ваших целевых устройствах будет нормально отрисовываться.

Локализовать под разные языки не получится. Там эти строки заданы в виде констант. Я лично использую NativeView Равиля - и вид нативный и надписи можно любые вставлять во время выполнения приложения

В общем, оказалось, что "'CharInSet' is deprecated: 'Use TCharHelper functionality'"
Правильно вот так:
uses System.Character; ... ... for ch in s do if ch.IsInArray(['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']) then result := result + ch; или "IsDigit" если нужны только цифры for ch in s do if ch.IsDigit then result := result + ch; http://docwiki.embarcadero.com/Libraries/XE7/en/System.Character.IsDigit

За смену картинки пальцем отвечают несколько свойств.
SkinFMXImageListViewer1.Properties.CanGestureSwitch;
SkinFMXImageListViewer1.Properties.ImageListSwitchEffectType;
 
Программно:
ImageListViewer.Prop.SwitchNext;
ImageListViewer.Prop.SwitchPrior;
 
Вместо полного названия свойства Properties можно использовать сокращение Prop.

Спасибо большое, ваш пример дал реальную помощь, чутка допилил под C++

Насколько я понимаю, речь идет о том, какую версию Google Mobile Ads SDK вы используете. И манифест здесь ни при чем. Google Mobile Ads SDK сейчас является составной частью Google Play Services. И если вы регулярно обновляете SDK под Android, то все должно быть норм.
Если ни так, поправьте меня.

Если правильно понял, то вам необходимо использовать intent-filter.

Чтобы SkinFMXImageListViewer нормально вписывал картинку, нужно прикрутить TSkinImageListViewerDefaultMaterial и уже в этой компоненте настраивать.
Не обязательно использовать  отдельный TSkinImageListViewerDefaultMaterial, достаточно включить свойство MaterialUserKind := mukSelfOwn, при этом свойство SelfOwnMaterial будет заполнено автоматически своей компонентой, но на форме её не будет.
Думаю, что TSkinImageListViewerDefaultMaterial удобно использовать, если есть несколько SkinFMXImageListViewer, подключенных к единой компоненте TSkinImageListViewerDefaultMaterial.

Кстати вот еще отличная статья.
http://delphiworlds.com/2013/10/creating-ad-hoc-deployment-of-ios-apps-with-delphi-part-1/
http://delphiworlds.com/2013/10/creating-ad-hoc-deployments-of-ios-apps-with-delphi-part-2/

у нас в качестве сборщика - какой-то древний макмини.
До iOS11 напрягало, что симулятор для отладки запускается безумно медленно.
А как перешли на Токио + IOS11 - эта проблема перестала играть роль, поскольку симулятор теперь просто не работает . Радикальное такое решение проблемы :)))

Делать так:
TThread.Synchronize(TThread.CurrentThread, procedure begin Label1.Text:=Значение; end); А Label лучше заменить на TText

item.selectable := false

без привязки к платформе, т.к. он работает с апи yandex и google
а выводить можно куда захотите, я выводил на TMapView для мобильных, на Windows можно использовать какой-нить другой компонент

Можете мне сделать тестовый сервер и клиент, чтобы я смог у себя проверить? Тогда мой ответ будет более детальным. А пока:
Какой вы объем данных шлете по соединению? Чем вызвана потребность использовать именно сокеты? TimeOut  никогда не ставьте большими. Indy работает по принципу блокировки сокета и всего потока в целом. Поэтому большое значение = зависание всего приложения = нежелательные результаты и зависание. Я ставил 100 мс для работы с маленькими пакетами. С такой задержкой доп. поток не обязателен. Если значения более 500 мс - нужно создавать отдельный поток и работать с сокетами в ней + синхронизация при обработке / отправке данных. TIdTCPClient на Andoid любит спать и не проверять входящий буфер. Поэтому вручную нужно вызывать по таймеру проверку типа: procedure T<какое-то имя класа>.Read; var sz : integer; lMsg : string; begin try TMonitor.Enter(Self); try if not Assigned(Client.IOHandler) then Exit; //Client = TIdTCPClient if Client.IOHandler.InputBufferIsEmpty then begin if not Client.IOHandler.CheckForDataOnSource() then exit; end; sz := Client.IOHandler.InputBuffer.Size; if sz <= 0 then exit; lMsg := Client.IOHandler.InputBuffer.ExtractToString(-1, IndyTextEncoding_UTF8); Client.IOHandler.InputBuffer.Clear; <какой-то обработчик входящего сообщения>; except on e : Exception do <какой-то обработчик ошибки>; end; finally TMonitor.Exit(Self); end; end; AntiFreeze - это мягко говоря "костыль" от Indy, использование его плохая практика. На мобильной платформе вряд ли он появится, хотя и реализуется не сложно.

Компонент TMapsEngine
 
Возможности
Нативный LocationSensor [ANDROID] Геокодинг/Реверс геокодинг через Google API, Yandex API, Here Maps API Построение маршрута через Google Distance API Расчет дистанции по прямой Совместим со стандартным компонентом TLocationSensor  
Видео демонстрация
 
На видео видно как TMapView косячик с миллионом точек, приложение зависло при отрисовке, но с этим ничего не поделать.
Без синхронизации не возможно отрисовать все точки
 
Исходник
TMapsEngine_source.zip
TMapsEngine_Seattle_10.zip
 
Скачать APK  (долго он там не пролежит, а форум не позволяет загрузить zip размером 7,4 мб )
 

Текущая реализация не позволяет нам менять цвет статус бара, потому что в FMX используется старая тема Holo.
Поэтому устанавливается полупрозрачный цвет для нативного окна, и регулируется цвет статус бара с помощью установки цвета формы. 
Так достигается эффект покраски статус бара

Ознакомьтесь с информацией на страницах:
Android Devices Supported for Application Development (Berlin)
ABI Management - Supported ABIs

оставлю это здесь
 

Обрабатывать OnDblClick - это и есть изобретение своего велосипеда и выполнение того, что должен выполнять сам компонент. Все просто в простейших контролах типа кнопки, когда не предусмотрено ни какой другой логики кроме выполнения события. А вот для TSwitch не всё так однозначно, там поведение уже более сложное (можно его переключить сдвинув пальцем и это не будет кликом). В Grid совсем все сложно. Логика поведения навороченная и любая отсябятина её поломает с непредсказуемыми последствиями.
Клик произошёл. Так что выделена ячейка должна быть под точкой клика. А кто-то (и таких людей наберется не мало) может сказать, "по клику я хочу сам выделить ячейку ту, которую считаю нужной, а не ту на которую ткнул пользователь". Допустим в одном столбце картинка во втором значение и по клику на картинку я хочу выделить соседнюю ячейку с изменяемым параметром. Кроме того не факт, что под курсором оказалась "не задизабленая" ячейка, об этом должен не забыть подумать прикладной программист.
Скроллирование тут при том, нажатие и отпускание мыши (пальца) происходит примерно в рандомном месте (два раза). На нажатие-отпускание пальца реакция может быть разной, скроллирование может остановиться/замедлится/пойти в другую сторону, при долгом нажатии остановиться и выделиться ячейка.
OnCellDblClick ведь сериализировать нельзя на единый обработчик кликов. Так и да, сделать два обработчика вместо одного — воистину адская по сложности работа :o) Да и странно, что таблица реагирует на нажатие также как кнопка, хотя всякое бывает.

Если продолжить философские рассуждения,
то на контролах не должно было быть событий относящихся к аппаратным средствам. Потому, что на разных платформах может быть мышь, а может сенсорный экран что на первый взгляд похоже но не совсем одно и то же, а может быть и то и другое, кстати и в этом разобраться очень трудно. Должны быть события относящиеся именно к контролам, к примеру вместо OnClick на кнопкообразных контролах должно быть что-то типа OnExecute. Может кликнули мышью, может ткнули пальцем, может нажали пробел на клавиатуре, может сдвинули пальцем переключатель, может еще что угодно о чем нам знать не обязательно и за это отвечает контрол — но в итоге произошло нечто в результате чего мы должны выполнить некоторое действие.
Также и в Grid можно десятью способами реагировать на разные клики/жесты в разных местах на разных платформах (включая будущие). На сколько правильно остаётся на совести компонента. Прикладной программист обрабатывает события не вдаваясь в подробности о том, в результате каких манипуляций они произошли, но реализует логику работы о которой можно догадаться из названия или краткой справки. Например OnSelectCell - неважно что произошло в подлунном мире, но грид хочет знать можно ли выделить определенную ячейку. OnSelChanged - опять, ни кого не интересует каким образом это произошло, но выделенная ячейка поменялась. OnExecute - надо выполнить какое-то действие. OnAltExecute - надо выполнить какое-то альтернативное действие и т.п.
К сожалению изначально на эту тему не задумывались. Сохранили совместимость с виндовой VCL там, где этого не следовало делать. Зато поломали совместимость там где в этом не было серьезной необходимости
Caption -> Text;
Left, Top: Integer -> Position.X, Position.Y: Single;
Font.Color -> FontColor
А ведь если бы можно было VCL-ный dfm запустить на андроиде... не, это было бы конечно не так круто, как натянуть грид на грани вращающегося куба, но гораздо более востребовано на практике.