تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

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

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

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

الأهداف

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

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

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

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

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

البيئة

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

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

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

إعداد الرمز ومزامنته

انتقِل إلى الدليل الرئيسي:
```
cd ~
```
أنشئ دليلاً فرعيًا محليًا للعمل داخله:
```
mkdir aosp
```
انتقِل إلى الدليل:
```
cd aosp
```
نفِّذ الفرع الرئيسي لرمز مصدر رمز مصدر مستودع AOSP (الإعداد التلقائي):
```
repo init -u https://android.googlesource.com/platform/manifest
```
أدخِل بيانات اعتماد Git أو اقبلها (الاسم وعنوان البريد الإلكتروني).
مزامنة رمز المصدر:
```
repo sync -j8
```

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

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

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

إنشاء الرمز البرمجي

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

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

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

يمكنك إعداد بيئتك لإنشاء أجهزة Android من خلال تشغيل الأمر التالي من جذر صفحة الدفع باستخدام رمز المصدر:
```
source build/envsetup.sh
```
قم بتمرير هدف الإصدار إلى أمر الغداء، مثل هذا:
```
lunch aosp_cf_x86_64_phone-trunk_staging-userdebug
```
يمكنك إنشاء الرمز من أي مكان في صفحة الدفع باستخدام:
```
m
```

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

إطلاق حبَّار

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

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

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.

إطلاق الحبار:
```
launch_cvd --daemon
```
يمكنك الاتصال بجهاز حبَّار من خلال الانتقال إلى https://localhost:8443 في متصفّح الويب. في انتظارك بث فيديو لجهاز Android الذي صنعته للتو.

تغيير

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

من جذر صفحة الدفع (دليل aosp/)، انتقِل إلى مشروع Git frameworks/native:
```
cd frameworks/native
```
ابدأ مشروعًا مؤقتًا باستخدام هذا الأمر:
```
repo start <some-name> .
```
عدِّل SurfaceFlinger.cpp لتضمين التعديلات من قائمة التغييرات في الموقع الجغرافي التالي:
```
aosp/frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp
```

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

void SurfaceFlinger::updateColorMatrixLocked() {

أضف هذين السطرين في بداية 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});

إنشاء التعليمة البرمجية:
```
m
```
تحديث الإصدار على الجهاز:
```
adb root
adb remount
adb sync
adb reboot
```

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

مثال على تغيير اللون الناجح

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

اختبار الرمز

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

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

التشغيل:
```
atest DevCodelabTest
```
سيفشل الاختبار. لإصلاحه، ابحث عن رمز المصدر للاختبار الذي تعذّر إكماله:
```
atest --info android.test.example.devcodelab.DevCodelabTest#testHelloWorld
```

ثم انظر هنا

platform_testing/tests/example/devcodelab

لتعديل الملف، عليك استخدام اسم الاختبار في android.test.example.devcodelab.DevCodelabTest واستبدال . بـ / للحصول على هذه النتيجة:
```
src/android/test/example/devcodelab/DevCodelabTest.java
```

ثم تعديل

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

لاستبدال

Assert.assertTrue(false)

مع

Assert.assertTrue(true)

أعِد تشغيل الاختبار للتأكّد من حلّ المشكلة:
```
atest DevCodelabTest
```

تحميل الرمز للمراجعة

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

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

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

على افتراض أنّك أجريت التغييرات في مشروع frameworks/native، عليك تشغيل هذه الأوامر لتحميلها:
```
cd frameworks/native
repo start codelab .
git add .
git commit
```
بالنسبة إلى رسالة الالتزام، أدخِل ما يلي:
```
Android codelab change
Test: manual atest
```
تحميل التغيير:
```
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.