How to add library android

How to Add External Library in Android Studio?

Android Studio is the official IDE (Integrated Development Environment) for Android app development and it is based on JetBrains’ IntelliJ IDEA software. Android Studio provides many excellent features that enhance productivity when building Android apps. In this article, we will learn how to add external libraries to our android project.

Method 1: Copy external library to the libs folder

Let us have an external library that we want to use in our project i.e a jar file.

Create a new project named GFGAddLib.

Now, our project has been created.

Now click on the Android drop-down and change to Project files.

Click on Project files.

Copy the jar file to the libs folder.

Here, you can see our added jar file under the libs folder. Right-click on the jar file and select Add As Library.

Now come back to the Android tab, you can see that your library has been already declared in build.grade (Module: GFGAddLib.app)

The library is successfully added to our project.

Method 2: Using the module library

Let us have a new project GFGAddLib2 and we want to use the same common-lang3-3.4.jar library for this project.

Create a new Android Module. Go to the File -> New -> New Module

Select Import JAR/.AAR Package and click Next.

Select the location of your JAR file and click on Finish.

Module library has been created. Next, we need to declare the dependency of the main project on the newly created module. Now go to the File and click on Project structure.

Now click on circled + sign and select Module Dependency

Click OK, a new dialogue box will appear, select the jar file and click OK.

Источник

How to add libraries in android studio in english

Jun 11, 2017 · 3 min read

Try one of these approaches:

1- Choose project view

2- Copy your JAR file in app -> lib folder

3- Right click on your JAR file and choose add as library

4- Check it in build.gradle

1- File -> New -> New Module

2- Import .JAR/.AAR Package

3- Browse your JAR File

5- File -> Project Structure -> Dependencies

6- You should click on + button and then click on Module Dependency

7- You will see your library here

8- choose your library and click ok

9- Then, you will see that your library is added.

For first two approaches, you need a JAR file. You can search http://search.maven.org/ to find JAR files that are related to Android. For example, this is the search result for jdom in this link

Approach 3) Android is using http://jcenter.bintray.com/ as remote library. For example, this is the search result for jdom in the link.

To add a library in this approach, please follow these steps:

1- File -> Project Structure -> Dependencies

2- Click on + button and choose library dependency

Источник

What is Android Support Library and How to add it in Android Studio?

In this post, you will learn about the Android Support Library and How to add in your Android Studio project.

In Android app development, support libraries have an important role. Without them, It might difficult to provide a consistent look and feel in all devices.

Okay, tell me in detail.

What is Android support library?

There are many devices still running in Jelly bean and below versions. So you need to give the same importance for old and new devices While making an app. Otherwise, the App in old devices looks dull when compared to new ones.
That may affect the app’s market. To avoid this trouble, Android introduced the Support library. These are set of code libraries that provide backward compatibility and you can find it on Android SDK. These libraries experiences revisions for fresh features and bug fixes. Package name shows which Android Version it supports from.
For example : android.support.v7.app.AppCompatActivity – It can be used with API level 7 and higher.

After the release of support-library 26.0.0, support for minimum API level change it to API level 14 . So Don’t confuse with v* notation

The Android Support library includes

• Palette – It used to take out colors from image.
• CardView – Provides card look like widget.
• leanback – Helps to make UI for TV apps.
• Mediarouter – Supports for Media Routes.
• gridLayout – Arranges widgets in grid manner.
• RecyclerView – New version of ListView and GridView.
• AppCompat – Provides support for ActionBars.
• support-v4 library – User Interface features and other components.
• MultiDex – helps to make apk contains multiple dex files.
• RenderScript – Enables latest features of RenderScript .
• Annotations – improves code .

If you are a beginner and experimenting with online tutorials, there may be a chance to edit the gradle file directly for adding the library as a dependency, sometimes wait for a download too.

Before doing that you can perform the following procedures to find and add an available version of the same support library. You can use this way to add AppCompat, Design, CardView, RecyclerView and so on.

There are two methods you are going to learn here. First one is simple and fast. The second method is an old one. But it’s good to know about that.

We assume that you have opened Android Studio and your project.

Method 1 – How to add support library in Android Studio

Open build.gradle(Module:app) file

Use ALT + ENTER and select Add library dependency

Select from the list, Here I am adding CardView.

CardView is added to my project. Just like this, you can add any library. If there is a sync needed. Just sync it.

Method 2 – How to add support libray in Android Studio

File->Project Structure you can use “Ctrl + Alt + Shift + S ” key combinations.

click the app module.

Click the Dependencies tab, you will see already added libraries below. click the + Button shown in the Right side of the window.

Choose library dependency from available options.

Choose library dependency dialog will be visible now. You can search here or choose the desired library that you want from the list. After your selection, just click OK.

The selected library will be added as a dependency in your dependencies tab list and click OK.

Just look at the build.gradle(Module: app) file dependency section, Android Studio will add your selected library. Please share it and your valuable comments will help us to improve.

Conclusion

