Rusland

Оказывается я уже оборачиваю в TThread.Synchronize(nil, procedure  

хмм, так?
THTTPClient.CookieManager.AddServerCookie();  

Приложение запустилось. Для iOS, в отличии от андроид оказалось, что надо добавить дополнительно свойство (TBeaconRegionCollection).

Оказывается я уже оборачиваю в TThread.Synchronize(nil, procedure  

ну желательно обернуть, т.к. это нативная штука. что там творится в недрах не видно. хуже не будет, но и не факт что поможет.

Это не из-за платформы. Обсуждали на форуме несколько раз уже эту проблему — проблема в том, что работа с UI и Action идет в разных потоках.
Получение снимка через Action Menu я делаю так
procedure TfmPhotos.TakePhotoFromCameraActionDidFinishTaking(Image: TBitmap); var ScaleFactor: Single; begin if System.Math.Max(Image.Width, Image.Height) > 1024 then begin ScaleFactor := System.Math.Max(Image.Width, Image.Height) / 1024; Image.Resize(Round(Image.Width / ScaleFactor), Round(Image.Height / ScaleFactor)); end; Image1.Bitmap.Assign(Image); end; Ну, т.е. так же, как и у тебя.
А... забыл сказать, что нужно вешать Action не на TSpeedButton, а на TButton. выглядят так же, только приложение не падает.
 

Может быть так? (правда код на Delphi)

У меня была похожая проблема. За Tplane с альфа каналом ничего не рисовалось (Сразу фон). Помогла смена материала с TLightMaterial на TTextureMaterial.

главное найти от куда плясать и все. а что ты хотел то? fmx это такой зверь которые надо пилить и пилить, не зря наши делали. это как и наши машины, купил а потом напильником подгоняй что бы работало 

Уже создавал тему по этому вопросу, надеялся, что в ХЕ8 рендеринг исправят, но нет. Кроме того, проблема обросла подробностями. 
Итак, та же моделька того же человечка в шлеме, собрана на TPlane'ах, код текстурирования тот же, всё так же не рендерится голова внутри. В тот раз проблема решилась случайно и я сам не понял, что же именно привело к решению. С тех пор форму старался не трогать, но рано или поздно дошёл и до неё черёд. И как результат, та же проблема - уже в ХЕ8.
 
Подробнее о том, как организована модель:
Viewport3D, внутри него лежит TDummy, в котором собрана TPlane'ами модель, а также камера, которая на это безобразие смотрит:

 
 
Теперь непосредственно к проблеме:
Смотрим на скрин:

 
По вайрфреймам можно понять, что боковые плоскости головы не рендерятся вообще (а не пропадает текстурка, как я полагал раньше).
Интересно, а что "внутри" шлема? Чтобы узнать, сделал возможность в рантайме, не закрывая программу, "снять" шлем (Visible для всех граней в False).
Смотрим:

 
Оп! Все грани на месте, всё отлично прорендерилось! А если снова "надеть" шлем?
Нет, надевание шлема привело всё к той же грустной картине на первом скрине - боковые плоскости просто отсеклись и упрямо не хотят рендериться...
 
Следующим шагом попробуем уменьшить прозрачность одной из плоскостей шлема и посмотреть сквозь неё на отсечённую плоскость головы:
 
 
Так точно, и полупрозрачность не заставляет включаться рендеринг "внутренних" граней.
 
А что будет, если поменять разрядность платформы? Выставим Win64/Debug и - о чудо! - рендеринг внезапно заработал!

 
 
И под конец экспериментов всплыл не такой страшный, но всё же назойливый баг, из-за которого иногда не прорисовываются те или иные графические элементы: к примеру, здесь не прорисовались текстуры модельки, иногда не прорисовываются некоторые превьюшки списка серверов, но это лечится обновлением битмапа.

 
 
Итак, что же мы узнали из этих исследований? Ровным счётом ничего. Рендеринг или, наоборот, нерендеринг не имеют никаких закономерностей.
 
Какими способами удалось повлиять на прорисовку этих поверхностей:
1) Изменение целевой платформы (Win32/Win64/Debug/Release) дают разный результат - практически всегда из четырёх комбинаций есть удачная, где всё рендерится
2) Изменение формы - добавление новых элементов или удаление существующих, помогает не всегда. На рабочей конфигурации может наоборот привести к отсечению граней
3) Изменение кода. ЛЮБОЕ. Даже никак не связанное с рендерингом. Достаточно воткнуть в произвольное место что-то типа Inc(Variable), чтобы рендеринг починился. Этого же, впрочем, достаточно и для того, чтобы рендеринг сломался.
 
