مطور Android Codelab

يمكنك المساعدة في تطوير نظام التشغيل الأكثر تثبيتًا في تاريخ Earth. نعم ، أنت هنا لبدء رحلة أن تصبح مهندسًا لمنصة Android.

على الرغم من أن المسار يمثل تحديًا ، إلا أن فريق Android يسعى جاهدًا لتبسيط رحلتك ، كل إصدار. ويقوم الفريق بإجراء تحسينات كل يوم من خلال العمل المباشر في مشروع Android مفتوح المصدر (AOSP).

لذا اجلس واشعل المحطة ودعنا نصنع التاريخ.

الأهداف

مهمة مختبر الرموز هذا ذات شقين:

  1. لإعطائك لمحة بسيطة عن سير عمل المطور بالنسبة لمهندسي Android الذين يعملون على النظام الأساسي (نظام التشغيل).
  2. شجعك على تقديم ملاحظات حول أدوات Android ووثائقه وسير عمل المطور.

المتطلبات الأساسية

قائمة متطلبات مختبر الرموز هذا مستمدة من تلك الخاصة بتطوير النظام الأساسي العام ( AOSP ). للحصول على معمل الرموز هذا ، قم بإعداد ما يلي:

بيئة

عادةً ما يقوم المستخدمون بالبناء والتطوير على محطة العمل مباشرةً. نظرًا لأنك قد تعمل في محطات طرفية مختلفة ، ولأن العديد من الأوامر المستخدمة خاصة بالمحطة ، فستحتاج إلى إعادة تشغيلها في كل جلسة طرفية. على وجه التحديد ، تتضمن هذه الأوامر source build/envsetup.sh وأوامر lunch .

قم بإعداد محطة العمل

  1. قم بتثبيت الحزم اللازمة على محطة العمل الخاصة بك.
  2. أثناء وجودك في محطة طرفية ، قم بتثبيت Repo واكتسب بيانات اعتماد لجميع مستودعات Git.

تهيئة ومزامنة الرمز

  1. انتقل إلى دليل منزلك:

    cd ~
    
  2. قم بإنشاء دليل فرعي محلي للعمل داخله:

    mkdir aosp
    
  3. انتقل إلى الدليل:

    cd aosp
    
  4. قم بتهيئة الفرع الرئيسي للشفرة المصدر لمستودع AOSP (الافتراضي):

    repo init -u https://android.googlesource.com/platform/manifest
    
  5. أدخل أو اقبل بيانات اعتماد Git (الاسم وعنوان البريد الإلكتروني).

  6. مزامنة كود المصدر:

    repo sync -j8
    

يمكن أن تستغرق عمليات المزامنة الأولية ساعة أو أكثر.

يتم تمثيل كل عملية سحب من الريبو بواسطة ملف بيان . يجوز أن يكون لديك أكثر من 1 إعادة تسجيل الخروج في وقت واحد ، طالما أنها موجودة في أدلة مميزة. لكن لاحظ أن كل عملية دفع وبناء تبلغ ما يقرب من 300 غيغابايت من الاستخدام (وتتزايد) ، لذلك إما أن تقصر نفسك على 2 من عمليات إعادة الشراء ، أو زد نظامك بمحرك أقراص ثانوي.

بناء الكود

لإنشاء Android ، يجب عليك تحديد نوع الجهاز المستهدف للبناء باستخدام أمر lunch . الهدف هو تبديل الجهاز ، مثل نموذج معين أو عامل الشكل.

هدف الجهاز المضمن أدناه ، aosp_cf_x86_64_phone-userdebug ، يمكّنك من إنشاء جهاز Android الظاهري Cuttlefish للاختبار بدون جهاز مادي.

لإنشاء جهاز مادي وتحديثه بدلاً من ذلك ، اختر هدفًا آخر واتبع الإرشادات الخاصة بالأجهزة الوامضة .

  1. قم بإعداد بيئتك لبناء أجهزة Android عن طريق تشغيل الأمر التالي من جذر الخروج من التعليمات البرمجية المصدر:

    source build/envsetup.sh
    
  2. قم بتمرير هدف البناء إلى أمر الغداء ، مثل هذا:

    lunch aosp_cf_x86_64_phone-userdebug
    
  3. قم ببناء الكود من أي مكان في عملية الدفع الخاصة بك باستخدام:

    m
    

