SDK v.s. SDK-addon v.s. hardware build.

[freakingtux]

Hello,

I am trying to understand how to deploy and use the different Android platform make targets.

I am working with the following cases:
Case-1) I will need to make small modifications to the standard Android APIs or code
Case-2) I will want to add new APIs next to the existing Android APIs
Case-3) I will want third parties to be able to develop using those APIs under Windows and Linux
Case-4) I will want to be able to build targeting real hardware.

Android globally supports the following targets
Target-1) Creating a SDK. In This contains the basic tools like the emulator binary and the SDK updater
Target-2) Creating a platform-x delivery (android.jar + emulator image and such) (in 2.2. this is part of the make sdk target)
Target-3) Creating a SDK-addon (vendor.jar + and emulator image)
Target-4) Creating a build targeting real hardware.

The questions I really have is about the relationship between the SDK-addon and a platform-x delivery.

When I create an sdk-addon it gets delivered with full emulator images but no "android.jar". How does that work? Should I run CTS on the sdk-addon?
What is the real difference between this sdk-addon and a platform?

Is it correct I can not create a AVD with multiple sdk-addons combined?
If like expected in Case-1 and Case-2 I make changes to the Android platform do I need to delivery a new SDK so people
can develop it or can I somehow decouple the delivery of a platform and the sdk?
How can I ensure the different target builds match?

I figured out how to do most things here but I am still struggling on how to use them.

Greetings

[David Turner]

On Wed, Jan 19, 2011 at 7:06 AM, freakingtux <kees.jon...@gmail.com> wrote:

Hello,

I am trying to understand how to deploy and use the different Android platform make targets.

I am working with the following cases:
Case-1) I will need to make small modifications to the standard Android APIs or code
Case-2) I will want to add new APIs next to the existing Android APIs
Case-3) I will want third parties to be able to develop using those APIs under Windows and Linux
Case-4) I will want to be able to build targeting real hardware.

Android globally supports the following targets
Target-1) Creating a SDK. In This contains the basic tools like the emulator binary and the SDK updater
Target-2) Creating a platform-x delivery (android.jar + emulator image and such) (in 2.2. this is part of the make sdk target)
Target-3) Creating a SDK-addon (vendor.jar + and emulator image)
Target-4) Creating a build targeting real hardware.

The questions I really have is about the relationship between the SDK-addon and a platform-x delivery.

When I create an sdk-addon it gets delivered with full emulator images but no "android.jar". How does that work?

add-ons are for stuff that add to the platform (hence the name). They correspond to case-2 and case-3 in your list.

They don't come with android.jar, which is specific to a given platform API.

 

Should I run CTS on the sdk-addon?

The CTS is supposed to perform platform-specific tests, and ignore additionnal vendor-specific APIs. However, it is run against a working system image (which may include add-ons, but that's not the point).

Note: If you provide a custom android.jar, chances are that you will not pass the CTS (depending on the modifications you made to the platform).

 

What is the real difference between this sdk-addon and a platform?

The platform is what _every_ Android application can expect to use. If you break the API, some applications will not be able to run properly.

 

Is it correct I can not create a AVD with multiple sdk-addons combined?

An AVD provides a system image. Said system image could provide anything, including the APIs of multiple add-ons. However, on the development side, I don't think you can build against multiple-addons at once.

If like expected in Case-1 and Case-2 I make changes to the Android platform do I need to delivery a new SDK so people
can develop it or can I somehow decouple the delivery of a platform and the sdk?

I think it is possible to make the SDK tools point to a custom repository of platform images, but I don't remember the details.

How can I ensure the different target builds match?

I figured out how to do most things here but I am still struggling on how to use them.

Greetings

--
unsubscribe: android-porti...@googlegroups.com
website: http://groups.google.com/group/android-porting

[Kees Jongenburger]

On Thu, Jan 20, 2011 at 3:29 AM, David Turner <di...@android.com> wrote:
> On Wed, Jan 19, 2011 at 7:06 AM, freakingtux <kees.jon...@gmail.com>

>> If like expected in Case-1 and Case-2 I make changes to the Android
>> platform do I need to delivery a new SDK so people
>> can develop it or can I somehow decouple the delivery of a platform and
>> the sdk?
>
> I think it is possible to make the SDK tools point to a custom repository of
> platform images, but I don't remember the details.

From inspecting the code it should be possible by declaring an
environment variable called SDK_UPDATER_URLS before the Android
manager gets called. The default non user repository however remains.
this allows to add "non user" source that are allowed to install
platforms.

/UpdaterWindowImpl.java
private void setupSources() {
RepoSources sources = mUpdaterData.getSources();
sources.add(new
RepoSource(SdkRepository.URL_GOOGLE_SDK_REPO_SITE, false
/*userSource*/));

// SDK_UPDATER_URLS is a semicolon-separated list of URLs that
can be used to
// seed the SDK Updater list for full repositories.
String str = System.getenv("SDK_UPDATER_URLS");
if (str != null) {
String[] urls = str.split(";");
for (String url : urls) {
if (url != null && url.length() > 0) {
RepoSource s = new RepoSource(url, false /*userSource*/);
if (!sources.hasSource(s)) {
sources.add(s);
}
}
}
}
Greetings