개발?세발?

Licenses

라이센스

The Android Open Source Project uses a few open source initiative approved open source licenses for our software.

안드로이드 오픈소스 프로젝트는 오픈소스 이니셔티브에 인증된 오픈소스 라이센스를 사용한다.

Android Open Source Project Licenses

안드로이드 오픈소스 라이센스

The preferred license for the Android Open Source Project is the Apache Software License, Version 2.0 ("Apache 2.0"), and the majority of the Android software is licensed with Apache 2.0. While the project will strive to adhere to the preferred license, there may be exceptions that will be handled on a case-by-case basis. For example, the Linux kernel patches are under the GPLv2 license with system exceptions, which can be found on kernel.org.

안드로이드 오픈소스 프로젝트는 아파치 소프트웨어 라이센스, 버전2.0 ("아파치 2.0")을 따른다. 그리고 많은 안드로이드 소프트웨어는 아파지 2.0에 허가된다. 프로젝트가 라이센스에 따르도록 하는 동안, 각 상황별로 다루어지게 될 것이다. 예를 들어 리눅스 커널 패치는 system exceptions(시스템 익셉션)과 GPLv2 라이센스를 따른다. kernel.org에서 찾을 수 있다.

Contributor License Agreement

컨티리뷰터 라이센스 동의

All individual contributors (that is, contributors making contributions only on their own behalf) of ideas, code, or documentation to the Android Open Source Project will be required to complete, sign, and submit an Individual Contributor License Agreement. The agreement can be executed online through the code review tool. The agreement clearly defines the terms under which intellectual property has been contributed to the Android Open Source Project. This license is for your protection as a contributor as well as the protection of the project; it does not change your rights to use your own contributions for any other purpose.

모든 개별적인 기여자(그들의 이익을 위한 기여자)의 안드로이드 오픈소스 프로젝트를 위한 아이디어, 코드, 또는 문서는 개별 컨트리뷰터 라이센스 동의서 작성하고, 서명이 되어 제출되어야 한다. 동의서는 코드 리뷰 툴를 통해 온라인상에서 실행된다. 동의서는 지적인 재산을 안드로이드 오픈소스 프로젝트에 기여한다는 조건을 정의한다. 이 라이센스는 당신을 컨트리뷰터로써 보호하고, 프로젝트의 보호를 위한 것이지, 당신이 기여한 당신의 권리를 어느 목적으로든 바꾸겠다는 것이 아니다.

For a corporation (or other entity) that has assigned employees to work on the Android Open Source Project, a Corporate Contributor License Agreement is available. This version of the agreement allows a corporation to authorize contributions submitted by its designated employees and to grant copyright and patent licenses. Note that a Corporate Contributor License Agreement does not remove the need for any developer to sign their own Individual Contributor License Agreement as an individual. The individual agreement is needed to cover any of their contributions that are not owned by the corporation signing the Corporate Contributor License Agreement.

안드로이드 오픈소스 프로젝트에 일을 할 직원을 할당한 기업(또는 다른 독립체)은 기업 컨트리뷰터 라이센스 동의서를 작성해야한다. 이 버전의 동의서는 기업의 지정된 직원이 기여(코드, 문서 기타 등등) 제출을 허락하고, 저작권과 특허권을 허가한다. 기업 컨트리뷰터 라이센스 동의서는 모든 개발자들의 개별 컨트리뷰터 라이센스 동의서를 개인적으로 서명할 필요를 제거하지 않는다. 개별 동의서는 기업에 의한 기여를 그들이 포함하도록 필요하다.

Please note we based our agreements on the ones the Apache Software Foundation uses, which can be found on the Apache web site.

우리들의 동의서는 아파치 웹사이트에서 찾을수 있는 아파치 소프트웨어 재단을 사용한다.  

Why Apache Software License?

왜 아파치 소프트웨어 라이센스인가?

We are sometimes asked why Apache Software License 2.0 is the preferred license for Android. For userspace (that is, non-kernel) software, we do in fact prefer ASL2.0 (and similar licenses like BSD, MIT, etc.) over other licenses such as LGPL.

우리는 종종 왜 아파치 소프트웨어 라이센스 2.0이 안드로이드 라이센스에 우선시 되는 라이센스인지 질문을 받는다. 사용자공간(커널이 아닌) 소프트웨어에서, 우리는 ASL2.0(그리고 BSD, MIT 등과 같은 비슷한 라이센스)를 LGPL과 같은 다른 라이센스보다 선호한다.

Android is about freedom and choice. The purpose of Android is promote openness in the mobile world, and we don't believe it's possible to predict or dictate all the uses to which people will want to put our software. So, while we encourage everyone to make devices that are open and modifiable, we don't believe it is our place to force them to do so. Using LGPL libraries would often force them to do just that.

