التحقق من سلوك التطبيقات على وقت تشغيل أندرويد (آرت)
Verifying App Behavior on the Android Runtime (ART)
في هذه الوثيقة
معالجة قضايا جمع القمامة (غ)
منع مشكلات جني
التحقق من رمز جني لقضايا جمع القمامة
معالجة الأخطاء
تغييرات نموذج الكائن
منع مشكلات حجم المكدس
إصلاح القضايا تجميع أوت
الإبلاغ عن المشاكل
أنظر أيضا
إدخال المعالجة المضادة للفيروس القهقري
تصحيح الروبوت جني مع تشيكجني
وقت التشغيل الروبوت (آرت) هو وقت التشغيل الافتراضي للأجهزة التي تعمل بنظام أندرويد 5.0 (مستوى أبي 21) وأعلى. هذا وقت التشغيل يقدم عددا من الميزات التي تحسن الأداء وسلاسة منصة أندرويد والتطبيقات. يمكنك العثور على مزيد من المعلومات حول الميزات الجديدة آرت في إدخال آرت .
ومع ذلك، بعض التقنيات التي تعمل على دالفيك لا تعمل على العلاج المضاد للفيروسات القهقرية. تتيح لك هذه الوثيقة معرفة الأشياء التي يجب مشاهدتها عند ترحيل تطبيق حالي ليكون متوافقا مع آرت. معظم التطبيقات يجب أن تعمل فقط عند تشغيل مع آرت.
معالجة قضايا جمع القمامة (غ)
تحت دالفيك، تطبيقات كثيرا ما تجد أنه من المفيد أن يدعو بشكل واضح System.gc() للمطالبة جمع القمامة (غ). يجب أن يكون هذا أقل ضررا بكثير مع المعالجة المضادة للفيروسات القهقرية، وخاصة إذا كنت GC_FOR_ALLOC جمع القمامة لمنع GC_FOR_ALLOC حدوث نوع أو لتقليل التجزؤ. يمكنك التحقق من وقت التشغيل قيد الاستخدام من خلال استدعاء System.getProperty("java.vm.version") . إذا آرت قيد الاستخدام، قيمة الخاصية هو "2.0.0" أو أعلى.
وعلاوة على ذلك، جامع القمامة ضغط قيد التطوير في مشروع مفتوح المصدر الروبوت (أوسب) لتحسين إدارة الذاكرة. وبسبب هذا، يجب تجنب استخدام التقنيات التي تتعارض مع ضغط غ (مثل توفير مؤشرات إلى بيانات مثيل الكائن). هذا مهم بشكل خاص للتطبيقات التي تستخدم واجهة جافا الأصلية (جني). لمزيد من المعلومات، راجع منع مشكلات جني .
منع مشكلات جني
آرت جني هو أكثر صرامة نوعا ما من دالفيك ل. انها فكرة جيدة بشكل خاص لاستخدام وضع تشيكجني للقبض على المشاكل المشتركة. إذا كان تطبيقك يستخدم شفرة C / C ++، يجب مراجعة المقالة التالية:
تصحيح الروبوت جني مع تشيكجني
التحقق من رمز جني لقضايا جمع القمامة
آرت لديه جامع القمامة ضغط قيد التطوير على الروبوت المصدر المفتوح المشروع (أوسب). مرة واحدة في جامع القمامة ضغط قيد الاستخدام، قد يتم نقل الكائنات في الذاكرة. إذا كنت تستخدم رمز C / C ++، لا تقم بتنفيذ عمليات غير متوافقة مع ضغط غ. قمنا بتعزيز تشيكجني لتحديد بعض القضايا المحتملة (كما هو موضح في جني المحلية التغييرات المرجعية في إكس ).
منطقة واحدة لمشاهدة على وجه الخصوص هو استخدام Get...ArrayElements() و Release...ArrayElements() الدالات. في أوقات التشغيل مع غ ضغط غير، Get...ArrayElements() عادة بإرجاع مرجع إلى الذاكرة الفعلية التي تدعم كائن صفيف. إذا قمت بإجراء تغيير على أحد عناصر المصفوفة التي تم إرجاعها، يتم تغيير الكائن مصفوفة نفسها Release...ArrayElements() ويتم عادة تجاهل الوسيطات إلى Release...ArrayElements() ). ومع ذلك، إذا كان ضغط غ قيد الاستخدام، قد تقوم الدالة Get...ArrayElements() بإرجاع نسخة من الذاكرة. إذا كنت إساءة استخدام المرجع عند ضغط غ قيد الاستخدام، يمكن أن يؤدي هذا إلى تلف الذاكرة أو مشاكل أخرى. فمثلا:
إذا قمت بإجراء أية تغييرات على عناصر الصفيف التي تم إرجاعها، يجب استدعاء الدالة Release...ArrayElements() المناسبة عند الانتهاء، للتأكد من أن التغييرات التي أجريتها يتم نسخها بشكل صحيح إلى كائن المصفوفة الأساسي.
عند تحرير عناصر صفيف الذاكرة، يجب استخدام الوضع المناسب، بناء على التغييرات التي أجريتها:
إذا لم تقم بإجراء أية تغييرات على عناصر الصفيف، استخدم وضع JNI_ABORT الذي يقوم بإصدار الذاكرة بدون نسخ التغييرات مرة أخرى إلى كائن الصفيف الأساسي.
إذا قمت بإجراء تغييرات على المصفوفة، ولا تحتاج إلى مرجع أكثر من ذلك، استخدم الكود 0 (الذي يقوم بتحديث كائن الصفيف ويحرر نسخة الذاكرة).
إذا قمت بإجراء تغييرات على المصفوفة التي تريد ارتكابها، وتريد الاحتفاظ بنسخة المصفوفة، استخدم JNI_COMMIT (الذي يقوم بتحديث كائن الصفيف الأساسي JNI_COMMIT النسخة).
عند استدعاء Release...ArrayElements() ، إرجاع نفس المؤشر الذي تم إرجاعه في الأصل بواسطة Get...ArrayElements() . على سبيل المثال، ليس من الآمن زيادة المؤشر الأصلي (لمسح عناصر المصفوفة التي تم إرجاعها) ثم تمرير المؤشر المتزايد إلى Release...ArrayElements() . قد يؤدي تمرير هذا المؤشر المعدل إلى تحرير الذاكرة الخاطئة، مما يؤدي إلى تلف الذاكرة.
معالجة الأخطاء
يلقي جني آرت أخطاء في عدد من الحالات حيث دالفيك لا. (مرة أخرى، يمكنك التقاط العديد من هذه الحالات عن طريق الاختبار مع تشيكجني.)
على سبيل المثال، إذا تم استدعاء ريجيستيرناتيفس مع طريقة غير موجودة (ربما لأن الطريقة تمت إزالتها بواسطة أداة مثل بروغوارد )، آرت الآن يلقي بشكل صحيح NoSuchMethodError :
08-12 17:09:41.082 13823 13823 E AndroidRuntime: FATAL EXCEPTION: main
08-12 17:09:41.082 13823 13823 E AndroidRuntime: java.lang.NoSuchMethodError:
no static or non-static method
"Lcom/foo/Bar;.native_frob(Ljava/lang/String;)I"
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
at java.lang.Runtime.nativeLoad(Native Method)
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
at java.lang.Runtime.doLoad(Runtime.java:421)
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
at java.lang.Runtime.loadLibrary(Runtime.java:362)
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
at java.lang.System.loadLibrary(System.java:526)
آرت أيضا بتسجيل خطأ (مرئية في لوغكات) إذا ريجيستيرناتيفس يسمى مع أي طرق:
W/art ( 1234): JNI RegisterNativeMethods: attempt to register 0 native
methods for <classname>
بالإضافة إلى ذلك، وظائف جني GetStaticFieldID() GetFieldID() و GetStaticFieldID() الآن رمي بشكل صحيح NoSuchFieldError بدلا من مجرد العودة فارغة. وبالمثل، GetMethodID() و GetStaticMethodID() الآن رمي بشكل صحيح NoSuchMethodError . هذا يمكن أن يؤدي إلى فشل تشيكجني بسبب الاستثناءات غير المعالجة أو الاستثناءات التي ألقيت إلى المتصلين جافا من التعليمات البرمجية الأصلية. وهذا يجعل من المهم بشكل خاص لاختبار التطبيقات المتوافقة مع آرت مع وضع تشيكجني.
آرت تتوقع مستخدمي جني CallNonvirtual...Method() أساليب CallNonvirtual...Method() ( CallNonvirtualVoidMethod() ) لاستخدام فئة تعريف الأسلوب، وليس فئة فرعية، كما هو مطلوب من قبل مواصفات جني.
منع مشكلات حجم المكدس
كان دالفيك مداخن منفصلة للأصل و جافا التعليمات البرمجية، مع حجم كومة جافا الافتراضي من 32KB وحجم الافتراضي كومة الأصلي من 1MB. آرت لديها كومة موحدة لتحسين موقع. عادة، يجب أن يكون حجم كومة Thread آرت تقريبا نفس لدالفيك. ومع ذلك، إذا قمت بتعيين أحجام المكدس بشكل صريح، قد تحتاج إلى إعادة النظر في تلك القيم للتطبيقات التي يتم تشغيلها في آرت.
في جافا، مراجعة المكالمات إلى منشئ Thread الذي يحدد حجم كومة صريحة. على سبيل المثال، سوف تحتاج إلى زيادة حجم إذا حدث StackOverflowError .
في C / C ++، مراجعة استخدام pthread_attr_setstack() و pthread_attr_setstacksize() مؤشرات الترابط التي تعمل أيضا كود جافا عبر جني. هنا مثال على الخطأ تسجيل عندما يحاول التطبيق للاتصال جني AttachCurrentThread() عندما يكون حجم AttachCurrentThread() صغير جدا:
F/art: art/runtime/thread.cc:435]
Attempt to attach a thread with a too-small stack (16384 bytes)
تغييرات نموذج الكائن
دالفيك سمح بشكل غير صحيح الفئات الفرعية لتجاوز أساليب الحزمة الخاصة. ويصدر آرت تحذيرا في مثل هذه الحالات:
Before Android 4.1, method void com.foo.Bar.quux()
would have incorrectly overridden the package-private method in
com.quux.Quux
إذا كنت تنوي تجاوز طريقة الفئة في حزمة مختلفة، فأعلن الطريقة public أو protected .
يحتوي Object الآن على حقول خاصة. يجب أن تكون التطبيقات التي تعكس الحقول في التسلسل الهرمي للفئة حريصة على عدم محاولة البحث في حقول Object . على سبيل المثال، إذا كنت تقوم بتكرار التسلسل الهرمي للفئة كجزء من إطار التسلسل، توقف عند
Class.getSuperclass () == java.lang.Object.class
بدلا من الاستمرار حتى تعود الطريقة null .
بروكسي InvocationHandler.invoke() يتلقى الآن null إذا لم يكن هناك وسيطات بدلا من صفيف فارغ. تم توثيق هذا السلوك سابقا ولكن لم يتم التعامل معها بشكل صحيح في دالفيك. الإصدارات السابقة من موكيتو لديهم صعوبات مع هذا، وذلك باستخدام نسخة موكيتو المحدثة عند الاختبار مع آرت.
إصلاح القضايا تجميع أوت
آرت's أهيد-أوف-تايم (أوت) يجب أن يعمل تجميع جافا لكل كود جافا القياسي. يتم تنفيذ تجميع بواسطة أداة آرت dex2oat . إذا واجهت أي مشاكل تتعلق dex2oat في وقت التثبيت، واسمحوا لنا أن نعرف (انظر مشاكل الإبلاغ ) حتى نتمكن من إصلاحها في أسرع وقت ممكن. وهناك عدد من القضايا أن نلاحظ:
آرت لا تشديد التحقق بيتيكود في وقت التثبيت من دالفيك لا. يجب أن تكون التعليمات البرمجية التي تنتجها أدوات بناء الروبوت على ما يرام. ومع ذلك، بعض أدوات ما بعد المعالجة (وخاصة الأدوات التي تؤدي التشويش) قد تنتج ملفات غير صالحة التي تتسامح معها دالفيك ولكن رفضها آرت. لقد تم العمل مع بائعي الأدوات لإيجاد وإصلاح هذه القضايا. في كثير من الحالات، الحصول على أحدث إصدارات أدواتك وإعادة إنشاء ملفات ديكس يمكن إصلاح هذه المشاكل.
بعض المشاكل النموذجية التي يتم الإبلاغ عنها من قبل المدقق آرت ما يلي:
تدفق التحكم غير صالح
غير متوازن moniterenter / moniterexit
0-لينغث المعلمة نوع نوع الحجم
بعض التطبيقات لها تبعيات على تنسيق ملف .odex المثبتة في /system/framework ، /data/dalvik-cache ، أو في DexClassLoader الأمثل إخراج الدليل. هذه الملفات الآن ملفات إلف وليس شكل موسع من ملفات ديكس. في حين يحاول آرت اتباع نفس قواعد التسمية والقفل كما دالفيك، يجب أن التطبيقات لا تعتمد على تنسيق الملف. فإن الشكل عرضة للتغيير دون إشعار.
الإبلاغ عن المشاكل
إذا واجهت أي مشاكل ليست بسبب مشاكل جني التطبيق، والإبلاغ عنها عن طريق الروبوت المصدر المفتوح مشروع تعقب المسألة في https://code.google.com/p/android/issues/list . تضمين "adb bugreport" ورابط إلى التطبيق في متجر غوغل بلاي إذا كانت متوفرة. وإلا، إذا أمكن، يمكنك إرفاق ملف أبك يكرر المشكلة. لاحظ أن المشكلات (بما في ذلك المرفقات) مرئية بشكل عام.
Verifying App Behavior on the Android Runtime (ART)
في هذه الوثيقة
معالجة قضايا جمع القمامة (غ)
منع مشكلات جني
التحقق من رمز جني لقضايا جمع القمامة
معالجة الأخطاء
تغييرات نموذج الكائن
منع مشكلات حجم المكدس
إصلاح القضايا تجميع أوت
الإبلاغ عن المشاكل
أنظر أيضا
إدخال المعالجة المضادة للفيروس القهقري
تصحيح الروبوت جني مع تشيكجني
وقت التشغيل الروبوت (آرت) هو وقت التشغيل الافتراضي للأجهزة التي تعمل بنظام أندرويد 5.0 (مستوى أبي 21) وأعلى. هذا وقت التشغيل يقدم عددا من الميزات التي تحسن الأداء وسلاسة منصة أندرويد والتطبيقات. يمكنك العثور على مزيد من المعلومات حول الميزات الجديدة آرت في إدخال آرت .
ومع ذلك، بعض التقنيات التي تعمل على دالفيك لا تعمل على العلاج المضاد للفيروسات القهقرية. تتيح لك هذه الوثيقة معرفة الأشياء التي يجب مشاهدتها عند ترحيل تطبيق حالي ليكون متوافقا مع آرت. معظم التطبيقات يجب أن تعمل فقط عند تشغيل مع آرت.
معالجة قضايا جمع القمامة (غ)
تحت دالفيك، تطبيقات كثيرا ما تجد أنه من المفيد أن يدعو بشكل واضح System.gc() للمطالبة جمع القمامة (غ). يجب أن يكون هذا أقل ضررا بكثير مع المعالجة المضادة للفيروسات القهقرية، وخاصة إذا كنت GC_FOR_ALLOC جمع القمامة لمنع GC_FOR_ALLOC حدوث نوع أو لتقليل التجزؤ. يمكنك التحقق من وقت التشغيل قيد الاستخدام من خلال استدعاء System.getProperty("java.vm.version") . إذا آرت قيد الاستخدام، قيمة الخاصية هو "2.0.0" أو أعلى.
وعلاوة على ذلك، جامع القمامة ضغط قيد التطوير في مشروع مفتوح المصدر الروبوت (أوسب) لتحسين إدارة الذاكرة. وبسبب هذا، يجب تجنب استخدام التقنيات التي تتعارض مع ضغط غ (مثل توفير مؤشرات إلى بيانات مثيل الكائن). هذا مهم بشكل خاص للتطبيقات التي تستخدم واجهة جافا الأصلية (جني). لمزيد من المعلومات، راجع منع مشكلات جني .
منع مشكلات جني
آرت جني هو أكثر صرامة نوعا ما من دالفيك ل. انها فكرة جيدة بشكل خاص لاستخدام وضع تشيكجني للقبض على المشاكل المشتركة. إذا كان تطبيقك يستخدم شفرة C / C ++، يجب مراجعة المقالة التالية:
تصحيح الروبوت جني مع تشيكجني
التحقق من رمز جني لقضايا جمع القمامة
آرت لديه جامع القمامة ضغط قيد التطوير على الروبوت المصدر المفتوح المشروع (أوسب). مرة واحدة في جامع القمامة ضغط قيد الاستخدام، قد يتم نقل الكائنات في الذاكرة. إذا كنت تستخدم رمز C / C ++، لا تقم بتنفيذ عمليات غير متوافقة مع ضغط غ. قمنا بتعزيز تشيكجني لتحديد بعض القضايا المحتملة (كما هو موضح في جني المحلية التغييرات المرجعية في إكس ).
منطقة واحدة لمشاهدة على وجه الخصوص هو استخدام Get...ArrayElements() و Release...ArrayElements() الدالات. في أوقات التشغيل مع غ ضغط غير، Get...ArrayElements() عادة بإرجاع مرجع إلى الذاكرة الفعلية التي تدعم كائن صفيف. إذا قمت بإجراء تغيير على أحد عناصر المصفوفة التي تم إرجاعها، يتم تغيير الكائن مصفوفة نفسها Release...ArrayElements() ويتم عادة تجاهل الوسيطات إلى Release...ArrayElements() ). ومع ذلك، إذا كان ضغط غ قيد الاستخدام، قد تقوم الدالة Get...ArrayElements() بإرجاع نسخة من الذاكرة. إذا كنت إساءة استخدام المرجع عند ضغط غ قيد الاستخدام، يمكن أن يؤدي هذا إلى تلف الذاكرة أو مشاكل أخرى. فمثلا:
إذا قمت بإجراء أية تغييرات على عناصر الصفيف التي تم إرجاعها، يجب استدعاء الدالة Release...ArrayElements() المناسبة عند الانتهاء، للتأكد من أن التغييرات التي أجريتها يتم نسخها بشكل صحيح إلى كائن المصفوفة الأساسي.
عند تحرير عناصر صفيف الذاكرة، يجب استخدام الوضع المناسب، بناء على التغييرات التي أجريتها:
إذا لم تقم بإجراء أية تغييرات على عناصر الصفيف، استخدم وضع JNI_ABORT الذي يقوم بإصدار الذاكرة بدون نسخ التغييرات مرة أخرى إلى كائن الصفيف الأساسي.
إذا قمت بإجراء تغييرات على المصفوفة، ولا تحتاج إلى مرجع أكثر من ذلك، استخدم الكود 0 (الذي يقوم بتحديث كائن الصفيف ويحرر نسخة الذاكرة).
إذا قمت بإجراء تغييرات على المصفوفة التي تريد ارتكابها، وتريد الاحتفاظ بنسخة المصفوفة، استخدم JNI_COMMIT (الذي يقوم بتحديث كائن الصفيف الأساسي JNI_COMMIT النسخة).
عند استدعاء Release...ArrayElements() ، إرجاع نفس المؤشر الذي تم إرجاعه في الأصل بواسطة Get...ArrayElements() . على سبيل المثال، ليس من الآمن زيادة المؤشر الأصلي (لمسح عناصر المصفوفة التي تم إرجاعها) ثم تمرير المؤشر المتزايد إلى Release...ArrayElements() . قد يؤدي تمرير هذا المؤشر المعدل إلى تحرير الذاكرة الخاطئة، مما يؤدي إلى تلف الذاكرة.
معالجة الأخطاء
يلقي جني آرت أخطاء في عدد من الحالات حيث دالفيك لا. (مرة أخرى، يمكنك التقاط العديد من هذه الحالات عن طريق الاختبار مع تشيكجني.)
على سبيل المثال، إذا تم استدعاء ريجيستيرناتيفس مع طريقة غير موجودة (ربما لأن الطريقة تمت إزالتها بواسطة أداة مثل بروغوارد )، آرت الآن يلقي بشكل صحيح NoSuchMethodError :
08-12 17:09:41.082 13823 13823 E AndroidRuntime: FATAL EXCEPTION: main
08-12 17:09:41.082 13823 13823 E AndroidRuntime: java.lang.NoSuchMethodError:
no static or non-static method
"Lcom/foo/Bar;.native_frob(Ljava/lang/String;)I"
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
at java.lang.Runtime.nativeLoad(Native Method)
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
at java.lang.Runtime.doLoad(Runtime.java:421)
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
at java.lang.Runtime.loadLibrary(Runtime.java:362)
08-12 17:09:41.082 13823 13823 E AndroidRuntime:
at java.lang.System.loadLibrary(System.java:526)
آرت أيضا بتسجيل خطأ (مرئية في لوغكات) إذا ريجيستيرناتيفس يسمى مع أي طرق:
W/art ( 1234): JNI RegisterNativeMethods: attempt to register 0 native
methods for <classname>
آرت تتوقع مستخدمي جني CallNonvirtual...Method() أساليب CallNonvirtual...Method() ( CallNonvirtualVoidMethod() ) لاستخدام فئة تعريف الأسلوب، وليس فئة فرعية، كما هو مطلوب من قبل مواصفات جني.
منع مشكلات حجم المكدس
كان دالفيك مداخن منفصلة للأصل و جافا التعليمات البرمجية، مع حجم كومة جافا الافتراضي من 32KB وحجم الافتراضي كومة الأصلي من 1MB. آرت لديها كومة موحدة لتحسين موقع. عادة، يجب أن يكون حجم كومة Thread آرت تقريبا نفس لدالفيك. ومع ذلك، إذا قمت بتعيين أحجام المكدس بشكل صريح، قد تحتاج إلى إعادة النظر في تلك القيم للتطبيقات التي يتم تشغيلها في آرت.
في جافا، مراجعة المكالمات إلى منشئ Thread الذي يحدد حجم كومة صريحة. على سبيل المثال، سوف تحتاج إلى زيادة حجم إذا حدث StackOverflowError .
في C / C ++، مراجعة استخدام pthread_attr_setstack() و pthread_attr_setstacksize() مؤشرات الترابط التي تعمل أيضا كود جافا عبر جني. هنا مثال على الخطأ تسجيل عندما يحاول التطبيق للاتصال جني AttachCurrentThread() عندما يكون حجم AttachCurrentThread() صغير جدا:
F/art: art/runtime/thread.cc:435]
Attempt to attach a thread with a too-small stack (16384 bytes)
تغييرات نموذج الكائن
دالفيك سمح بشكل غير صحيح الفئات الفرعية لتجاوز أساليب الحزمة الخاصة. ويصدر آرت تحذيرا في مثل هذه الحالات:
Before Android 4.1, method void com.foo.Bar.quux()
would have incorrectly overridden the package-private method in
com.quux.Quux
إذا كنت تنوي تجاوز طريقة الفئة في حزمة مختلفة، فأعلن الطريقة public أو protected .
يحتوي Object الآن على حقول خاصة. يجب أن تكون التطبيقات التي تعكس الحقول في التسلسل الهرمي للفئة حريصة على عدم محاولة البحث في حقول Object . على سبيل المثال، إذا كنت تقوم بتكرار التسلسل الهرمي للفئة كجزء من إطار التسلسل، توقف عند
Class.getSuperclass () == java.lang.Object.class
بروكسي InvocationHandler.invoke() يتلقى الآن null إذا لم يكن هناك وسيطات بدلا من صفيف فارغ. تم توثيق هذا السلوك سابقا ولكن لم يتم التعامل معها بشكل صحيح في دالفيك. الإصدارات السابقة من موكيتو لديهم صعوبات مع هذا، وذلك باستخدام نسخة موكيتو المحدثة عند الاختبار مع آرت.
إصلاح القضايا تجميع أوت
آرت's أهيد-أوف-تايم (أوت) يجب أن يعمل تجميع جافا لكل كود جافا القياسي. يتم تنفيذ تجميع بواسطة أداة آرت dex2oat . إذا واجهت أي مشاكل تتعلق dex2oat في وقت التثبيت، واسمحوا لنا أن نعرف (انظر مشاكل الإبلاغ ) حتى نتمكن من إصلاحها في أسرع وقت ممكن. وهناك عدد من القضايا أن نلاحظ:
آرت لا تشديد التحقق بيتيكود في وقت التثبيت من دالفيك لا. يجب أن تكون التعليمات البرمجية التي تنتجها أدوات بناء الروبوت على ما يرام. ومع ذلك، بعض أدوات ما بعد المعالجة (وخاصة الأدوات التي تؤدي التشويش) قد تنتج ملفات غير صالحة التي تتسامح معها دالفيك ولكن رفضها آرت. لقد تم العمل مع بائعي الأدوات لإيجاد وإصلاح هذه القضايا. في كثير من الحالات، الحصول على أحدث إصدارات أدواتك وإعادة إنشاء ملفات ديكس يمكن إصلاح هذه المشاكل.
بعض المشاكل النموذجية التي يتم الإبلاغ عنها من قبل المدقق آرت ما يلي:
تدفق التحكم غير صالح
غير متوازن moniterenter / moniterexit
0-لينغث المعلمة نوع نوع الحجم
بعض التطبيقات لها تبعيات على تنسيق ملف .odex المثبتة في /system/framework ، /data/dalvik-cache ، أو في DexClassLoader الأمثل إخراج الدليل. هذه الملفات الآن ملفات إلف وليس شكل موسع من ملفات ديكس. في حين يحاول آرت اتباع نفس قواعد التسمية والقفل كما دالفيك، يجب أن التطبيقات لا تعتمد على تنسيق الملف. فإن الشكل عرضة للتغيير دون إشعار.
الإبلاغ عن المشاكل
إذا واجهت أي مشاكل ليست بسبب مشاكل جني التطبيق، والإبلاغ عنها عن طريق الروبوت المصدر المفتوح مشروع تعقب المسألة في https://code.google.com/p/android/issues/list . تضمين "adb bugreport" ورابط إلى التطبيق في متجر غوغل بلاي إذا كانت متوفرة. وإلا، إذا أمكن، يمكنك إرفاق ملف أبك يكرر المشكلة. لاحظ أن المشكلات (بما في ذلك المرفقات) مرئية بشكل عام.
ليست هناك تعليقات:
إرسال تعليق