درس تطبيقي حول ترميز مطوّري تطبيقات Android

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

وعلى الرغم من صعوبة هذا المسار، يسعى فريق Android جاهدًا لتبسيط ورحلتك وكل إصدار. ويُجري الفريق تحسينات كل يوم من خلال العمل المباشر في "المشروع المفتوح المصدر لنظام Android" ‏(AOSP).

لذا ندعوك للاستراحة وإطلاق العنان لإبداعك ومشاركة التاريخ مع صناعة التاريخ.

الأهداف

تنطوي مهمة هذا الدرس التطبيقي حول الترميز على شقين:

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

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

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

• أن تستوفي محطة عمل Linux جميع المتطلبات العامة
• Repo وإعدادات Git المطلوبة لتعديل قاعدة بيانات Android

البيئة

عادةً ما يقوم المستخدمون بالبناء والتطوير على محطة العمل مباشرةً. لأنه قد تعمل في العديد من الوحدات الطرفية، كما أن العديد من الأوامر المستخدمة خاصة بالوحدة الطرفية، عليك إعادة تشغيلهما في كل جلسة طرفية. على وجه التحديد، وتتضمّن الأمرين 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

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

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

نصيحة: لزيادة المساحة الخالية، احذف دليل فرعي وابدأ جديدة من إنشاء الدليل، على النحو التالي: rm -rf aosp2.

إنشاء الرمز

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

يتيح لك استهداف الجهاز aosp_cf_x86_64_phone-userdebug لتصميم جهاز Android افتراضي للحبت للاختبار بدون جهاز مادي.

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

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

   source build/envsetup.sh

2. نقْل هدف الإنشاء إلى أمر lunch، على النحو التالي:

   lunch aosp_cf_x86_64_phone-trunk_staging-userdebug

3. يمكنك إنشاء الرمز من أي مكان في الدفع باستخدام:

   m

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

إطلاق حبَّار

حبَّار هو محاكي Android الذي يُستخدم لاختبار تصميماتك.

1. إذا لم يسبق لك تثبيت تطبيق Cuttlefish، فيجب تثبيت تبعيات الحبار. في نافذة المحطة الطرفية، شغِّل الأوامر التالية لتنزيل حزم دبيان المضيفة وإنشاؤها وتثبيتها:

   sudo apt install -y git devscripts equivs config-package-dev debhelper-compat golang curl
   git clone https://github.com/google/android-cuttlefish
   cd android-cuttlefish
   for dir in base frontend; do
   pushd $dir
   # Install build dependencies
   sudo mk-build-deps -i
   dpkg-buildpackage -uc -us
   popd
   done
   sudo dpkg -i ./cuttlefish-base_*_*64.deb || sudo apt-get install -f
   sudo dpkg -i ./cuttlefish-user_*_*64.deb || sudo apt-get install -f
   sudo usermod -aG kvm,cvdnetwork,render $USER
   sudo reboot

   تؤدي إعادة التشغيل إلى تثبيت وحدات نواة إضافية وتطبيق udev. القواعد.

2. إطلاق حبَّار:

   launch_cvd --daemon
   

3. الاتصال بجهاز حبَّار من خلال الانتقال إلى https://localhost:8443 في في متصفح الويب الخاص بك. يتم الترحيب بك من خلال بث فيديو للجهاز الذي يعمل بنظام التشغيل Android الذي أنشأته للتو.

تغيير

عدِّل الرمز المصدر باتّباع مثال قائمة التغييرات هذا.

1. من جذر عملية الفحص (الدليل aosp/)، انتقِل إلى frameworks/native مشروع Git:

   cd frameworks/native

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

   repo start <some-name> .

3. عدِّل SurfaceFlinger.cpp لتضمين التعديلات من قائمة التغييرات في الموقع الجغرافي التالي:

   aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
   

4. ابحث عن هذا الخط:

   void SurfaceFlinger::updateColorMatrixLocked() {
   

5. أضِف هذين السطرَين في بداية updateColorMatrixLocked():

   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});
   

6. أنشئ الرمز البرمجي:

   m

7. لتعديل الإصدار على الجهاز، اتّبِع الخطوات التالية:

   adb root
   adb remount
   adb sync
   adb reboot

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

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

اختبار الرمز

يستخدِم هذا الجزء من الدرس التطبيقي حول الترميز مثالاً على اختبار في شجرة المصدر وهي تفشل. يستخدم ذلك Atest لـ إجراء الاختبار محليًا واختبار الرمز.

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

1. تنفيذ:

   atest DevCodelabTest

2. سيتعذّر إكمال الاختبار. فحص تتبُّع تسلسل استدعاء الدوال البرمجية للاختبار الذي تعذّر إكماله:

   STACKTRACE:
   java.lang.AssertionError
    at org.junit.Assert.fail(Assert.java:87)
    at org.junit.Assert.assertTrue(Assert.java:42)
    at org.junit.Assert.assertTrue(Assert.java:53)
    at android.test.example.devcodelab.DevCodelabTest.testHelloWorld(DevCodelabTest.java:29)

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. نظام مراجعة الرموز البرمجية المستند إلى الويب.

ملاحظة مهمة: تأكَّد من تسجيل الدخول إلى 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 main:
  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/main

عرض التغيير في Gerrit

انتقِل إلى الرابط المطبوع في الوحدة الطرفية والذي يشبه هذا الرابط:

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 المجموعة.