안드로이드는 자유와 선택에 관한 것이다. 안드로이드의 목적은 모바일 세계에서의 솔직함을 지향하는 것이다. 우리는 사용자들이 우리의 소프트웨어를 사용하는 것을 예측하고, 영향을 미치는 것을 불가능 하다고 믿는다. 즉, 우리가 모두에게 공개되고 변경가능한 기기들을 만들도록 하는 동안 그들을 그렇게 하도록 하는 것이 우리들의 역활이라고 생각하지 않는다. LGPL 라이브러리를 사용하는 것은 종종 그들을 단지 그것을 하게 만든다.

Here are some of our specific concerns:

아래는 우리가 걱정하는 것들이다 :

• LGPL (in simplified terms) requires either: shipping of source to the application; a written offer for source; or linking the LGPL-ed library dynamically and allowing users to manually upgrade or replace the library. Since Android software is typically shipped in the form of a static system image, complying with these requirements ends up restricting OEMs' designs. (For instance, it's difficult for a user to replace a library on read-only flash storage.)
• LGPL requires allowance of customer modification and reverse engineering for debugging those modifications. Most device makers do not want to have to be bound by these terms. So to minimize the burden on these companies, we minimize usage of LGPL software in userspace.
• Historically, LGPL libraries have been the source of a large number of compliance problems for downstream device makers and application developers. Educating engineers on these issues is difficult and slow-going, unfortunately. It's critical to Android's success that it be as easy as possible for device makers to comply with the licenses. Given the difficulties with complying with LGPL in the past, it is most prudent to simply not use LGPL libraries if we can avoid it.

• 간단히 LGPL는 : 어플리케이션으로 소스코드 배송, 제공하기 위해 작성된 소스코드, 또는 동적으로 LGPL라이브러리에 연결하고, 유저가 수동으로 업그레이드 또는 라이브러리를 바꾸는 것을 허락하는 것중 하나를 요구한다. 안드로이드 소프트웨어가 일반적으로 고정된 시스템 이미지로부터 배송되었을 때 부터, OEM업체의 제한된 디자인 자격요건을 따른다.(대신, 읽기만 가능한 플레시 저장소에 라이브러리를 교체하기 어렵다.)
• LGPL은 사용자 수정사항과 리버스엔지니어링을 그들의 수정사항의 디버깅을 위해 필요로한다. 대부분의 기기 제조사들은 이러한 제약에 구속되기를 원치 않는다. 그래서 기업들의 짐을 최소화하고, 우리는 사용자공간의 LGPL소프트웨어 사용을 최소화한다.
• 지금까지 LGPL 라이브러리는 소규모기기 제조사와 어플리케이션 개발자들의 많은 수의 규정 준수 문제의 원인이 되었다. 불행하게도, 엔지니어링교육을 하기에는 이런 이슈들은 어렵고 느리다. 이것은 가능한 쉽게 기기 제조사들이 라이센스를 따르도록 할려는 안드로이드 성공의 위협적이다. 과거의 LGPL를 따르는 것이 어려운 것은, 만약 그것을 피할 수 있다면, 가장 신중하게 간단히 LGPL 라이브러리를 사용하지 않는 것이다.

Brand Guidelines

브랜드 가이드라인

The "Android" name, the  logo, the "Google Play" brand, and other trademarks are property of Google Inc. and not part of the assets available through the Android Open Source Project.

"Android" 명칭,  로고, "Google Play" 브랜드, 그리고 다른 트레이드마크(상표)는 구글의 재산이다. 재산의 일부는 안드로이드 오픈소스 프로젝트에서 사용가능하다.

If you are interested in using these brands to indicate their association with your device, adhere to the guidelines on this page. These guidelines correspond to and complement the Brand Guidelines for Android App Developers and Google Brand Permissions.

만약 이 브랜드들을 당신의 장치나 협회에서 사용하고 싶다면, 가이드라인에 이 페이지를 추가시켜야 한다. 그 가이드라인들은 Brand Guidelines for Android App Developers와 Google Brand Permissions에 부합하고, 일치한다.

Android

안드로이드

Here are manufacturer guidelines for the Android brand and related assets.

아래에는 안드로이드 브랜드와 자산을 위한 제조사 가이드 라인이다.

Android in text

안드로이드 글자(안드로이드로 적힌 문자, 텍스트)

• Android™ should have a trademark symbol the first time it appears in a creative.
• "Android" should always be capitalized and is never plural or possessive.
• The use of “Android” on hardware, packaging or marketing materials of device is restricted to Android-compatible devices only.
• "Android” should be used only as a term to refer to the operating system (OS) of your device. If you are unsure whether your use meets our guidelines, follow this simple test: If you can replace "Android" with "the Android platform" and the text still makes sense, then you may use this term.
• Incorrect: "Android XBrand Phone"
• Correct: "XBrand phone on Android"
• You may use “with Android” in plain black text with your logo. If used with your logo, "with Android" should be no larger than 90% of your logo’s size. First or most prominent instance of this use should be followed by a ™ symbol.
• Android may be used only as a descriptor, as long as it is followed by a proper generic term. It cannot be framed as the product name or brand of your device.
• Incorrect: "Android XBrand Phone"
• Correct: "Android mobile device"