Что НИКАК не влияет на рендеринг:
А не влияет всё то, что должно было бы повлиять, а именно:
1) Расстановка в любых мыслимых и немыслимых местах BeginUpdate'ов и EndUpdate'ов
2) Repaint'ы и Invalidate'ы всего и вся
3) Обновление текстур (грубо говоря, заливка модели новой текстурой)
4) Использование StyleBook'a
 
Исходя из вайрфреймов, нарисованных на каждой плоскости, мы видим, что не прорисовываются сами TPlane'ы. Могу предположить, что движок считает их невидимыми и отсекает как ненужные для оптимизации, но почему, в таком случае, рендерятся передняя и задняя плоскости головы?
 
Итак, вопрос - классика: кто виноват и что делать. Баг ли это в движке FMX, или же всё учтено и достаточно задать волшебную опцию, которая разом всё починит - я так и не узнал. Приветствуется любая помощь, а также хотелось бы раз и навсегда закрыть вопрос: в каких случаях нужно делать BeginUpdate/EndUpdate и влияет ли он на обработку отрисовки унаследованных объектов.

Удалось вытащить библиотеки, передав их через Bluetooth.
Проверил с ними - выходит ошибка: "Failed to load /data/data/com.embarcadero.Mikro/files/libcrypto.so."

Проверил. Да, действительно обрезается текст (не понял почему). Чтобы это не происходило, добавьте текста в Error.ini:
тогда ошибка будет видна полностью.
Пробовал разные версии libcrypto.so и libssl.so (из этой темы в частности). Всегда выдает либо "Failed to load /data/data/com.embarcadero.Mikro/files/libssl.so.", либо "Failed to load /data/data/com.embarcadero.Mikro/files/libcrypto.so.". Думаю, надо искать нужную версию библиотек под intel

Не поделитесь своим переводом обертки?

Так попробуйте и узнаете! Заодно и нам расскажите... Что мешает?
 
P.S.
А как с камерой работаете? Примерчиком не поделитесь?

Всем кто в сервис передает параметры, типа:
procedure TFrmMain.StartService(); var LIntent: JIntent; begin LIntent := TJIntent.Create; LIntent.setClassName(TAndroidHelper.Context.getPackageName(), TAndroidHelper.StringToJString('com.embarcadero.services.TestRemoteServ')); LIntent.setAction(StringToJString('StartService')); TAndroidHelper.Activity.startService(LIntent); end; function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin if Intent.getAction.equalsIgnoreCase(StringToJString('StopService')) then begin Log('START_NOT_STICKY'); Result := TJService.JavaClass.START_NOT_STICKY; end else // if Intent.getAction.equalsIgnoreCase(StringToJString('StartService')) then begin Log('START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; end; обязательно проверяйте Intent на nil !
Когда система убивает ваше приложение из-за нехватки памяти и перезапускает сервис, то на Intent.getAction происходит Segmentation fault и сервис остается в подвешенном состоянии (на процессоре ARM в Приложения - Работающие у меня отображается как-будто сервис нормально перезапустился, а вот на процессоре Intel - видно как сервис находится в вечном перезапуске). И естественно хост-приложение не может нормально стартануть.
Делаем примерно так:
function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin if Intent<>nil then begin if Intent.getAction.equalsIgnoreCase(StringToJString('StopService')) then begin Log('START_NOT_STICKY'); Result := TJService.JavaClass.START_NOT_STICKY; end else // if Intent.getAction.equalsIgnoreCase(StringToJString('StartService')) then begin Log('START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; end else begin Log('RESTART BY SYSTEM'); Result := TJService.JavaClass.START_STICKY; end; end;  

