Is there a reference like this (http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html) that explains the folders inside the main Android SDK folder?
Based on the response I've got so far, I think I need to clarify further what I'm looking for.
I wanted to know the basis for the SDK to be divided into these folders (screenshot below). For e.g. something similar to the following excerpt in the 'SDK Readme.txt'
"Platform-tools contains build tools that are periodically updated to support new features in the Android platform (which is why they are separate from basic SDK tools), including adb, dexdump, and others."
I did put copy the android-sdk folder at a location separate from IDEs so that it can be shared.
It's not a guaranteed standard, but the folders have been consistent for many years now. Here are the core basics, see the links for more info:
# platform-tools: Updated each AOSP version; always backwards compatible
# tools/bin: Platform-independent tools to help building/using android
# eg lint, sdkmanager, monkeyrunner
# build-tools/<version>: Compilation tools, required to build.
# AOSP version specific, typically used by AS directly
See https://developer.android.com/studio/command-line/
https://www.programering.com/a/MDMyMzNwATk.html
No, this is proprietary project from Google, so they don't need to follow any standard.
Related
I'm trying to port Android SDK Tools to unsupported system (OpenBSD for that matter).
I've already fixed few things in go scripts for 'lunch' to work.
Now I'm at the point where I need to provide binaries to actually build SDK for current machine.
Some of the tools are provided inside AOSP.
There are bunch of prebuilt executables and libraries inside prebuilts/build-tools/ in linux-x86 and darwin-x86 subdirs for specific platforms.
Question is, how did they get there?
There are aidl, m4, ninja, soong_zip, zipalign, etc.
I could link some of them from base system but for some of them (soong_zip, for example) I didn't find any information how to obtain them.
Is there some kind of google repo where one can build them from?
Any information that could be relevant to the topic are also will be welcomed.
Note - I am relatively new to Android and AOSP...
Where can I find the Android SDK in the AOSP? As we know, we build apk files in the android studio using the separately installed SDK. But for some reason, I wish to use the SDK in the AOSP if it is available. I see the source code of SDK in the AOSP; do we need to build it?
Why/How I have arrived at the above question:
I had created an .apk in the AOSP which had JNI files and dependency on some existing Broadcom libs (so). It is a system app. What I noticed is the .apk package does not contain the JNI libs but rather is copied to /system/lib folder separately. Hence I had a doubt how the .apk upgrade will work? Is it possible?
I assumed the .apk upgrade won't work that way and the .apk should be packaged including the JNI libs. Hence I planned to build the .apk in the studio and use the .apk as prebuilt and just sign it in the AOSP (we have the keys). Then I also wanted to allow the developers to build the .apk in AOSP itself by running the Gradle in the command line. I did so by adding the command to the Android.mk. But the point here is, it is still using the SDK installed in /home//Android/Sdk. But there may be build machines which may not have the SDK installed. So I am putting this question - Do we (where?) have the SDK in AOSP? Can I use that instead?
I tried to explain the problem.. in case it's not clear please let me know... Will try to give more details...
OTA update will work. Update with Package Manager - won't. This is normal for system apps with native libraries.
In AOSP applications are built differently depending on their location in build tree. Apps placed in ~/packages/apps and ~/device/some_vendor are system apps and they are handled differently by the system. One of differences is that during build process they are stripped of their native libraries and those libraries are simply copied to the /system/ partition.
Including pre-built apk is a good solution.
Yes you can build sdk yourself from sources. Yes, it's there. But I don't understand why you need that. Are there any changes to the API?
There are other options. For example, you can mangle your build scripts. Say, you can add a global FLAG that would disable lib stripping for system apps.
Is there a way to build AOSP's /platform/frameworks/base package source or support library source separately in Android Studio.
I wanted to read the framework (base and support) code in Android Studio and since I didn't want to be bothered about the rest of the packages in AOSP, I only imported the mirrored repo of these two packages as two separate projects in Android Studio. I want to browse through the code by using "jump to source" shortcut (cmd/ctrl+click) of the IDE. But this handy feature won't simply work properly in Android Studio. When I try to jump to the method definition which belongs to a different java source file (It says - "Cannot find declaration to go to"). This limitation of source editor is due to gradle build failure. The project just won't build and throws the following error.
Error:You need a symlink in prebuilts/sdk/99 that points to
prebuilts/sdk/current.Without it, studio cannot understand current
SDK. ln -s ../../prebuilts/sdk/current ../../prebuilts/sdk/99
Is there a way to fix this. I know I can simply browse the source code on http://androidxref.com/ too, but it's not as convenient and powerful as your IDE.
This is possible (having Android Studio be able to show you the framework code and let you use the usual IDE tools), though compiling won't work.
But the detail in your question seems to indicate you don't actually care about compiling, just about viewing/editing.
The first steps listed here:
http://ronubo.blogspot.com/2016/01/debugging-aosp-platform-code-with.html
might work for you. Basically:
Build your AOSP platform
( . build/envsetup.sh && lunch - && make ...)
Create the Android Studio project for importing to
( mmm development/tools/idegen && development/tools/idegen/idegen.sh )
Import the project
( open android.ipr from Android Studio)
Not without a huge effort.
For very many reasons.Ex:
1.the framework depends on different HALs and libraries from system/bionic/external
2.Compiling the framework uses specific tools from linux(flex,bison,libgl etc..)
3.Framework is built using the Android.mk system and needs a lot of flags and compilation macros from build/
I also can't imagine a motivation to do what you are trying to do. If it's going to run on any device, bare in mind device manufacturers modify the framework heavily, even the small ones. Actually the chipset manufacturers modify it and give it to manufacturers that modify it even more.
Error:You need a symlink in prebuilts/sdk/99 that points to prebuilts/sdk/current.Without it, studio cannot understand current SDK. ln -s ../../prebuilts/sdk/current ../../prebuilts/sdk/99
This notice already tell you should run the command:
ln -s ../../prebuilts/sdk/current ../../prebuilts/sdk/99
To tell build system use 'current version sdk' in prebuilts/sdk/current directory replace the temp sdk version 99.
could you try it?
Background: I have been using the Terminal-IDE program to learn about doing Android development (I like vim, for starters...).
https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside
As shipped, it supports SDK level 9. I want to support level 14 (Android 4.0+), so that I can use GridLayout instead of the more complex TableLayout.
I emailed the author, who responded in less than a day (kudos!), but, when I look for a replacement android.jar under /system on my tablet (Nexus 7 model 2), that particular jar does not exist, only many other jars with longer names that are just wrappers around dex files.
Anybody ran into this problem and solved it?
Upon further emails with the author of the environment, I found an easy solution:
Go to the system/classes directory of the T-IDE install
Rename the existing jar (e.g. - android.jar.t-ide)
Copy the android.jar from the SDK (or sdk directory within Android Studio) with an alternate name (e.g. - android.jar.studio.sdk)
Make a symbolic link from the updated SDK jar to android.jar
Now I can use GridLayout from Android 4.0 - compiles (on the tablet) and runs just fine. I did not need to update any other environment variables or configurations, as I replaced the original android.jar with a sym-link to the updated jar (and an "ls -l" will show which one is being used as "android.jar").
Note: if you get the updated android.jar from Android Studio, be sure to get the one in the sdk directory, not the one in the "plugins" directory, which won't work.
I have downloaded the android source code. And i want to make some modifications to the source code to embed some functionality which currently does not exist. But the problem here is that i am not able to understand how the source code is organised, what kind of files could be find where. So if someone could help me understand that it would be really helpful.
Here is short version of what you will find when you download the Android source. I will leave out some minor directories and dig deeper into a couple of the important ones. Basically what you will get (based on the current Ice Cream Sandwich release), in alphabetical order:
Bionic - the C-runtime for Android. Note that Android is not using glibc like most Linux distributions. Instead the c-library is called bionic and is based mostly on BSD-derived sources. In this folder you will find the source for the c-library, math and other core runtime libraries.
Bootable - boot and startup related code. Some of it is legacy, the fastboot protocol info could be interesting since it is implemented by boot loaders in a number of devices such as the Nexus ones.
Build - the build system implementation including all the core make file templates. An important file here is the envsetup.sh script that will help you a lot when working with the platform source. Running this script in a shell will enable commands to setup environment variables, build specific modules and grep in source code files.
Cts - the compatability tests. The test suite to ensure that a build complies with the Android specification.
Dalvik - the source code for the implementation of the Dalvik Virtual Machine
Development - projects related to development such as the source code for the sdk and ndk tools. Normally not a folder you touch when working with the platform for a target.
Device - product specific code for different devices. This is the place to find hardware modules for the different Nexus devices, build configurations and more.
External - contains source code for all external open source projects such as SQLite, Freetype and webkit.
Frameworks - this folder is essential to Android since it contains the sources for the framework. Here you will find the implementation of key services such as the System Server with the Package- and Activity managers. A lot of the mapping between the java application APIs and the native libraries is also done here.
Hardware - hardware related source code such as the Android hardware abstraction layer specification and implementation. This folder also contains the reference radio interface layer (to communicate with the modem side) implementation.
libcore - Apache Harmony.
libnativehelper - Helper functions for use with JNI.
(Kernel) - not part of the default source download but you can get access to this code either by downloading it manually or by adding the repository to the repo tool. Contains the sources for the Android version of the Linux kernel.
Out - the build output will be placed here after you run make. The folder structure is out/target/product/. In the default build for the emulator the output will be placed in out/target/product/generic. This is where you will find the images used by the emulator to start (or to be downloaded and flashed to a device if you are building for a hardware target).
Packages - contains the source code for the default applications such as contacts, calendar, browser.
Prebuilt - contains files that are distributed in binary form for convenience. Examples include the cross compilations toolchains for different development machines.
System - source code files for the core Android system. That is the minimal Linux system that is started before the Dalvik VM and any java based services are enabled. This includes the source code for the init process and the default init.rc script that provide the dynamic configuration of the platform
tools - Various IDE tools.
Beyond the above you also have the hidden .repo directory that contains the source for the repo utility. It also holds the manifest specifying what git repositories you want to track for this Android source project. If you have your own additions you could automatically track them by adding a local manifest here.
For modifications of the platform framework there are some instructions available in the device/sample folder of the source code tree. That will show you how to add APIs to Android without having to modify the core framework.