• Android™은 최초로 만들어진 상표이다.
• "Android"는 항상 대문자여야 하고, 결코 복수형이 될수 없고 소유할수 없다.
• "Android"를 기기의 하드웨어, 포장지, 마켓팅 자료에 사용하기 위해서는 안드로이드에 호환되는 기기로 제한한다.
• "Android"라는 용어는 장비의 운영체제(OS)를 제공함으로써만 사용되어져야한다. 만약 가이드라인에 적절한지 확실할 수 없다면 다음의 간단한 테스트를 해보아라 : 만약 "Android"를 "the Android platform"으로 바꾸어도 말이 된다면, 이 용어를 사용 해도 될 것이다.
• 불가능: "Android XBrand Phone"
• 가능: "XBrand phone on Android"
• 만약 "with Android"를 검은 글자로 당신의 로고와 사용할수 있다. 만약 당신의 로고와 사용 할 경우 "with Android"는 당신의 로고 90%보다 크면 안된다. 가장 중요한 사항은 ™ 바로 뒤에 사용해야 한다.
• 안드로이드는 완벽한 명칭 뒤에 기술자로써만 사용가능하다. 기기의 브랜드나 제품 명칭의 틀로써 사용할 수 없다.
• 불가능: "Android XBrand Phone"
• 가능: "Android mobile device"

Android is a trademark of Google Inc.

모든 커뮤니티에서는 무조건 안드로이드 이름을 아래의 문구와 같이 명시하여야 한다.

안드로이드는 구글의 상표이다.

Acceptable example

사용가능 예

Unacceptable example

사용 불가능 예

Android logo

안드로이드 로고

Unless expressly authorized by Google through written agreement, the Android logo and custom typeface may not be used (with or without the Android robot).

구글에 의해서 허가를 받지 않은 개인적인 형식의 (안드로이드 로봇이 있던지 없던지) 안드로이드 로고는 사용할 수 없다. 

Android Robot

안드로이드 로봇

Google Play

구글 플레이

Use of the “Google Play” name and the Google Play Store icon on the packaging of the hardware, marketing materials of the hardware, or the hardware itself is allowed only on devices licensed to access Google Play. For a list of devices licensed to use Google Play, refer to Supported devices.

하드웨어 패키징, 하드웨어 마켓팅 자료, 또는 하드웨어 자체에 "Google Play" 이름과 구글 프레이 스토어 아이콘을 사용하기 위해서는 구글 플레이에 접근 허가를 받은 디바이스여아 한다. 구글플레이를 사용 할 수 있는 기기 리스트는 지원되는 기기지원되는 기기를 참조 하면 된다.

Other Brand

다른 브랜드

Android Auto, Android TV, and Android Wear are brands owned by Google. These brands require Google proprietary software that runs on top of Android and is available only through a license with Google. For information on how to request a license, see Contact Us.

안드로이드 오토, 안드로이드 티비 그리고 안드로이드 웨어는 구글의 브랜드이다. 이 브랜드들은 안드로이드 위에서 실행되는 구글의 소프트웨어를 요구하고, 구글의 허가를 통해 사용 가능하다. 사용허가 신청 정보는 다음 링크를 통해 확인 할 수 있다.

Questions

질문

For additional brand usage information, contact the Android Partner Marketing team by submitting the Partner Brand Inquiry Form.

추가적인 브랜드 사용 정보를 위해서는 안드로이드 파트너 마켓팅 팀에 파트너 브랜드 질문서를 제출하면 된다.

원문 : https://source.android.com/source/roles.html

Project Roles

프로젝트 역할

The Android Open Source Project (AOSP) includes individuals working in a variety of roles. Google is responsible for Android product management and the engineering process for the core framework and platform; however, the project considers contributions from any source, not just Google. This page describes the kinds of roles that interested parties can take on.

안드로이드 오픈소스 프로젝트에 각양각색의 역활을 개개인이 담당해 왔다. 구글은 안드로이드 제품 관리와 중요 프레임워크와 플랫폼의 프로세스 인지니어링을 책임진다. 그러나 구글 뿐만 아니라 많은 참여가 모든 소스에서 있었다. 이 페이지는 참여 가능한 흥미로운 역활의 종류 부분을 설명 한다.

Contributor

컨트리뷰터

"Contributors" are those making contributions to the AOSP source code, including both employees of Google or other companies, as well as individual developers who are contributing to Android on their own behalf. There is no distinction between contributors who are employed by Google and those who are not; all engineers use the same tools (git, repo, and gerrit), follow the same code review process, and are subject to the same requirements on code style and so on.

"컨트리뷰터"는 구글 또는 다른 기업 직원과 자신의 이익을 위한 개인적인 개발자들로 AOSP 소스 코드에 기여하는 사람들이다. 구글 직원가 그렇지 않은 사람들의 차이는 없다. 모든 인지니어들은 같은 툴(git, repo와 gerrit)을 사용하고, 같은 코드 리뷰 절차와 같은 코드 스타일을 따른다.

Developer

디벨로퍼