Посмотрите DeviceInfo от ZuBy

Ты молодец!
На эту проблему потрачено неимоверно много времени, и не мной одним.
В итоге, действительно проблема решилась.
Всегда молодым программистам по 100 раз говорю — Проверяйте объекты на NULL! Простое условие "if not Assigned(Object)" сэкономит кучу времени. — и сам же в это болото залез.
 

Всем кто в сервис передает параметры, типа:
procedure TFrmMain.StartService(); var LIntent: JIntent; begin LIntent := TJIntent.Create; LIntent.setClassName(TAndroidHelper.Context.getPackageName(), TAndroidHelper.StringToJString('com.embarcadero.services.TestRemoteServ')); LIntent.setAction(StringToJString('StartService')); TAndroidHelper.Activity.startService(LIntent); end; function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin if Intent.getAction.equalsIgnoreCase(StringToJString('StopService')) then begin Log('START_NOT_STICKY'); Result := TJService.JavaClass.START_NOT_STICKY; end else // if Intent.getAction.equalsIgnoreCase(StringToJString('StartService')) then begin Log('START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; end; обязательно проверяйте Intent на nil !
Когда система убивает ваше приложение из-за нехватки памяти и перезапускает сервис, то на Intent.getAction происходит Segmentation fault и сервис остается в подвешенном состоянии (на процессоре ARM в Приложения - Работающие у меня отображается как-будто сервис нормально перезапустился, а вот на процессоре Intel - видно как сервис находится в вечном перезапуске). И естественно хост-приложение не может нормально стартануть.
Делаем примерно так:
function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin if Intent<>nil then begin if Intent.getAction.equalsIgnoreCase(StringToJString('StopService')) then begin Log('START_NOT_STICKY'); Result := TJService.JavaClass.START_NOT_STICKY; end else // if Intent.getAction.equalsIgnoreCase(StringToJString('StartService')) then begin Log('START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; end else begin Log('RESTART BY SYSTEM'); Result := TJService.JavaClass.START_STICKY; end; end;  

Всем кто в сервис передает параметры, типа:
procedure TFrmMain.StartService(); var LIntent: JIntent; begin LIntent := TJIntent.Create; LIntent.setClassName(TAndroidHelper.Context.getPackageName(), TAndroidHelper.StringToJString('com.embarcadero.services.TestRemoteServ')); LIntent.setAction(StringToJString('StartService')); TAndroidHelper.Activity.startService(LIntent); end; function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin if Intent.getAction.equalsIgnoreCase(StringToJString('StopService')) then begin Log('START_NOT_STICKY'); Result := TJService.JavaClass.START_NOT_STICKY; end else // if Intent.getAction.equalsIgnoreCase(StringToJString('StartService')) then begin Log('START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; end; обязательно проверяйте Intent на nil !
Когда система убивает ваше приложение из-за нехватки памяти и перезапускает сервис, то на Intent.getAction происходит Segmentation fault и сервис остается в подвешенном состоянии (на процессоре ARM в Приложения - Работающие у меня отображается как-будто сервис нормально перезапустился, а вот на процессоре Intel - видно как сервис находится в вечном перезапуске). И естественно хост-приложение не может нормально стартануть.
Делаем примерно так:
function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin if Intent<>nil then begin if Intent.getAction.equalsIgnoreCase(StringToJString('StopService')) then begin Log('START_NOT_STICKY'); Result := TJService.JavaClass.START_NOT_STICKY; end else // if Intent.getAction.equalsIgnoreCase(StringToJString('StartService')) then begin Log('START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; end else begin Log('RESTART BY SYSTEM'); Result := TJService.JavaClass.START_STICKY; end; end;  

