Major

Поправка: это самый верный способ для FMX, вне зависимости от платформы.
Емнип, у TCircle нет наследников. Ну и - для использования Release не обязательно приводить тип к истинному классу объекта.
Поэтому сей код можно записать так (не проверял в IDE, но если скомпилируется - значит всё нормально):
for k:=Layout1.ChildrenCount-1 downto 0 do if Layout1.Children[k] is TCircle then Layout1.Children[k].Release;  

As far as I know, это пока единственный способ (сам не пробовал). Буду рад узнать, если появились другие возможности.

Нет, не правильнее.
Объект может иметь ссылки не только в родителе (в списке его дочерних контролов), но и еще в куче мест, например - на которые он подписался (FreeNotification, к примеру) или на которые подписали его. Поэтому из родителя он исчезнет, Free - заNilит его текущую ссылку, но сам объект не удалится.
Ссылка не на ту статью. В другой статье Ярослав упоминал Самый Правильный Метод - это вызвать myObject.Release. Это гарантированно удалит все ссылки на объект, присутствующие во внутренностях FMX. Понятное дело, что если объект присутствует где-то в списках (или просто отдельной переменной) в коде, созданном вами, то нужно заNilить эти ссылки (и удалить из списков) самостоятельно.

var MyRect: TRectF; begin MyRect := RectF(10, 10, 30, 30); if Canvas.BeginScene then try Canvas.Fill.Color := TAlphaColorRec.Red; Canvas.Stroke.Color := TAlphaColorRec.Black; Canvas.FillEllipse(MyRect, 1); Canvas.DrawEllipse(MyRect, 1); finally Canvas.EndScene; end; end; FillEllipse - заливка
DrawEllipse - обводка

для заливки используется 
Canvas.Fill.Color := цвет; Canvas.FillEllipse();  

Так, ситуация такая. Приложение я отлаживал в Android Studio, не в RAD Studio, поэтому данную ошибку не встречал.
Если хочется запускать с отладчиком RAD, то закомментируйте строчку
Process._Release; Но, тогда будет происходить утечка памяти, которую можно будет увидеть в Android Studio и про которую я говорил в статье.
Ошибка появляется только во время дебага через RAD Studio. Во время обычной работы приложения всё нормально.
К сожалению, других решений для устранения утечки я не нашёл, а QC Embarcadero молчит...
Более подробно, про утечку расскажу в след. статье.
Исходники на гитхабе верные.
 
p.s. Тему почистил. Спасибо, что сообщили об этом поведении.
p.s.2. В статью добавил информацию по этому поводу.

Например, вот так:
Создаём фрейм
FFrmSettings := TfrmSettings.Create(Self); FFrmSettings.Parent := Parent; Уничтожаем фрейм
if FFrmSettings <> nil then begin FFrmSettings.Parent := nil; FFrmSettings.DisposeOf; FFrmSettings := nil; end;

Ссылка: http://delphifmandroid.blogspot.ru/2017/03/blog-post.html
Автор: Ефимов Андрей
Описание:

Major
Под Android, iOS, MacOS - TIniFile это все тот же TMemIniFile:
{$IFDEF MSWINDOWS}   { TIniFile - Encapsulates the Windows INI file interface (Get/SetPrivateProfileXXX functions) }   TIniFile = class(TCustomIniFile)   public     [...]   end; {$ELSE}   TIniFile = class(TMemIniFile)   public    [...]   end; {$ENDIF}

Это спорный момент. При написании мултиплатформенной программы, в Windows -  GetDocumentsPath вернет  c:\Users\<username>\Documents\ . Пользователь может удалить оттуда данные случайно - т.к. это папка "Мои документы".
Лучше TPath.GetHomePath\имя программы - напр. для Adobe в Windows это c:\Users\<username>\AppData\Roaming\Adobe\
Для андроида GetHomePath и GetDocumentsPath вернут одинаковый путь. В MacOS, iOS и Windows - это разные пути.
Здесь  описание всех путей.
+ Для андроида 
GetDocumentsPath; - /data/data/com.myapp.app1/files GetDownloadsPath; - /storage/emulated/0/Android/data/com.myapp.app1/files/Download GetHomePath; - /data/data/com.myapp.app1/files GetSharedDocumentsPath; - /storage/emulated/0/Android/data/com.myapp.app1/files GetLibraryPath; - /data/data/com.myapp.app1/files GetPublicPath; - /storage/emulated/0/Android/data/com.myapp.app1/files GetPicturesPath; - /storage/emulated/0/Android/data/com.myapp.app1/files/Pictures Ну и кто еще не в курсе - сохранять удобней всего в TMemIniFile из юнита IniFiles. Реестра в Unix системах нет (а это MacOS, iOS и Android), там все на файлах.

Вот сделал таблицу с событиями. Добавил в статью Очередь событий Delphi приложения на Android
И получилось, что отслеживать сворачивание можно по:
OnSaveState
aeWillBecomeInactive
EnteredBackground
Разворачивание:
WillBecomeForeground

Не совсем, если отслеживать все возможные варианты сворачивания приложения (включая выход из приложения), то лучше использовать:
TApplicationEvent.EnteredBackground
Для отслеживания разворачивания приложения достаточно:
TApplicationEvent.WillBecomeForeground
 
aeBecameActive и aeWillBecomeInactive отрабатывают только в определённых случаях.
 
p.s. Надо табличку оформить, чтобы было понятно, когда и для чего могут понадобится те или иные события.

Очередь событий Delphi приложения на Android Жизненный цикл мобильного приложения

https://community.embarcadero.com/blogs/entry/handling-ios-application-events-39450

ну вот, я вам ответил в предыдущем сообщении почему так происходит

TintColor не во всех стилях есть, в дефалтном на Windows точно нету.
на какой платформе тестите?

Посмотрите пример по вашей задаче:
C:\Users\Public\Documents\Embarcadero\Studio\18.0\Samples\Object Pascal\Multi-Device Samples\User Interface\Forms

мы в чатике провели небольшое расследование.
получилось что ресурсы на мобильных (на андроиде точно) сделаны для совместимости кода, т.к. даже если вы добавите в ресурсы файл, он все равно окажется в деплойменте
и доступ будет и через TResourceStream и по пути.
тест был такой
1) Новый проект
2) Project - Resources and Images
3) добавляем файл (camera_1x.png) 

 
 
 
 
 
 
 
 
 
 
4) компилируем на андроид устройство
5) проверяем оба варианта
procedure TForm1.Button1Click(Sender: TObject); var ResourceStream: TResourceStream; begin ResourceStream := TResourceStream.Create(hInstance, 'camera', RT_RCDATA); try ResourceStream.Position := 0; Image1.Bitmap.LoadFromStream(ResourceStream); finally FreeAndNil(ResourceStream); end; end; procedure TForm1.Button2Click(Sender: TObject); begin Image1.Bitmap.LoadFromFile(TPath.Combine (TPath.GetDocumentsPath, 'camera_1x.png')); end; в deployment'е наш файлик

из деплоймента вытаскивает файлы в нужные папки, не трогайте этот модуль

вообще имхо плохой вариант делать анимацию через поток и sleep
в данном случае я бы лучше наверное разделил анимацию на нужное кол-во ступеней и просто в таймере запускал их
смысл абсолютно тот же ибо доп. поток будет работать только на Sleep, все остальное все равно происходит в главном

Правило: Обращение к любому визуальному компоненту в потоке только через
TThread.Synchronize

А там что? Обращение к визуальным компонентам?

HitTest := true стоит?

Целый раздел с примерчиками: http://fire-monkey.ru/forum/130-json/