"Developers" are engineers writing applications that run on Android devices. There is often little difference in skillset between a developer and a contributor. But AOSP uses "developer" to distinguish between engineers using the platform and those contributing to it. Developers (along with users) are the "customers" of the platform the contributors create. As such, we talk about developers a lot, though this isn't technically a separate role in the AOSP per se.

"디벨로퍼"는 안드로이드 기기에서 실행되는 어플리케이션을 작성하는 엔지니어들이다. 디벨로퍼와 컨트리뷰터 사이에는 스킬셋에서 약간의 다른점이 종종있다. 하지만 AOSP에서는 "디벨로퍼"를 플랫폼을 사용하는 엔지니어 인지 기여하는 엔지니어인지로 구분 짓는다. 디벨로퍼(사용자와 같이)는 컨트리뷰터가 만든 플랫폼의 "커스터머(소비자)"이다.  우리는 개발자를 많이 말하지만, AOSP 자체의 기술적으로 나눈 것은 아니다.

Verfier

버리피어

"Verifiers" are responsible for testing change requests. After individuals have submitted a significant amount of high-quality code to the project, the project leads might invite them to become verifiers.

Note: At this time, verifiers act similarly to approvers.

"버리피어"는 변화된 요청을 테스트한다. 개인이 중요한 고난이도 코드를 제출을 하면, 프로젝트 리더는 그들을 버리피어로 초대 한다.

추신 : 버리피어는 어프로버와 비슷하다.

Approver

어프로버

"Approvers" are experienced members of the project who have demonstrated their design skills and have made significant technical contributions to the project. In the code-review process, an approver decides whether to include or exclude a change. Project leads (who are typically employed by Google) choose the approvers, sometimes promoting to this position verifiers who have demonstrated their expertise within a specific project.

"어프로버"는 프로젝트에서 디자인 스킬을 입증했거나, 중요한 기술적 기여자들이다. 코드 검토 과정에서 어프로버는 변화된 코드를 포함 시킬지 제외시킬지 결정을 한다. 프로젝트 리더(구글 직원)가 어프로버를 선택을 한다. 종종, 프로젝트의 전문지식을 입증받은 버리피어들이 홍보 하기도 한다.

Project Lead

프로젝트 리드

Android consists of a number of sub-projects; you can see these in the git repository as individual .git files. "Project leads" are senior contributors who oversee the engineering for individual Android projects. Typically these project leads are Google employees. A project lead for an individual project is responsible for the following:

안드로이드는 많은 서브 프로젝트들로 구성되어 있다. 깃 저장소에서 개별적으로 확인 할 수 있다. "프로젝트 리더"는 개별적인 안드로이드 엔지니어링을 총괄하는 중요한 콘트리뷰터이다. 특별히 안드로이드 프로젝트에서는 구글 직원들이다. 개별적인 프로젝트의 프로젝트 리더는 아래의 책임이 있다.

• Lead all technical aspects of the project, including the project roadmap, development, release cycles, versioning, and quality assurance (QA).

• Ensure the project is tested by QA in time for scheduled Android platform releases.

• Designate Verifiers and Approvers for submitted patches

• Be fair and unbiased while reviewing changes. Accept or reject patches based on technical merit and alignment with the Android strategy.

• Review changes in a timely manner and make best efforts to communicate when changes are not accepted.

• Optionally maintain a web site for the project for information and documents specific to the project.

• Act as a facilitator in resolving technical conflicts.

• Be a public face for the project and the go-to person for questions related to the project.

• 프로젝트 로드맵, 개발, 릴리즈 사이클, 버전 관리, 품질 관리(QA)을 포함한 프로젝트의 기술적인 측면을 이끌어야한다.
• 정해진 안드로이드 플랫폼 릴리즈를 위해 품질 관리로써 프로젝트 테스트를 확실히 해야한다.
• 제출된 부분들을 위해 버리피어와 어프로버를 지정해야 한다.
• 코드 검토는 공평하고 편견없이 한다. 패치 내용의 인정과  거절은 기술적인 이익과 안드로이드 정책의 일정함을 기준으로 한다.
• 코드 검토는 일정한 방식으로 하고, 거절된 코드는 정중히 전달한다.
• 프로젝트 정보가 있는 웹사이트와 프로젝트에 관한 문서는 선택적으로 유지시킨다.
• 기술적 문제를 풀수 있게 협력한다.
• 프로젝트에 대해 일반적인 입장을 취하고, 프로젝트에 대한 질문은 인간적으로 대한다.

Codenames, Tags, and Build Numbers

코드네임, 태그, 그리고 빌드 번호.

At a high level, Android development happens around families of releases, which use code names ordered alphabetically after tasty treats.

높은 레벨의 안드로이드 개발은 알파벳 오름차순으로 정렬된 음식이름의 코드네임으로 된 배포단위가 일어 났다.

Platform Codenames, Versions, API Levels, and NDK Releases

플랫폼 코드네임, 버전, API 레벨 그리고 NDK 배포

The code names match the following version numbers, along with API levels and NDK releases provided for convenience:

코드 네임은 버전 넘버와 함께 편의를 위해 제공되는 API 레벨, NDK배포와 매칭이 된다.

Starting with Cupcake, individual builds are identified with a short build code, e.g. FRF85B.

Cipcake부터 개별적인 빌드는 FRF85B와 같은 짧은 빌드 코드를 가지게 되었다.

The first letter is the code name of the release family, e.g. F is Froyo.

첫 글자는 배포 단위의 코드네임이다. 예를 들어 F는 Froyo이다.

The second letter is a branch code that allows Google to identify the exact code branch that the build was made from, and R is by convention the primary release branch.

두 번째 글자는 구글이 확실히 어느 부분에서 시작된 코드인지 확인 할 수 있는 브랜치 코드이다. R은 규칙에 의한 주요 릴리즈 지점이다.

The next letter and two digits are a date code. The letter counts quarters, with A being Q1 2009. Therefore, F is Q2 2010. The two digits count days within the quarter, so F85 is June 24 2010.

다음 글자와 두 숫자는 날짜 코드이다. 글자는 1분기당 1씩 증가하며 A는 2009년 1분기이다. 그러므로 F는 2010년 2분기이다. 두 숫자는 분기내 하루를 나타낸다. 그러니까, F85는 2010년 6월 24일 이다.

Finally, the last letter identifies individual versions related to the same date code, sequentially starting with A; A is actually implicit and usually omitted for brevity.

마지막으로, 마지막 글자는 같은 날에 개별적인 구분자이다. A부터 연속적으로 지정되며 보통 A는 생략된다.

The date code is not guaranteed to be the exact date at which a build was made, and it is common that minor variations added to an existing build re-use the same date code as that existing build.

날짜 코드는 정확히 빌드된 날짜에 맞춰 붙는 것이 아니다. 보통 이미 빌드된 코드의 같은 날짜 코드를 마이너한 변화를 추가하여 재 빌드한다.

SourceCode Tags and Builds

소스코드 태그와 빌드

Starting with Donut, the exact list of tags and builds is in the following table. Factory images and binaries for Nexus devices can be downloaded from:

Donut부터 태그와 빌드 리스트는 아래 테이블에 있다. 공장이미지와 넥서스 바이너리는 아래 링크에서 다운 받을 수 있다.

https://developers.google.com/android/nexus/images

https://developers.google.com/android/nexus/drivers

(테이블은 여기를 참조해주세요. 너무 태이블이 커서.....)

The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev, jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev, kitkat-dev represent development branches that do not exactly match configurations that were tested by Google. They might contain a variety of changes in addition to the official tagged releases, and those haven't been as thoroughly tested.

froyo, gingerbread, ics-mr0, ics-mr1, jb-dev, jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev, kitkat-dev는 구글이 테스트한 것과 정확히 일치하지 않는 개발 지점의 대표한다. 그들은 아마 공식으로 이름이 붙은 배포판에 다양한 변화를 추가한 것이고, 정밀한 테스트가 되지 않았을 것이다.

To differentiate between releases, you may obtain a list of changes associated with each project by issuing the following command and passing it the two branch tags:

배포된 것들 사이의 프로젝트 별 이슈 사항 및 두 지점의 다른 점은 아래의 명령어를 통해서 확인 할 수 있다.

$ repo forall -pc 'git log --no-merges --oneline branch-1..branch-2'

For example:
예를 들어 :

$ repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1'

And to output to a text file:
그리고 text 파일로 출력 할 수 있다.

repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1' > /tmp/android-4.4.2_r2-an

Honeycomb GPL Modules

Honeycomb GPL 모듈

For Honeycomb, the entire platform source code isn't available. However, the parts of Honeycomb licensed under the GPL and LGPL are available under the following tags:

Honeycomb의 전체 플렛폼 소스코드는 사용 할 수 없다. 그러나, GPL과 LGPL의 라이센스 Honeycomb중 아래에 나타난 것들은 사용 할 수 있다.

There is no manifest that contains exactly those. However, there are manifests that allow building those components. The following commands work for 3.0_r1.1, and using other versions can be done by switching the git checkout paramater, and if necessary the -m parameter in repo init. The git checkout command outputs an error for the non-GPL projects, where it can't find the tag in question.

그것들은 정확히 그것들을 나타내는 것이 아니다. 그러나 그것들의 컴포넌트를 빌딩 한 것이다. 아래의 명령어는 3.0_r1.1(git 체크아웃 파라미터를 변경 하면 다른 버전도 동작한다.) 버전을 위한 것이고, repo init(repo 초기화)가 필요하다면 -m를 같이 써도 된다. 위의 표에 Tag로 나타나지 않은 GPL 프로젝트가 아닌 git 체크아웃 명령어는 에러가 난다.

$ repo init -b master -m base-for-3.0-gpl.xml
$ repo sync
$ repo forall -c git checkout android-3.0_r1.1

원문 : https://source.android.com/source/code-lines.html

Codelines, Branches, and Releases

코드라인, 브랜치, 그리고 릴리즈

