Android sdk debian 10 install

Пакет: android-sdk (28.0.2+3)

Ссылки для android-sdk

Ресурсы Debian:

Исходный код android-sdk-meta:

Сопровождающие:

Подобные пакеты:

Software development kit for Android platform

The Android SDK includes a variety of tools that help you develop mobile applications for the Android platform. The tools are classified into 3 groups: SDK Tools, Platform-tools and Build-tools.

SDK Tools are platform independent and are required no matter which Android platform you are developing on. It is the base toolset of Android SDK.

This metapackage pulls the entire Android SDK.

Другие пакеты, относящиеся к android-sdk

зависимости

рекомендации

предложения

enhances

• dep: android-sdk-build-tools Tools for building Android applications
• dep: android-sdk-common (>= 28.0.2+3) Common files of Android SDK base toolset
• dep: android-sdk-platform-tools (>= 20) Tools for interacting with an Android platform
• dep: proguard-cli Java class file shrinker, optimizer, and obfuscator (CLI)

• rec: default-jdk-headless Standard Java or Java compatible Development Kit (headless)
• rec: gradle Powerful build system for the JVM

• sug: android-sdk-platform-23 Android SDK Platform for API Level 23 (6.0 Marshmallow)
• sug: maven Java software project management and comprehension tool
• sug: proguard-gui Java class file shrinker, optimizer, and obfuscator (GUI)

Загрузка android-sdk

Загрузить для всех доступных архитектур

Архитектура	Размер пакета	В установленном виде	Файлы
amd64	5,4 Кб	34,0 Кб	[список файлов]
arm64	5,4 Кб	34,0 Кб	[список файлов]
armel	5,4 Кб	34,0 Кб	[список файлов]
armhf	5,4 Кб	34,0 Кб	[список файлов]
i386	5,4 Кб	34,0 Кб	[список файлов]
mips64el	5,4 Кб	34,0 Кб	[список файлов]
mipsel	5,4 Кб	34,0 Кб	[список файлов]

Эта страница также доступна на следующих языках (Как установить язык по умолчанию):

Чтобы сообщить о проблеме, связанной с веб-сайтом, отправьте сообщение (на английском) в список рассылки debian-www@lists.debian.org. Прочую контактную информацию см. на странице Debian Как с нами связаться.

Авторские права © 1997 — 2021 SPI Inc.; См. условия лицензии. Debian это торговый знак компании SPI Inc. Об этом сайте.

Источник

• AndroidTools
• IntroBuildingApps

This is a tutorial for building an Android app using only Android SDK and development tools already available in Debian. Two examples are provided. The first example is a build of a minimal Android «Hello World» program using the make utility. It has been tested on Debian 10 (Buster). The second example is a build of the F-droid client app using gradle. It was originally tested on Debian 9.2 (Stretch), but requires updating to run on Debian Buster. Each example produces an Android application package file (.apk) which can be used to install the app on an Android device.

Terminology (for those new to Android development)

API Level — Apps interface to the Android OS via the Android Application Program Interface (API). The API is frequently updated (30 versions over 12 years). Each version is identified by the API Level, which is incremented by 1 from the previous version. API versions are generally backward compatible; an Android version that supports one API Level will run apps targeted at earlier API levels. A list of Android versions and corresponding API Levels can be found here and here

ART (Android Runtime) — is the virtual machine and runtime environment of Android 5.0 (API Level 21) and later versions. ART uses Dalvik bytecode. It implements selective precompilation of bytecode into the host device’s native machine language to improve performance. Details here.

Dalvik — Android’s original virtual machine, superseded by ART. Its bytecode is different from the JVM bytecode. Application build tools compile JVM bytecode into Dalvik bytecode which is saved in a .dex (Dalvik EXecutable), which is included in an APK file for installation on the target device.

APK (Android Package)- file format that packages an Android app for installation on a device; .apk is the usual file extension.

Gradle — a build utility used by many Android projects.

Currently there is only the target platform of API Level 23 packaged, so only apps targeted at android-23 can be built with only Debian packages. We will add more API platform packages via backports afterwards. Only Build-Tools 24.0.0 is available, but we will use the android-sdk-helper package so we won’t need to modify the build scripts in order to use the SDK.

Hello World

On Debian Buster, install the following packages with apt (or Synaptic):

# apt install git make android-sdk android-sdk-platform-23

Check out the project with git and build it with make:

$ mkdir

$ cd

$ cd hello-world-debian-android

$ make

The build generates file helloworld.apk. Copying it to an Android device and opening it will install the app.

(Testing: Built from commit 39bf760e 2020-06-17 of the Git project using Debian Buster, then run on Cyanogenmod Android 4.4.4 and on Android 7.0. Also reported to be tested on Android 11.)

F-droid — Preparing the environment

# apt install android-sdk android-sdk-platform-23 git libgradle-android-plugin-java

