Android Frequently Asked Questions for Open Source

来源:互联网 发布:酷炫爆炸js网站效果 编辑:程序博客网 时间:2024/06/06 12:32

Open Source


What is the Android Open Source Project?

We use the phrase "Android Open Source Project" or "AOSP" to refer to the people, the processes, and the source code that make up Android.

The people oversee the project and develop the actual source code. The processes refer to the tools and procedures we use to manage the development of the software. The net result is the source code you can use to build mobile phones and other devices.

Why did we open the Android source code?

Google started the Android project in response to our own experiences launching mobile apps. We wanted to make sure there would always be an open platform available for carriers, OEMs, and developers to use to make their innovative ideas a reality. We also wanted to make sure there was no central point of failure, so no single industry player could restrict or control the innovations of any other. The single most important goal of the Android Open Source Project (AOSP) is to make sure that the open source Android software is implemented as widely and compatibly as possible, to everyone's benefit.

What kind of open source project is Android?

Google oversees the development of the core Android open source platform and works to create robust developer and user communities. For the most part, the Android source code is licensed under the permissive Apache Software License 2.0, rather than a "copyleft" license. The main reason for this is because our most important goal is widespread adoption of the software, and we believe that the ASL2.0 license best achieves that goal.

You can find more information on this topic on our Licenses page.

Why is Google in charge of Android?

Launching a software platform is complex. Openness is vital to the long-term success of a platform, since openness is required to attract investment from developers and ensure a level playing field. However, the platform itself must also be a compelling product to users.

That's why Google has committed the professional engineering resources necessary to ensure that Android is a fully competitive software platform. Google treats the Android project as a full-scale product development operation and strikes the business deals necessary to make sure great devices running Android actually make it to market.

By making sure Android is a success with users, we help ensure the vitality of Android as a platform and as an open source project. After all, who wants the source code to an unsuccessful product?

Google's goal is to ensure a successful ecosystem around Android. Of course, no one is required to participate. We opened the Android source code so anyone can modify and distribute the software to meet their own needs.

What is Google's overall strategy for Android product development?

We aim to release great devices into a competitive marketplace. We then incorporate the innovations and enhancements we made into the core platform as the next version.

In practice, this means the Android engineering team typically focuses on a small number of "flagship" devices and develops the next version of the Android software to support those product launches. These flagship devices absorb much of the product risk and blaze a trail for the broad OEM community, who follow up with many more devices that take advantage of the new features. In this way, we make sure the Android platform evolves according to the actual needs of real-world devices.

How is the Android software developed?

Each platform version of Android (such as 1.5, 1.6, and so on) has a corresponding branch in the open source tree. At any given moment, the most recent such branch will be considered the "current stable" branch version. This current stable branch is the one that manufacturers port to their devices. This branch is kept suitable for release at all times.

Simultaneously, there is also a "current experimental" branch, which is where speculative contributions, such as large next-generation features, are developed. Bug fixes and other contributions can be included in the current stable branch from the experimental branch as appropriate.

Finally, Google works on the next version of the Android platform in tandem with developing a flagship device. This branch pulls in changes from the experimental and stable branches as appropriate.

You can find more information on this topic at our Codelines, Branches and Releases page.

Why are parts of Android developed in private?

It typically takes more than a year to bring a device to market. And, of course, device manufacturers want to ship the latest software they can. Developers, meanwhile, don't want to constantly track new versions of the platform when writing apps. Both groups experience a tension between shipping products and not wanting to fall behind.

To address this, some parts of the next version of Android including the core platform APIs are developed in a private branch. These APIs constitute the next version of Android. Our aim is to focus attention on the current stable version of the Android source code while we create the next version of the platform. This allows developers and OEMs to use a single version without tracking unfinished future work just to keep up. Other parts of the Android system that aren't related to application compatibility are developed in the open, however. It's our intention to move more of these parts to open development over time.

When are source code releases made?

When they are ready. Releasing the source code is a fairly complex process. Some parts of Android are developed in the open, so that source code is always available. Other parts are developed first in a private tree, and that source code is released when the next platform version is ready.

In some releases, core platform APIs will be ready far enough in advance that we can push the source code out for an early look prior to the device's release; however in other releases, this isn't possible. In all cases, we release the platform source when we feel the version has stabilized enough, and when the development process permits.

What is involved in releasing the source code for a new Android version?

Releasing the source code for a new version of the Android platform is a significant process. First, the software gets built into a system image for a device and put through various forms of certification, including government regulatory certification for the regions the phones will be deployed. It also goes through operator testing. This is an important phase of the process, since it helps shake out a lot of software bugs.

Once the release is approved by the regulators and operators, the manufacturer begins mass producing devices, and we turn to releasing the source code.

Simultaneous to mass production, the Google team kicks off several efforts to prepare the open source release. These efforts include making final API changes, updating documentation (to reflect any modifications that were made during qualification testing, for example), preparing an SDK for the new version, and launching the platform compatibility information.

Also included is a final legal sign-off to release the code into open source. Just as open source contributors are required to sign a Contributors License Agreement attesting to their intellectual property ownership of their contribution, Google too must verify it is clear to make contributions.

From the time mass production begins, the software release process usually takes around a month. This often places source code releases around the same time the devices reach users.

How does the AOSP relate to the Android Compatibility Program?

The Android Open Source Project maintains the Android software, and develops new versions. Since it's open source, this software can be used for any purpose, including to develop devices that are not compatible with other devices based on the same source.

The function of the Android Compatibility Program is to define a baseline implementation of Android that is compatible with third-party apps written by developers. Devices that are "Android compatible" may participate in the Android ecosystem, including Google Play; devices that don't meet the compatibility requirements exist outside that ecosystem.

In other words, the Android Compatibility Program is how we separate "Android-compatible devices" from devices that merely run derivatives of the source code. We welcome all uses of the Android source code, but only Android-compatible devices -- as defined and tested by the Android Compatibility Program -- may participate in the Android ecosystem.

How can I contribute to Android?

There are a number of ways you can contribute to Android. You can report bugs, write apps for Android, or contribute source code to the Android Open Source Project.

There are some limits to the kinds of code contributions we are willing or able to accept. For instance, someone might want to contribute an alternative application API, such as a full C++-based environment. We would decline that contribution, since Android encourages applications to be run in the ART runtime. Similarly, we won't accept contributions such as GPL or LGPL libraries that are incompatible with our licensing goals.

We encourage those interested in contributing source code to contact us via the channels listed on the Android Community page prior to beginning any work. You can find more information on this topic from the Contributingpage.

How do I become an Android committer?

The Android Open Source Project doesn't really have a notion of a "committer". All contributions -- including those authored by Google employees -- go through a web-based system known as "gerrit" that's part of the Android engineering process. This system works in tandem with the git source code management system to cleanly manage source code contributions.

Once submitted, changes need to be accepted by a designated Approver. Approvers are typically Google employees, but the same approvers are responsible for all submissions, regardless of origin.

You can find more information on this topic at the Submitting Patches page.

0 0