The Android Open Source Project (AOSP) maintains a complete software stack to be ported by OEMs and other device implementors and run on their own hardware. To maintain the quality of Android, Google has contributed full-time engineers, product managers, user interface designers, quality assurance testers, and all the other roles required to bring modern devices to market.

안드로이드 오픈소스 프로젝트는 모든 안드로이드기기와 하드웨어를 위해 완벽한 소프트웨어로 유지 된다. 안드로이드의 품질유지를 위해, 구글은 항시 엔지니어와 제품 매니저와 UI 디자이너, 품질테스터를 제공해 왔고, 현대 기기들을 시장에 내놓기 위한 모든 역활을 해왔다.

Accordingly, we maintain a number of "code lines" to clearly separate the current stable version of Android from unstable experimental work. We roll the open source administration and maintenance of the Android code lines into the larger product development cycle.

그에 따라, 우리는 실험적 불안정한 많은 "코드라인"에서 완벽하게 안정적인 버전의 안드로이드를 구분지었다.  우리는 더 큰 안드로이드 코드라인 개발 사이클을 유지하고 관리하는 역활을 했다.

The chart below depicts at a conceptual level how AOSP manages code and releases. We're referring to these as "code lines" instead of "branches" simply because at any given moment there may be more than one branch for a given "code line". For instance, when a release is cut, it may or may not become a new branch based on the needs of the moment.

아래의 차트는 AOSP(Android Open Source Project)를 어떻게 코드관리와 배포를 하는지에 대한 컨셉을 나타난 것이다.  우리가 "branche" 대신 "코드라인" 이라고 하는 이유는 간단하게 주어진 "코드라인"에 하나이상의 브랜치(branch)가 있기 때문이다. 예로, 배포가 끝나면, 필요에 따라 새로운 브랜치(branche)가 되거나 아닐수 있다.

1. At any given moment, there is a current latest release of the Android platform. This typically takes the form of a branch in the tree.
2. Device builders and contributors work with the current latest release, fixing bugs, launching new devices, experimenting with new features, and so on.
3. In parallel, Google works internally on the next version of the Android platform and framework according to the product's needs and goals. We develop the next version of Android by working with a device partner on a flagship device whose specifications are chosen to push Android in the direction we believe it should go.
4. When the "n+1"th version is ready, it will be published to the public source tree and become the new latest release.

1. 안드로이드 플랫폼의 최신 배포가 있는 모든순간에, 그건 일반적으로 트리에 가지(브랜치 branch)형태로 있다.
2. 기기 제조사와 컨트리뷰터(기여자, 오픈소스프로젝트에 참여하는 방식중 하나)는 최신 배포버전으로 버그 수정, 새기기에 실행시키기, 새로운 기능 실험하기 등을 한다.
3. 동시에, 구글은 내부적으로 안드로이드 플랫폼과 프레임워크를 제품의 요구와 목표에 맞춰 다음 버전을 준비한다. 우리는 우리의 의도와 같은 협력사의 주력 기기를 선택하여 안드로이드의 다음 버전을 개발한다.
4. 다음 차기버전이 준비가 되면, 공개 소스 트리에 게재가 되고, 최신버전으로 배포가 된다.

Terms and Caveats

약관 및 주의사항

• A release corresponds to a formal version of the Android platform, such as 1.5, 2.1, and so on. Generally speaking, a release of the platform corresponds to the version in the SdkVersion field of AndroidManifest.xml files and defined within frameworks/base/api in the source tree.
• An upstream project is an open source project from which the Android stack is pulling code. These include obvious projects such as the Linux kernel and WebKit. Over time we are migrating some of the semi-autonomous Android projects (such as ART, the Android SDK tools, Bionic, and so on) to work as "upstream" projects. Generally, these projects are developed entirely in the public tree. For some upstream projects, development is done by contributing directly to the upstream project itself. See Upstream Projects for details. In both cases, snapshots will be periodically pulled into releases.
• At all times, a release code-line (which may actually consist of more than one actual branch in git) is considered the sole canonical source code for a given Android platform version. OEMs and other groups building devices should pull only from a release branch.
• "Experimental" code-lines are established to capture changes from the community so they can be iterated on with an eye toward stability.
• Changes that prove stable will eventually be pulled into a release branch. Note this applies only to bug fixes, application improvements, and other changes that do not affect the APIs of the platform.
• Changes will be pulled into release branches from upstream projects (including the Android "upstream" projects) as necessary.
• The "n+1"th version (that is, next major version of the framework and platform APIs) will be developed by Google internally. See About Private Codelines for details.
• Changes will be pulled from upstream, release, and experimental branches into Google's private branch as necessary.
• When the platform APIs for the next version have stabilized and been fully tested, Google will cut a release of the next platform version. (This specifically refers to a new SdkVersion.) This will also correspond to the internal code-line being made a public release branch, and the new current platform code-line.
• When a new platform version is cut, a corresponding experimental code-line will be created at the same time.

