개발?세발?

원문 : 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.

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