delphi XE7 firemonkey Android совместно используемый объект / библиотека для динамической загрузки - шаблон

Question

delphi XE7 firemonkey Android совместно используемый объект / библиотека для динамической загрузки - шаблон

1

Есть ли шаблон для создания файла.so, который может быть загружен другим файлом delphi ape - я попытался запустить проект пустой обезьяны огня и сменить программу на библиотеку и создать ее, но файл.so, который он создает, не будет загружаться с помощью dlopen в рамках другого проекта delphi. Я прочитал, что в других средах разработки есть параметр islibrary. Я догадываюсь, что более важно то, что есть пример.so библиотека, построенная с огненной обезьяной - я нашел ссылку на голые кости без обезьяны огня, но использует только jni not androidapi.jni - спасибо

shakaworld 17 нояб. 2014, в 15:21

Источник

Теги:

android

object

templates

delphi

shared

2 ответа

2

Если вы запустите пустой проект Firemonkey и измените Unit на Library, вы получите эту ошибку компилятора:

[DCC Error] myfunnylib.pas(1): E2029 "UNIT" ожидается, но "БИБЛИОТЕКА" найдена

Попытка добавить существующий проект библиотеки к группе проектов будет отделять этот проект от остальной части сборки и назначать ей уникальные цели сборки и платформы. Который оставит вас с настройками для компиляции для Windows и OS X.

Единственный способ, о котором я до сих пор слышал, - предварительно скомпилировать вашу библиотеку с другим компилятором. FPC упоминается в другом месте. Я еще не пробовал это, но его следующий в списке.

http://wiki.freepascal.org/Android

Не смущайтесь тем фактом, что каждое приложение для Android на самом деле является общим объектом с расширением .so (для общего объекта). Однако это не то же самое, что разделяемая библиотека. Поскольку библиотека экспортирует свои функции, пока приложение не работает. Для компилятора это довольно большая разница, хотя вы не увидите этого, посмотрев расширение файла (но его префикс lib вместо этого).

Если вы ограничите свой вопрос XE и Firemonkey, мое единственное предложение здесь - посмотреть на службы Android. Связанная локальная служба может предложить аналогичные возможности, которые вы ожидаете от библиотеки:

http://docwiki.embarcadero.com/RADStudio/Seattle/en/Android_Service

Также важно отметить, что Android N не позволит динамической компоновке больше, поэтому многие из методов, которые вы найдете в другом месте в качестве решения, не будут работать.

Пример кода suat dmk в ответе ниже, хотя и опротестован, вводит в заблуждение.
Он не может быть скомпилирован для Android или iOS в XE 10.1 или любом из его предшественников.

ОБНОВИТЬ:
Там определенное выражение сотрудников Embarcadero по этому вопросу.
Для объяснения вопроса потребовалось немного терпения, но ответ достаточно ясен:

[..] хочет, чтобы у Delphi был тип проекта общей библиотеки (.so),
в этом случае он прав, у Дельфи это не сейчас. [..]

quod erat demonstrandum

Следовательно, такого шаблона не может быть. Также отвечает на этот вопрос.

souldealer_B317 16 сен. 2016, в 17:15

0

Последняя сборка FPC (3.1.1) поддерживает компиляцию библиотеки для Android с небольшими ограничениями: wiki.freepascal.org/Android#Building_cross_compiler
souldealer_B317 18 сен. 2016, в 10:50
0

Вы можете предварительно собрать свою библиотеку с помощью FPC, а затем загрузить ее с приложением FMX, скомпилированным в Delphi. Я сам еще не пробовал, и углубление, вероятно, вышло бы за рамки этого вопроса.
souldealer_B317 18 сен. 2016, в 11:00
0

@ Remy: есть ли у вас какие-либо сведения о том, что Android 7 больше не поддерживает динамические ссылки? И что бы это значило? Если apk проекта содержит несколько .so файлов, я больше не могу получить доступ к функциональности, содержащейся в других, или я неправильно истолковал то, что вы здесь говорите?
Markus 16 июнь 2018, в 12:32
0

@Markus, изменения в поведении Android 7, о которых говорил Реми, (я считаю) задокументированы здесь . Это говорит о том, что это влияет на ваши .apk ссылки на файлы .so вне вашего .apk. Поэтому несколько файлов .so внутри вашего .apk должны нормально взаимодействовать.
blong 16 июнь 2018, в 16:05
0