• 각 배포는 1.5버전, 2.1버전, 기타 버전 과 같이 안드로이드 플랫폼의 정식 버전에 해당한다. 일반적으로, 플랫폼 배포는 AndroidManifest.xml 파일의 SdkVersion 필드의 버전에 해당하고, 소스트리의 frameworks/base/api 에 정의된다.
• 업스트림 프로젝트는 안드로이드 저장소에서 당겨온 코드의 오픈소스 프로젝트입니다(ㅠㅠ이이상 매끄럽게 못바꾸겠네요). 그것들은 리눅스커널 과 웹킷과 같은 프로젝트를 포함합니다. 현재까지 우리는 반독립적인 안드로이드 프로젝트인 ART와 안드로이드 SDK툴, Bionic 기타등등을 "업스트림" 프로젝트로 이동시켰다. 보통 그 프로젝트들은 전적으로 공개트리에서 개발되어 왔다. 기여로 완성된 몇 프로젝트는 곧장 업스트림 프로젝트로 간다. 자세한 사항은 업스트림 프로젝트에서 확인 할 수 있다. 두 가지 경우에 스냅샷은 정기적으로 배포된다.
• 항상 깃에 올라온 실제 하나 이상의 소스코드들은 안드로이드 플랫폼 버전의 소스코드로 고려된다. 제조사들이 만든 기기들은 브랜치에서 가져온 소스코드를 사용한다.
• "실험적인" 코드라인들의 변경사항들을 인지한 커뮤니티들이 안정성에 눈을 돌리게 한다.
• 안정성이 검증된 변화들은 결국 release 브랜치에 올라가게 된다. 그 적용사항들은 버그 수정, 어플리케이션 향상 그리고 플랫폼의 API에 영향을 끼치지 않는 것들 이다.
• 변경사항은 안드로이드 "업스트림" 프로젝트를 포함한 업스트림 프로젝트의 필요에 release 브랜치에 반영 될 것이다.
• 프레임워크 와 플랫폼 API의 중요(메이저) 차기버전은 구글 내부적으로 개발이 된다. 자세항 사항은 About Private Codelines에서 확인 할 수 있다.
• 업스트림, 배포 그리고 실험적인 브랜치의 변경사항들은 필요에 따라 구글 내부 브랜치에 반영된다.
• 차기 버전을 위해 플랫폼 API들이 안정화가 되고, 충분히 테스트가 되었을 때, 구글은 다음 버전의 배포를 끊을 것이다.(그것은 분명하게 SdkVersion를 나타낸다.) 그것은 또한, 내부 코드가 되고, 공개 release 브랜치를 만들고, 새로운 현재 플랫폼 코드라인에 해당한다.
• 새로운 플랫폼 버전이 끊어지면, 실험적인 코드라인에 해당하는 브랜치가 만들어 질것이다.

About Private Codeline

비공개 코드라인에 대해서.

The source management strategy above includes a code-line that Google will keep private. The reason for this is to focus attention on the current public version of Android.

코드라인을 포함한 소스 관리 기법은 구글내에 비공개로 있다. 그이유는 현재 공개된 버전의 안드로이드에 집중을 하게 하기 위함이다.

OEMs and other device builders naturally want to ship devices with the latest version of Android. Similarly, application developers don't want to deal with more platform versions than strictly necessary. Meanwhile, Google retains responsibility for the strategic direction of Android as a platform and a product. Our approach focuses on a small number of flagship devices to drive features while securing protections of Android-related intellectual property.

제조사들은 자연적으로 안드로이드의 최신버전와 구매할 수 있는 기기를 원한다. 비슷하게, 앱 개발자들은 많은 플랫폼에서 보단 엄격한 필요(적은 수의 플랫폼)를 원한다. 그동안 구글은 안드로이드의 플랫폼과 제품의 전략적인 방향을 책임졌다. 우리는 안드로이드에 대한 지적 재산권의 보호를 하며, 특색을 가진 적은 수의 주요 기기들에 집중을 한다.

As a result, Google frequently has possession of confidential information from third parties. And we must refrain from revealing sensitive features until we've secured the appropriate protections. In addition, there are real risks to the platform arising from having too many platform versions extant at once. For these reasons, we have structured the open source project -- including third-party contributions -- to focus on the currently-public stable version of Android. "Deep development" on the next version of the platform will happen in private until it's ready to become an official release.

그 결과, 구글은 자주 써드파트(Third-Part)에서 기밀의 정보를 갖는다. 그리고 반드시 은밀하고 민감한 특징을 적절한 보호와 보안이 될때까지 숨긴다. 게다가, 한 번에 많은 과거 플랫폼 버전은 정말 위험한 일이 일어난다. 그러한 이유로, 우리는 써드파트 컨트리뷰트를 포함한 오픈소스프로젝트를 현재 공개된 안정적인 버전의 안드로이드에 집중하게 설계했다. 다음 버전으로 "깊은 개발(집중적인 개발)"은 공개적인 배포가 준비가 될때 까지 비밀리에 일어 날 것이다.

We recognize many contributors will disagree with this approach. We respect others may have a different point of view; however, this is the approach we feel is best, and the one we've chosen to implement.