Obs1: Git is the recommended method to obtain the source code of the android application.

Obs2: The last package is needed to meet the dependency of android-sdk-helper, which is not in stretch repositories yet

Get the android-sdk-helper from the testing repository

Right now, android-sdk-helper is not available in stretch backports, so we will have to add testing/buster repository.

Add Debian buster or later to your apt sources files (/etc/apt/sources.list etc).

The next step is to create/update apt preferences files (/etc/apt/preferences etc). This is where the apt pinning takes place. Normally, the highest version of an available package wins, but we will override that.

Create/edit the preferences file so it looks like this:

Note the descending values. Since Stable has the highest pin-priority, it will be installed preferentially over Testing.

Getting F-droid source code

Let’s create a Git folder in your home directory and clone the F-droid source code into it

$ mkdir

$ cd

Adjustments

Some tweaks will be necessary so everything can work as expected

Accepting SDK license

To use the android-sdk you must accept its license. At the present moment there are some ways to do so, but none of them is perfect.

In this tutorial we’ll clone a git repository containing all the needed licenses and copy them to the right location.

/Git$ sudo cp -a android-sdk-licenses/*-license /usr/lib/android-sdk/licenses

Note that this is a temporary solution. We can expect that in the future there will be offered an automatic solution for accepting the SDK license.

Define your SDK location

In the top folder of your app project, you need to create a file called local.properties that says where your SDK is. In our case, this file needs to have the following single line:

Disabling lint

Since the Lint in this version of Gradle Android Plugin is still problematic, running the :lint tasks might not work. They can be turned off editing the file build.gradle in the app folder.

Open this file with your prefered editor and search for the line that says abortOnError inside the lintOptions method. Then change it to false

Change Heap Size (in case gradle complains about the speed)

After you start builing your app with gradle you might get a warning like this:

If it happens to you, obey your computer and create the file gradle.properties in the root folder of your project and add the line

Change locale (for some timezones)

There is currently an unexpected behaviour in F-droid building process that results into an error when the project is built in some timezones. If the gradle fails with the message

• Execution failed for task ‘:app:testDebugUnitTest’

You can fix it by temporarily changing your timezone to GMT+1 with the command. Run the gradle command, and after everything is done remember to use this command again to return to your regular timezone.

# dpkg-reconfigure tzdata

Building the app

After you follow all the past steps, you probably will be able to build the project easily with the following command.

Источник

• AndroidTools

This page is a gathering place for information about the android-tools packaging team, which is focused on packaging the Android development tools for Debian. There are also some packages which help run Debian in a chroot on Android. The goal of this team is to get as much of the Android SDK and development tools into Debian as possible. There are many advantages to having the SDK and tools in Debian, rather than relying only on the Google distributions:

• easy install and update channel that all Debian users already know
• automatic trustworthy downloads, no need to verify hash sums
• eliminate need for insecure wrapper scripts, like ./gradlew

trivial install for specific tools, like adb, fastboot, etc.

To communicate with this team, join our low traffic mailing list, android-tools-devel@lists.alioth.debian.org and on the IRC channel #debian-android-tools (webchat). You can also join the IRC Channel through Matrix

The binaries for the Android SDK downloadable from Google have a proprietary license but the source code is free software so Debian is packaging it. Not all Android SDK packages can be installed from Debian, some never will be in Debian because they are too specific to Android. Sylvain Beucler’s libre Android rebuilds and/or Google’s non-free binaries can also be used with the Debian Android SDK.

Building apps with these packages

If you’re just starting out with building apps, we suggest that you first read the Introduction to build packages with Debian’s Android SDK.

If you are already familiar with how to use these tools, you might want to look these brief instructions below. Here are the steps for building Android apps using Debian’s Android SDK on Stretch.

1. sudo apt install android-sdk android-sdk-platform-23
2. export ANDROID_HOME=/usr/lib/android-sdk

In build.gradle, change compileSdkVersion to 23 and buildToolsVersion to 24.0.0

run gradle build

The Gradle Android Plugin is also packaged. Using the Debian package instead of the one from online Maven repositories requires a little configuration before running Gradle. In the buildscript <> block:

use compile ‘com.android.tools.build:gradle:debian’ to load the plugin

Currently there is only the target platform of API Level 23 packaged, so only apps targeted at android-23 can be built with only Debian packages. We will add more API platform packages via backports afterwards. Only Build-Tools 24.0.0 is available, so in order to use the SDK, build scripts need to be modified. Beware that the Lint in this version of Gradle Android Plugin is still problematic, so running the :lint tasks might not work. They can be turned off with lintOptions.abortOnError in build.gradle. Google binaries can be combined with the Debian packages, for example to use a different version of the platform or build-tools.

In stretch-backports (and soon testing), the Gradle Android Plugin is patched to work with Debian’s Android SDK. It detects what versions of API Levels and Build-Tools are available and you no longer need to modify the build scripts. In order to build apps, do the following:

1. sudo apt install android-sdk android-sdk-platform-23 android-sdk-helper
2. export ANDROID_HOME=/usr/lib/android-sdk
3. gradle build —init-script /usr/share/android-sdk-helper/init.gradle

Thus, init.gradle forces Gradle to use the Gradle Android Plugin in Debian and the plugin will do the rest.

Communication Channels

There are a number of ways that people working on packaging Android Tools communicate. Here is a list:

IRC chat room for automated messages: #debian-android-tools

some Java packages are essential to Android, so we also talk here: #debian-java (webchat).

Joining the Android Tools Team

We want make it as easy as possible for anyone to get involved in the Android Tools Team, and contribute in ways that they think are important. It is important to note that some of the packages here are quite complicated, and the Android SDK is a very large project. That means that changes must be discussed with the team before they can be committed and pushed. That discussion can happen in anywhere, including merge requests.

So here is the Android Tools Team policy for granting membership to the team, based on the GitLab user roles:

• any request to become a member is granted at least «Reporter» level
• any Debian Developer or previous contributor is granted at least «Developer» level

requests from anyone else must be posted to https://salsa.debian.org/android-tools-team/admin/issues and are approved by «lazy consensus»

specific requests for «Master» level must also be posted to https://salsa.debian.org/android-tools-team/admin/issues and are approved by «lazy consensus»

This is based on «Lazy consensus»: if no one objects to a request within one week or so, then any Master/Owner is free to grant the request. So silence is considered approval, but not automatic approval. An existing Master/Owner must actually grant the request after the waiting period.

standalone vs. interdependent packages

Mostly, our procedures are about which packages are standalone and can be freely uploaded, versus which packages are interwoven and must be uploaded in coordinated batches (e.g. the Android SDK). repo or enjarify is a standalone package, for example. The interwoven ones basically all follow the Android SDK git repo naming scheme for the source package names:

Package naming scheme

The naming scheme for android-tools packages is as follows:

binary packages of utilities that run on Debian directly are named after the utility itself (e.g. zipalign, aapt, etc.)

shared libraries that are only used by android-tools packages are named after the library, without a ABI version number in the package name, and prefixed by android-. (e.g. android-libhost, android-libcutils-dev, etc. In the Google builds, these are built as static libraries, and linked statically into each binary. In the Debian builds, they are built as shared libraries and installed into /usr/lib/android.

Source package structure

The structure of each source package is documented in the README.source of each source package for this team:

Updating the source packages

The packages in this team are structured somewhat unusually because we are trying to keep the source packages as close as possible to the upstream source organization while still working in a Debian way. Google builds the Android OS and SDK as one giant thing, something like 10 gigs of source code. But the code is broken up into many different git repos that are coordinated using the Android team’s tool called repo. Also, there are lots of shared libraries used between the various Android SDK tools, but since everything is always built together, those shared libraries are unversioned.

All this means that it is essential that any Android SDK package is only built against the exact same version of all its Build-Depends and only uses the exact same version of an Android SDK package as a Depends. To achieve that, we use the substvars variable in dependency declarations: (>= $).

Additionally, because of this and the circular dependencies, it is important to upload updates in the correct order. Some packages also have to be uploaded using a multi-stage method. Here is the estimated upload order:

• Stage 1
  • android-framework-$apilevel
  • android-platform-external-boringssl
  • android-platform-external-jsilver (Usually no update needed)
  • android-platform-external-libselinux (should be switched to android-platform-external-selinux from 8.0 release)
  • android-platform-external-libunwind
  • android-platform-frameworks-data-binding
  • android-platform-frameworks-native
  • android-platform-libcore
  • android-platform-tools-analytics-library
• Stage 2
  • android-platform-external-doclava
  • android-platform-system-core

    stage1

  • android-platform-tools-base
• Stage 3
  • android-platform-art
  • android-platform-development
  • android-platform-frameworks-base
  • android-platform-libnativehelper
  • android-platform-system-extras
  • android-platform-system-tools-aidl
• Stage 4
  • android-platform-art
  • android-platform-build
  • android-platform-dalvik
  • android-platform-system-core

  android-platform-dalvik (Needs android.jar of the latest API Level)

Each packages belonging to the same stage are unrelated to each other and can be uploaded in any order.

This order only represents one possible way of updating all of them to a new major version. In practice, you can delay or advance any packages as long as the build-dependencies satisfy.

Upstream repository of tools in Android SDK

Tools in Android SDK come from various repositories. Here is a list of tools consisting the entire Android SDK, with each tool followed with the corresponding upstream repository name.

SDK Tools

hierarchyviewer: platform/tools/swt (deprecated)
monitor (Depends on hprof-conv, systrace.py, logcat)

traceview: platform/tools/swt (deprecated)

android (Including SDK Mannager, AVD Manager) (Deprecated)

apkanalyzer:

Источник