توقع أن يستغرق البناء الأول ساعات. تستغرق عمليات الإنشاء اللاحقة وقتًا أقل بكثير.

قم بإنشاء مثيل Acloud

Acloud هي أداة سطر أوامر في AOSP تساعد المستخدمين في إنشاء أجهزة Android افتراضية ، في هذه الحالة Cuttlefish.

إذا كنت في نفس الجلسة الطرفية المستخدمة لإنشاء الكود ، فتابع. خلاف ذلك ، أعد تشغيل البرنامج النصي envsetup.sh ونفس أمر lunch الذي استخدمته هناك أولا. ثم

  1. قم بإنشاء مثيل محلي Acloud باستخدام:

    acloud create --local-image --local-instance
    
  2. اقبل التحديثات على الحزم المطلوبة.

  3. إذا طُلب منك ذلك ، قم بإعادة تشغيل محطة العمل الخاصة بك حتى تصبح جميع التغييرات سارية المفعول.

  4. حدد جهاز الحبار.

يجب أن يتم الترحيب بك بجلسة VNC تحتوي على جهاز Android!

يمكنك التفاعل مع الجهاز الافتراضي على محطة العمل الخاصة بك باستخدام الماوس ولوحة المفاتيح. يمكنك أيضًا متابعة النشاط داخل السجلات أثناء استخدام جهازك عن طريق استخدام أمر Android Debug Bridge (adb) logcat :

adb logcat

اصنع فرق

قم بتحديث الكود المصدري باتباع هذا المثال لقائمة التغيير .

  1. من جذر عملية الدفع الخاصة بك ( aosp/ directory) ، انتقل إلى frameworks/native :

    cd frameworks/native
    
  2. ابدأ مشروعًا مؤقتًا باستخدام هذا الأمر:

    repo start <some-name> .
    
  3. قم بتحرير SurfaceFlinger.cpp لتضمين التحديثات من قائمة التغيير في الموقع التالي:

    aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
    
  4. ابحث عن هذين السطرين:

    postFrame();
    postComposition();
    
  5. استبدل هذين السطرين بما يلي:

    postFrame();
    postComposition();
    mClientColorMatrix = mat4(vec4{1.0f, 0.0f, 0.0f, 0.0f}, vec4{0.0f, -1.0f, 0.0f, 0.0f},
                              vec4{0.0f, 0.0f, -1.0f, 0.0f}, vec4{0.0f, 1.0f, 1.0f, 1.0f});
    updateColorMatrixLocked();
    
  6. بناء الكود:

    m
    
  7. تحديث البناء على الجهاز:

    adb root
    adb remount
    adb sync
    adb reboot
    acloud reconnect
    
  8. إذا طُلب منك تحديد جهاز ، فاختر الجهاز الذي يعرض أقصر وقت انقضاء. (ربما يكون هذا هو الأخير في القائمة التي تراها.) لمشاهدة جميع مثيلات الجهاز الظاهري ، استخدم acloud list acloud وأوامر acloud list -v .

تحقق من أنك ترى تغيرًا في اللون على جهازك المحدد مشابهًا لما يظهر في الشكل 1.

Example of a successful color change

الشكل 1. ظهور الشاشة بعد تغيير اللون بنجاح

اختبر الكود الخاص بك

يستخدم هذا الجزء من codelab اختبارًا نموذجيًا موجودًا في شجرة المصدر وفشل. يستخدم هذا Atest لإجراء الاختبار محليًا واختبار الكود.