우리는 많은 컨트리뷰터들이 이것에 동의하지 않는 다는 것을 인정한다. 우리는 다른 많은 관점을 존중한다. 하지만 이것이 최선이고, 우리가 선택해야할 일이다.

원문 : https://source.android.com/source/index.html

오타, 오역 지적 감사하게 받겠습니다. 일단 저도 공부차 하는 짓이라......... 매끄럽지 않는 번역 이해 바랍니다.

The Android Source Code

안도로이드 소스 코드

Android is an open source software stack created for a wide array of devices with different form factors. The primary purposes of Android are to create an open software platform available for carriers, OEMs, and developers to make their innovative ideas a reality and to introduce a successful, real-world product that improves the mobile experience for users.

안드로이드 오픈소스 소프트웨어는 다양한 장치들로 이루어진 많은 기기를 위해 만들어 졌다. 안드로이드의 주 목적은 항공사(운송사)와 제조사, 개발자들이 사용자들의 모바일 경험을 향상 시킬 그들의 혁신적인 아이디어를 현실로 만들고, 성공적인 실제품 위해 실용 가능한 오픈 소프트웨어 플랫폼을 만드는 것이다.

We also wanted to make sure there was no central point of failure, where one industry player could restrict or control the innovations of any other. The result is a full, production-quality consumer product with source code open for customization and porting.

또한 한 곳의 제조사가 독점하거나, 혁신들을 지배하는 일은 없게 확실하게 할 것이다. 그 결과 커스터마이징 및 포팅이 가능한 사용자 제품이 높은 생산 품질이 가능하다.

Governance Philosophy

관리 철학

Android was originated by a group of companies known as the Open Handset Alliance, led by Google. Today, many companies -- both original members of the OHA and others -- have invested heavily in Android. These companies have allocated significant engineering resources to improve Android and bring Android devices to market.

안드로이드는 구글의 Open Handset Alliance라는 구룹에서 비롯 되었다. 현재는 많은 기업들이 안드로이드에 집중적으로 투자하고 있다. 기업들은 안드로이드 향상에 많은 자원을 할당하고, 시장에 내놓는다.

The companies that have invested in Android have done so on its merits because we believe an open platform is necessary. Android is intentionally and explicitly an open source -- as opposed to a free software -- effort; a group of organizations with shared needs has pooled resources to collaborate on a single implementation of a shared product. The Android philosophy is pragmatic, first and foremost. The objective is a shared product that each contributor can tailor and customize.

기업들은 오픈 플랫폼이 꼭 필요하다고 믿기 때문에 곧 안드로이드에 대한 집중 투자는 기업들의 장점이 된다. 자유소프트웨어(free software)와 다른 안드로이드는 전적으로 각각의 기업들의 결과물의 합작으로 만들어진 오픈소스 프로젝트의 결과물이다. 안드로이드의 무엇보다도 최우선시 되는 철학은 실용성이다. 그 목적은 참여자들이 자유롭게 만든 결과물을 공유하는 것이다.

Uncontrolled customization can, of course, lead to incompatible implementations. To prevent this, the Android Open Source Project also maintains the Android Compatibility Program, which spells out what it means to be "Android compatible" and what is required of device builders to achieve that status. Anyone can (and will!) use the Android source code for any purpose, and we welcome all legitimate uses. However, in order to take part in the shared ecosystem of applications we are building around Android, device builders must participate in the Android Compatibility Program.

물론, 통제되지 않은 커스터마이징은 각각의 다른 길로 가게 된다. 그것을 막기위해서는 안드로이드 오픈소스 프로젝트는 "Android Compatibility Program"로도 남겨져야 한다. 그의미는 'Android compatibility(안드로이드 호환성)' 과 제조사들이 그 상황을 이행하는 것이다. 어느 누구든 안드로이드 소스코드를 무슨 목적으로 든 사용 할 수있고 그렇게 할 의무가 있다. 그리고 우리는 합당한 사용을 환영 할 것이다. 우리가 만들어 놓은 모든 안드로이드에 대한 어플리케이션 생태계와 기기 제조사는 안드로이드 프로젝트에 참여하여야 한다.

The Android Open Source Project is led by Google, who maintains and further develops Android. Although Android consists of multiple subprojects, this is strictly a project management technique. We view and manage Android as a single, holistic software product, not a "distribution", specification, or collection of replaceable parts. Our intent is that device builders port Android to a device; they don't implement a specification or curate a distribution.

안드로이드 오픈소스 프로젝트는 관리 및 개발을 하는 구글에 의해 진행 된다. 비록 안드로이드는 엄격한 관리기법으로 관리되는 수 많은 하위 프로젝트로 이루어 져있지만, 안드로이드는 나뉘어지고, 교체가 가능한 것들로 만들어진 것이 아닌, 단 하나의 소프트웨어 제품이다. 우리는 제조사들이 규격을 맞추지 않고, 책임을 다하지 않더라도 안드로이드를 기기에 포팅하기를 바란다.