Всем кто в сервис передает параметры, типа:
procedure TFrmMain.StartService(); var LIntent: JIntent; begin LIntent := TJIntent.Create; LIntent.setClassName(TAndroidHelper.Context.getPackageName(), TAndroidHelper.StringToJString('com.embarcadero.services.TestRemoteServ')); LIntent.setAction(StringToJString('StartService')); TAndroidHelper.Activity.startService(LIntent); end; function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin if Intent.getAction.equalsIgnoreCase(StringToJString('StopService')) then begin Log('START_NOT_STICKY'); Result := TJService.JavaClass.START_NOT_STICKY; end else // if Intent.getAction.equalsIgnoreCase(StringToJString('StartService')) then begin Log('START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; end; обязательно проверяйте Intent на nil !
Когда система убивает ваше приложение из-за нехватки памяти и перезапускает сервис, то на Intent.getAction происходит Segmentation fault и сервис остается в подвешенном состоянии (на процессоре ARM в Приложения - Работающие у меня отображается как-будто сервис нормально перезапустился, а вот на процессоре Intel - видно как сервис находится в вечном перезапуске). И естественно хост-приложение не может нормально стартануть.
Делаем примерно так:
function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin if Intent<>nil then begin if Intent.getAction.equalsIgnoreCase(StringToJString('StopService')) then begin Log('START_NOT_STICKY'); Result := TJService.JavaClass.START_NOT_STICKY; end else // if Intent.getAction.equalsIgnoreCase(StringToJString('StartService')) then begin Log('START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; end else begin Log('RESTART BY SYSTEM'); Result := TJService.JavaClass.START_STICKY; end; end;  

Всем кто в сервис передает параметры, типа:
procedure TFrmMain.StartService(); var LIntent: JIntent; begin LIntent := TJIntent.Create; LIntent.setClassName(TAndroidHelper.Context.getPackageName(), TAndroidHelper.StringToJString('com.embarcadero.services.TestRemoteServ')); LIntent.setAction(StringToJString('StartService')); TAndroidHelper.Activity.startService(LIntent); end; function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin if Intent.getAction.equalsIgnoreCase(StringToJString('StopService')) then begin Log('START_NOT_STICKY'); Result := TJService.JavaClass.START_NOT_STICKY; end else // if Intent.getAction.equalsIgnoreCase(StringToJString('StartService')) then begin Log('START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; end; обязательно проверяйте Intent на nil !
Когда система убивает ваше приложение из-за нехватки памяти и перезапускает сервис, то на Intent.getAction происходит Segmentation fault и сервис остается в подвешенном состоянии (на процессоре ARM в Приложения - Работающие у меня отображается как-будто сервис нормально перезапустился, а вот на процессоре Intel - видно как сервис находится в вечном перезапуске). И естественно хост-приложение не может нормально стартануть.
Делаем примерно так:
function TDM.AndroidServiceStartCommand(const Sender: TObject; const Intent: JIntent; Flags, StartId: Integer): Integer; begin if Intent<>nil then begin if Intent.getAction.equalsIgnoreCase(StringToJString('StopService')) then begin Log('START_NOT_STICKY'); Result := TJService.JavaClass.START_NOT_STICKY; end else // if Intent.getAction.equalsIgnoreCase(StringToJString('StartService')) then begin Log('START_STICKY'); Result := TJService.JavaClass.START_STICKY; end; end else begin Log('RESTART BY SYSTEM'); Result := TJService.JavaClass.START_STICKY; end; end;  

String fn; String path = System::Ioutils::TPath::GetSharedDownloadsPath(); #ifdef __ANDROID__ TSearchRec sr; if ( !FindFirst( path + "/*", faAnyFile, sr) ) { do { if ( sr.Name=="." || sr.Name==".." ) {} else if ( (sr.Attr & faDirectory) == faDirectory ) {} // dir else {} // file // отрисовать в список sr.Name sr.Name; } while ( !FindNext(sr) ); FindClose(sr); // по клику в списке получить fn = path + "/" + name; } #else OpenDialog->InitialDir = System::Ioutils::TPath::GetSharedDocumentsPath(); if ( !OpenDialog->Execute() ) return; fn = OpenDialog->FileName; #endif вот так сделал, кому понадобится, на паскале тоже работает, только синтаксис другой

Может быть так? (правда код на Delphi)

Может быть так? (правда код на Delphi)

Может быть так? (правда код на Delphi)