The Android Support library helps to reduce the headache of developers by providing backward compatibility. Users also feel fresh and happy with their old device. There is no complexity in adding support library in Android Studio. You can do it in simple steps. I assume the above words might have helped you.

Источник

Как собрать нативную библиотеку для Android

Собрать и заставить работать приложение с небольшим количеством нативного кода несложно. Если же вы хотите использовать нативную библиотеку, в которой много файлов, становится труднее. Сложность в том, что нативные библиотеки распространяются в виде исходного кода, который нужно компилировать под нужную архитектуру процессора. На примере аудиокодека Opus я покажу, как это сделать.

В своей предыдущей статье я на примере аудиокодека Opus показал, как решить задачу сборки нативной библиотеки для Android, но в проект был добавлен весь исходный код Opus, а так делать не хочется. По-хорошему нужно иметь в проекте уже собранные .so или .a, и используя их, писать свои врапперы на C/C++ и собирать приложение. Об этом и пойдёт речь в статье. На примере того же аудиокодека Opus я покажу, как с помощью NDK получить скомпилированные .so и .a, чтобы далее использовать их в Android-проекте.

Чтобы использовать любую нативную библиотеку, нам нужно написать враппер на C/C++, в котором мы будем вызывать методы самой библиотеки. Мы скомпилируем и соберём библиотеку Opus как статическую (.a).

Мы вызываем функцию в нашем C файле, которая описана в другой библиотеке. Для этого в начале файла пишем #include . Далее на этапе компиляции C файла, если библиотека статическая(.a), то вместо #include компилятор подставит весь код этой функции. Если динамическая(.so), то подставит только ссылку на функцию. Таким образом, при использовании статической библиотеки у нас есть весь код, который нам необходим из другой библиотеки, а при использовании динамической код будет подгружаться динамически.

Использование .so в зависимостях может уменьшить размер нашей итоговой библиотеки. Это было бы так, если бы Opus был стандартной библиотекой, но так как её нет в Android, мы должны её предоставить. Поэтому итоговый размер нашего libjniopus.so будет одинаковым, что при использовании libopus.a, что при использовании libopus.so.

Для компиляции нативных библиотек из исходников в NDK c версии 19 есть готовые удобные инструменты «из коробки». В документации описано, как их использовать. Описание довольно короткое, поэтому человек, не имеющий опыта в сборке нативных библиотек, неизбежно столкнётся со сложностями. Как их решить, я разберу ниже.

Собираем Opus из исходников

Сначала скачиваем исходники: либо из репозитория (git clone), либо архивом. У Opus есть Autoconf — утилита, которая автоматически создаёт конфигурационные скрипты. В проекте с Autoconf можно задать toolchain для компиляции, используя ENV-переменные. Autoconf, как правило, работает только на Unix подобных системах. Поэтому если у вас Windows, то вам, скорее всего, придётся использовать средства эмуляции.

В итоге мы хотим получить 4 файла библиотеки с расширением .a по одной на каждую архитектуру процессора: armeabi-v7a, arm64-v8a, x86, x86-64.

Для каждой архитектуры нужно задать свои ENV-переменные. Общими будут только NDK, HOST_TAG и TOOLCHAIN. В Linux, ENV-переменную для текущей сессии терминала можно задать, используя команду export:

Однако заданные ENV-переменные будут существовать, пока активна текущая сессия терминала, и только в ней. Если вы откроете другую сессию, то там этих переменных не будет. Чтобы каждый раз не прописывать ENV-переменные заново, можно добавить их в конец файла .bashrc, который находится в домашнем каталоге (

). Перед запуском каждой сессии терминала запускается .bashrc. Поэтому переменные, объявленные в нём, будут существовать во всех сессиях терминала. Вот ENV-переменные, которые отличаются в зависимости от архитектуры:

Сначала скомпилируем под arm64-v8a, поэтому закомментируем в .bashrc объявление ENV-переменных для остальных архитектур. Стоит отметить, что в переменных CC и CXX есть цифра 21, которая очень похожа на Android API level. Так и есть, а если быть точнее, то это ваша minSdkVersion. В нашем примере это 21, но если у вас другие потребности, можете смело поменять. В NDK доступны версии с 16 по 29 для 32-разрядных ABI (armeabi-v7a и x86) и с 21 по 29 для 64-разрядных ABI (arm64-v8a и x86-64).

Итак, мы объявили ENV-переменные, которые определяют toolchain для компиляции под выбранную архитектуру, и выкачали репозиторий с исходниками Opus. Теперь открываем Readme в папке с исходниками Opus и видим, что для компиляции библиотеки надо всего-навсего запустить:

Но не всё так просто. Таким образом мы скомпилируем библиотеку под архитектуру нашей рабочей машины, а нам надо под 4 архитектуры мобильных девайсов.

В NDK с версии r19 «из коробки» идут toolchains. Как и показано в примере на странице, нужно выставить ENV-переменные (выставили их выше в .bashrc), соответствующие архитектуре, под которую компилируется библиотека. Затем нужно запустить команду configure с соответствующим аргументом host. Для arm64-v8a получается такое:

/.bashrc необходимо запускать, чтобы изменения переменных среды для сборки «подхватывались» текущей сессией терминала без перезапуска.

После выполнения всех вышеописанных команд, в папке с исходниками Opus появится папка .libs. В ней будут находиться все артефакты компиляции, в том числе и нужный нам libopus.a.

Далее в .bashrc комментим/раскомменчиваем, чтобы активными были ENV-переменные для armeabi-v7a, и прописываем команды уже с другим аргументом host:

./autogen.sh не выполняем, так как он нужен был только для первоначальной генерации конфигурационных файлов и того самого configure, который мы запускаем.

В этот раз команда make завершится ошибкой. Я долго не понимал, из-за чего так происходит. Поискав в интернете похожие проблемы, понял, что файлы и тесты, которые создаются для определённой архитектуры, во время компиляции не удаляются автоматически после переконфигурации на другую архитектуру (запуск configure с другим host). А так как в папке с исходниками, в которой появляются все артефакты сборки, и так много файлов, понять, какие из них надо удалять потом, очень сложно.

Решение оказалось довольно простым. Можно запускать все команды для конфигурации и компиляции, не находясь в папке с исходниками Opus. Тогда можно создать свою отдельную папку для каждой архитектуры, где будут все артефакты сборки и временные файлы для этой архитектуры.

Теперь всего-то нужно создать 4 папки и последовательно сделать одни и те же действия по выставлению ENV-переменных и прописыванию команд с нужным аргументом. Это слишком долго и скучно, поэтому есть отличная возможность написать bash-скрипт, который всё это сделает за нас. Вот такой небольшой скрипт получился:

Если использовать скрипт, то объявлять ENV-переменные в .bashrc нет необходимости, так как они объявлены в скрипте.

Чтобы использовать скрипт, нужно сделать его исполняемым:

Далее необходимо прописать путь к NDK на вашей машине и поменять HOST_TAG, если вы не на Linux (в скрипте значение linux-x86_64):

• 32-bit Windows: windows
• 64-bit Windows: windows-x86_64
• macOS: darwin-x86_64

Затем запускаем скрипт таким образом:

Ему нужно передать minSdkVersion и путь к папке с исходниками Opus. Опционально можно передать путь к папке, куда поместим артефакты сборки. По умолчанию создаётся папка opus_android_build в папке, где расположен скрипт buildOpus.sh.

Выполнение скрипта займёт некоторое время. Потом в папке opus_android_build или в той, которую вы передали, будут располагаться папки с названиями ABI, под которые была скомпилирована библиотека. Соответственно, внутри каждой папки будет уже знакомая нам папка .libs, в которой лежат все артефакты сборки.

Добавляем собранные библиотеки в проект

Отлично, у нас есть 4 файла libopus.a под разные архитектуры, самое сложное позади. Осталось добавить их в наш Android-проект и поправить CmakeLists.txt, чтобы к итоговой .so линковалась скомпилированная нами статическая библиотека Opus.

У нас есть папка app/src/main/cpp, в которой лежит наш C-враппер (jniopus.c), к которому идут external вызовы из Kotlin. В ней создаём папку includes. Затем в неё копируем содержимое папки include из исходников Opus. Там находятся файлы хедеров (.h). Они нам нужны для использования функции и структуры Opus в нашем C-враппере. Файлы хедеров содержат прототипы функций и являются своего рода контрактом, который определяет, какие аргументы может принимать и возвращать та или иная функция.

После этого в той же в папке app/src/main/cpp создадим папку libopus, а внутри неё 4 папки с названиями, идентичными названиям ABI, под которые мы скомпилировали библиотеку Opus: armeabi-v7a, arm64-v8a, x86, x86-64. В каждую из них помещаем файл libopus.a, скомпилированный под соответствующую архитектуру.

Далее модифицируем CmakeLists.txt, который был в предыдущей статье, где мы собирали Opus из исходников прямо в проекте. Сначала удаляем «простыню» со всеми путями к исходникам. Затем задаём переменные для путей:

Теперь добавляем Opus в сборку:

add_library используется для добавления библиотеки в сборку. Сначала идёт имя, которое у неё будет, далее тип библиотеки STATIC(.a) или SHARED(.so) и путь к исходникам, либо слово IMPORTED, если у нас уже собранная библиотека и мы хотим её использовать. В этом случае путь к готовым (импортируемым) библиотекам указывается ниже с помощью конструкции:

ANDROID_ABI это NDK toolchain аргумент, который сам туда подставит ABI.

Для компиляции нашего С-враппера, куда идут external вызовы из Kotlin, мы оставляем:

Также оставляем библиотеку, которая идёт «из коробки» в NDK для логирования таким образом:

И в конце мы объединяем всё это вместе:

Первым параметром идёт имя итоговой библиотеки, далее идут имена библиотек, которые нужно прилинковать к нашей. Вот и всё, теперь синхронизируем проект с помощью Gradle, нажимаем Run, и готово. Приложение открывается, жмём на кнопку Start call и говорим. Если тут же слышим то, что сказали, значит всё работает как надо.

Источник