@ souldealer_B317, я полагаю, что ваше предположение о том, что совместно используемые библиотеки не могут быть созданы с помощью Delphi, неверно. Невозможность использовать ключевое слово library является лишь следствием того факта, что все приложения в любом случае являются общими библиотеками. Нет смысла поддерживать ключевое слово library как оно не имеет значения. Вы можете экспортировать функции из Delphi .so по своему усмотрению и получать доступ к этим экспортированным функциям из другого кода .so или из Java. Различие, которое вы проводите между разделяемым объектом и разделяемой библиотекой, недопустимо по этой причине.
blong 16 июнь 2018, в 16:09
0

У меня есть пример, который доказывает эту мысль и имел место в течение нескольких лет, но до сих пор не было важно записать его. Если вы загляните в .apk проекта службы Delphi, вы увидите 3 .so файла, приложение, службу и библиотеку прокси, все они созданы с помощью Delphi. Java прекрасно вызывает экспорт прокси-библиотеки, а служба lib .so экспортирует просто отлично. Я думаю, что главное препятствие во всем этом заключается в том, что никто не показал, как это сделать. Хотя, может, Саймон Чой вроде так и сделал здесь ?
blong 16 июнь 2018, в 16:12

Показать ещё 4 комментария

Ещё вопросы

Последняя сборка FPC (3.1.1) поддерживает компиляцию библиотеки для Android с небольшими ограничениями: wiki.freepascal.org/Android#Building_cross_compiler
Вы можете предварительно собрать свою библиотеку с помощью FPC, а затем загрузить ее с приложением FMX, скомпилированным в Delphi. Я сам еще не пробовал, и углубление, вероятно, вышло бы за рамки этого вопроса.
@ Remy: есть ли у вас какие-либо сведения о том, что Android 7 больше не поддерживает динамические ссылки? И что бы это значило? Если apk проекта содержит несколько .so файлов, я больше не могу получить доступ к функциональности, содержащейся в других, или я неправильно истолковал то, что вы здесь говорите?
@Markus, изменения в поведении Android 7, о которых говорил Реми, (я считаю) задокументированы здесь . Это говорит о том, что это влияет на ваши .apk ссылки на файлы .so вне вашего .apk. Поэтому несколько файлов .so внутри вашего .apk должны нормально взаимодействовать.
@ souldealer_B317, я полагаю, что ваше предположение о том, что совместно используемые библиотеки не могут быть созданы с помощью Delphi, неверно. Невозможность использовать ключевое слово library является лишь следствием того факта, что все приложения в любом случае являются общими библиотеками. Нет смысла поддерживать ключевое слово library как оно не имеет значения. Вы можете экспортировать функции из Delphi .so по своему усмотрению и получать доступ к этим экспортированным функциям из другого кода .so или из Java. Различие, которое вы проводите между разделяемым объектом и разделяемой библиотекой, недопустимо по этой причине.
У меня есть пример, который доказывает эту мысль и имел место в течение нескольких лет, но до сих пор не было важно записать его. Если вы загляните в .apk проекта службы Delphi, вы увидите 3 .so файла, приложение, службу и библиотеку прокси, все они созданы с помощью Delphi. Java прекрасно вызывает экспорт прокси-библиотеки, а служба lib .so экспортирует просто отлично. Я думаю, что главное препятствие во всем этом заключается в том, что никто не показал, как это сделать. Хотя, может, Саймон Чой вроде так и сделал здесь ?

suat dmk · Accepted Answer · 2014-12-14T15-23-00.000Z

могут быть полезны следующие коды.

//-- Code for libMylib.so (MyLib.dproj) --- 

    library MyLib; 
//    uses  SysUtils;


    function GetSum(a, b: integer ) : integer; cdecl; 
    begin 
      Result := a + b; 
    end;

    exports

    GetSum        name 'GetSum'; 

    begin 
    end.

    //-- Code for using libMylib.so (TestMyLib.dproj) --- 

    var 
    DocDir, LibFN: string; 
    GetSum: function(a, b: integer ) : integer; cdecl; 
    hLib: HMODULE; 

    begin 
      DocDir := IncludeTrailingPathDelimiter(System.IOUtils.TPath.GetLibrary'enter code here'Path);
      LibFN:=DocDir + 'libMyLib.so';
      hLib := LoadLibrary(LibFN); //ERROR (Segmentation fault (11)) 
      if hLib<>0 then 
      begin 
        GetSum := GetProcAddress(hLib, 'GetSum');//It works
        ShowMessage(IntToStr(GetSum(3, 8)));//It works 
      end; 
    end;

PS: вы должны добавить скомпилированный файл libMyLib.so для развертывания TestMyLib.dproj.

P.S2: он дает ошибку при выполнении "LoadLibrary", но работает.

Я не мог найти решение. Вероятно, это связано с параметрами компилятора/компоновщика MyLib.dproj. Потому что, когда я тестирую другой файл.so, который скомпилирован с C++, при вызове LoadLibrary проблем не возникает.