لاستخدام الاختبار ، اتبع التعليمات التالية:

  1. يجري:

    atest DevCodelabTest
    
  2. سوف يفشل الاختبار. لإصلاحها ، ابحث عن الكود المصدري للاختبار الفاشل:

    atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
    
  3. ثم انظر هنا

    platform_testing/tests/example/devcodelab
    
  4. للحصول على الملف المراد تحريره ، خذ اسم الاختبار في android.test.example.devcodelab.DevCodelabTest واستبدل ملف . مع / للحصول على هذه النتيجة:

    src/android/test/example/devcodelab/DevCodelabTest.java
    
  5. ثم قم بالتحرير

    platform_testing/tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
    

    ليحل محل

    Assert.assertTrue(false)
    

    مع

    Assert.assertTrue(true)
    
  6. شغّل الاختبار مرة أخرى للتحقق من حل المشكلة:

    atest DevCodelabTest
    

تحميل الكود الخاص بك للمراجعة

يبسط Repo استخدام Git من خلال تجميع أوامر مثل git clone للعمل عبر مستودعات Git (أو المشاريع) المتعددة في وقت واحد.

راجع أدوات التحكم في المصدر للحصول على لمحات عامة عن Git و Repo ، مع روابط إلى الوثائق الكاملة حول العمل مع كود مصدر Android. راجع مستودع AOSP للحصول على القائمة الكاملة لمشاريع Git والمشاريع الفردية (المسارات) للفروع المرتبطة بكل مشروع.

لمراجعة التعليمات البرمجية لمشاريعك في Git ، ستستخدم نظام مراجعة الكود المستند إلى الويب من Gerrit .

  1. بافتراض أنك أجريت التغييرات في frameworks/native ، قم بتشغيل هذه الأوامر لتحميلها:

    cd frameworks/native
    repo start codelab .
    git add .
    git commit
    
  2. لرسالة الالتزام الخاصة بك ، أدخل ما يلي:

    Android codelab change
    Test: manual atest
    
  3. قم بتحميل التغيير الخاص بك:

    repo upload
    

إذا نجحت ، فسترى رسالة تشبه هذه:

Upload project frameworks/native/ to remote branch master:
  branch codelab ( 1 commit, Wed Aug 7 09:32:33 2019 -0700):
         ff46b36d android codelab change
to https://android-review.googlesource.com/ (y/N)? y
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote:   https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432 android codelab change [NEW]
remote:
To https://android-review.googlesource.com/platform/frameworks/native
 * [new branch]          codelab -> refs/for/master

عرض التغيير الخاص بك في جيريت

انتقل إلى الرابط ، المطبوع في الجهاز ، والذي يشبه هذا الرابط:

https://android-review.googlesource.com/c/platform/frameworks/native/+/1098432

هذا يكمل مختبر الكود المبدئي لتطوير منصة Android. راجع إرسال التصحيحات لمعرفة الخطوات التالية ، وللحصول على تفاصيل كاملة حول تطوير Android ، راجع باقي هذا الموقع.

التراجع عن التغيير

عادة ، بعد الاختبار وعند المراجعة والموافقة ، تقوم بإرسال التغيير الخاص بك في Gerrit ودمجه في المستودع.

بدلاً من ذلك ، ولأغراض معمل الرموز هذا ، قم بإعادة قائمة التغيير الخاصة بك عن طريق النقر فوق التخلي في Gerrit.

ثم تخلَّ عن الفرع المؤقت المرتبط في دليل frameworks/native (أو الدلائل الفرعية):

repo abandon codelab .

تذكر أيضًا إعادة التغييرات التي أجريتها على ملف الاختبار. نظرًا لأنك لم repo start ، git commit ، وإعادة repo upload التغيير ، يمكنك إعادة تعيين الملف نفسه. بافتراض أنك في دليل aosp/platform_testing directory ، استخدم ما يلي لإعادة تعيين الملف:

git reset HEAD tests/example/devcodelab/src/android/test/example/devcodelab/DevCodelabTest.java
git checkout .

في هذه المرحلة ، لقد انتهيت! عمل جيد!

احصل على مساعدة

إذا واجهت أخطاء أثناء برنامج التعليمات البرمجية هذا ، فيرجى الإبلاغ عنها باستخدام رابط " تعقب المشكلات" الموجود أسفل أية صفحة. أرسل أسئلة إلى مجموعة android-building .