این مقاله فرآیند ورود به سیستم را شامل استانداردهای گزارش، دستورالعملهای سطح، کلاسها، اهداف و تقریبهای چند پشتهای را پوشش میدهد.
استانداردهای لاگ
ورود به سیستم اندروید به دلیل ترکیبی از استانداردهای استفاده شده که در logcat
ترکیب شده اند، پیچیده است. استانداردهای اصلی مورد استفاده به تفصیل در زیر آمده است:
منبع | نمونه ها | راهنمایی سطح پشته |
---|---|---|
RFC 5424 ( syslog استاندارد) | هسته لینوکس، بسیاری از برنامه های یونیکس | هسته، شیاطین سیستم |
android.util.Log | چارچوب اندروید + ثبت برنامه | فریم ورک اندروید و اپلیکیشن سیستم |
java.util.logging.Level | ورود به سیستم عمومی در جاوا | برنامه غیر سیستمی |
شکل 1: استانداردهای سطح گزارش.
اگرچه هر یک از این استانداردها ساختار مشابهی دارند، اما از نظر دانه بندی متفاوت هستند. معادل های تقریبی در سراسر استانداردها به شرح زیر است:
سطح RFC 5424 | RFC 5424 شدت | توضیحات RFC 5424 | android.util.Log | java.util.logging.Level |
---|---|---|---|---|
0 | اورژانس | سیستم غیر قابل استفاده است | Log.e / Log.wtf | SEVERE |
1 | هشدار | باید فورا اقدام شود | Log.e / Log.wtf | SEVERE |
2 | انتقادی | شرایط بحرانی | Log.e / Log.wtf | SEVERE |
3 | خطا | شرایط خطا | Log.e | SEVERE |
4 | هشدار | شرایط هشدار | Log.w | WARNING |
5 | توجه کنید | عادی اما قابل توجه | Log.w | WARNING |
6 | اطلاعات | پیام رسانی اطلاعاتی | Log.i | INFO |
7 | اشکال زدایی | پیام های سطح اشکال زدایی | Log.d | CONFIG ، FINE |
- | - | پیام رسانی پرمخاطب | Log.v | FINER / FINEST |
شکل 2: سطوح ثبت syslog
، اندروید و جاوا.
دستورالعمل های سطح ورود به سیستم
دستورالعمل های موجود برای هر استاندارد ورود به سیستم وجود دارد. سطح گزارش انتخاب شده از استاندارد مناسبی که استفاده می شود، مانند استفاده از استاندارد syslog
برای توسعه هسته پیروی می کند.
ترتیبات سطح گزارش، از حداقل به بیشترین، در سه شکل زیر نشان داده شده است:
ERROR | این سیاههها همیشه نگهداری می شوند. |
WARN | این سیاههها همیشه نگهداری می شوند. |
INFO | این سیاههها همیشه نگهداری می شوند. |
DEBUG | این لاگ ها کامپایل می شوند اما در زمان اجرا پاک می شوند. |
VERBOSE | این گزارشها به جز در زمان توسعه هرگز در یک برنامه کامپایل نمیشوند. |
شکل 3: android.util.Log
CONFIG | سطح پیام برای پیام های پیکربندی ایستا |
FINE | سطح پیام ارائه اطلاعات ردیابی |
FINER | یک پیام ردیابی نسبتاً دقیق را نشان می دهد |
FINEST | پیام ردیابی بسیار دقیق را نشان می دهد |
INFO | سطح پیام برای پیام های اطلاعاتی |
SEVERE | سطح پیام نشان دهنده یک شکست جدی است |
WARNING | سطح پیام نشان دهنده یک مشکل احتمالی است |
شکل 4: java.util.Logging.Level
.
0 | اورژانس | سیستم غیر قابل استفاده است |
1 | هشدار | باید فورا اقدام شود |
2 | انتقادی | شرایط بحرانی |
3 | خطا | شرایط خطا |
4 | هشدار | شرایط هشدار |
5 | توجه کنید | شرایط عادی اما قابل توجه |
6 | اطلاعاتی | پیام های اطلاعاتی |
7 | اشکال زدایی | پیام های سطح اشکال زدایی |
شکل 5: RFC 5424
- بخش 6.2.1 .
ثبت برنامه
گزارش گیری انتخابی با TAG
توسط کلاس android.util.Log
با استفاده از Log#isLoggable
انجام می شود، همانطور که در زیر نشان داده شده است:
if (Log.isLoggable("FOO_TAG", Log.VERBOSE)) { Log.v("FOO_TAG", "Message for logging."); } |
---|
گزارشها را میتوان در زمان اجرا تنظیم کرد تا سطح انتخابی از ورود به سیستم را مطابق شکل زیر ارائه کند:
adb shell setprop log.tag.FOO_TAG VERBOSE |
---|
ویژگی های log.tag.*
در راه اندازی مجدد بازنشانی می شوند. انواع دائمی وجود دارد که در راه اندازی مجدد نیز باقی می مانند. زیر را ببینید:
adb shell setprop persist.log.tag.FOO_TAG VERBOSE |
---|
بررسی های Log#isLoggable
ردی از گزارش در کد برنامه باقی می گذارد. پرچمهای Boolean DEBUG
با استفاده از بهینهسازیهای کامپایلر که روی false
تنظیم شدهاند، ردهای گزارش را دور میزنند، همانطور که در زیر نشان داده شده است:
private final static boolean DEBUG = false; |
---|
ورود به سیستم را می توان بر اساس هر APK از طریق قوانین ProGuard توسط R8
در زمان کامپایل حذف کرد. مثال زیر همه موارد زیر ثبت سطح INFO
را برای android.util.Log
حذف می کند:
# This allows proguard to strip isLoggable() blocks containing only <=INFO log # code from release builds. -assumenosideeffects class android.util.Log { static *** i(...); static *** d(...); static *** v(...); static *** isLoggable(...); } -maximumremovedandroidloglevel 4 |
---|
این برای مدیریت چندین نوع ساخت برنامه (به عنوان مثال، ساختهای توسعه در مقابل نسخههای انتشار) که انتظار میرود کد اصلی یکسان باشد، اما سطوح گزارش مجاز متفاوت است، مفید است. باید یک خط مشی صریح برای برنامهها (به ویژه برنامههای سیستمی) تنظیم و دنبال شود تا تصمیم بگیرند که چگونه انواع ساخت و انتظارات انتشار بر خروجی گزارش تأثیر میگذارند.
ورود سیستم در زمان اجرا اندروید (ART)
چندین کلاس موجود برای برنامه ها و سرویس های سیستم موجود است:
کلاس | هدف |
---|---|
android.telephony.Rlog | گزارش رادیویی |
android.util.Log | ثبت برنامه عمومی |
android.util.EventLog | ثبت رویدادهای تشخیصی یکپارچه ساز سیستم |
android.util.Slog | ورود به سیستم چارچوب پلت فرم |
شکل 6: کلاس ها و اهداف ثبت سیستم موجود.
اگرچه android.util.Log
و android.util.Slog
از استانداردهای سطح گزارش یکسانی استفاده می کنند، Slog
یک کلاس @hide
است که فقط توسط پلتفرم قابل استفاده است. سطوح EventLog
به ورودی های فایل event.logtags
در /system/etc/event-log-tags
نگاشت می شوند.
چوب بری بومی
ورود به سیستم C/C++ از استاندارد syslog
پیروی می کند که syslog
(2) مربوط به syslog
هسته لینوکس است که بافر printk
کنترل می کند و syslog
(3) مربوط به سیستم ثبت کننده عمومی است. اندروید از کتابخانه liblog
برای ورود به سیستم عمومی استفاده می کند.
liblog
با استفاده از فرم ماکرو زیر، بستهبندیهایی را برای گروههای زیرلاگها فراهم میکند:
[Sublog Buffer ID] LOG [Log Level ID] |
برای مثال، RLOGD
با [Radio log buffer ID] LOG [Debug Level]
مطابقت دارد. بستهبندیهای اصلی liblog
به شرح زیر است:
کلاس لفاف | توابع نمونه |
---|---|
log_main.h | ALOGV ، ALOGW |
log_radio.h | RLOGD ، RLOGE |
log_system.h | SLOGI ، SLOGW |
شکل 7: بسته بندی های liblog
.
اندروید دارای رابط های سطح بالاتری برای ورود به سیستم است که نسبت به استفاده مستقیم liblog
ترجیح داده می شود، همانطور که در زیر مشاهده می کنید:
کتابخانه | استفاده |
---|---|
async_safe | کتابخانه فقط برای ورود به سیستم از محیطهای ایمن سیگنال غیرهمگام |
libbase | کتابخانه Logging که یک رابط جریان C++ را برای ورود به سیستم فراهم میکند، شبیه به گزارشگیری به سبک Google (glog). libbase در هر دو پروژه خارجی قابل استفاده است و در برنامه هایی با استفاده از libbase_ndk در دسترس است. |
شکل 8: کتابخانه های ثبتی سطح بالاتر.
تقریب های چند پشته ای
به دلیل تفاوت در جزئیات و هدف سطح، هیچ تطبیق واضح یا دقیقی از استانداردهای مختلف گزارش وجود ندارد. به عنوان مثال، سطوح java.util.logging.Level
و android.util.Log
برای گزارشهای خطا مطابق 1:1 نیستند:
java.util.Logging.Level | android.util.Log |
---|---|
شدید | Log.wtf |
شدید | Log.e |
شکل 9: سطح خطا در لاگ استاندارد جاوا در مقابل لاگ اندروید.
در مواردی مانند این، از استاندارد فردی برای تعیین سطح مورد استفاده استفاده کنید.
در طول توسعه سیستم با چندین مؤلفه در سطح پشته، شکل 1 را دنبال کنید تا تعیین کنید از کدام استاندارد برای هر جزء استفاده کنید. برای راهنمای تقریبی پیامرسانی ردیف، شکل 2 را دنبال کنید.
امنیت و حریم خصوصی
اطلاعات شناسایی شخصی (PII) را وارد نکنید. این شامل جزئیاتی مانند:
- آدرس های ایمیل
- شماره های تلفن
- نام ها
به طور مشابه، برخی از جزئیات حساس تلقی می شوند، حتی اگر به طور صریح و شخصی قابل شناسایی نباشند.
برای مثال، اگرچه اطلاعات منطقه زمانی قابل شناسایی شخصی در نظر گرفته نمی شود، اما نشانی از مکان تقریبی یک کاربر را نشان می دهد.
خط مشی گزارش و جزئیات قابل قبول باید به عنوان بخشی از بررسی امنیت و حریم خصوصی قبل از انتشار بررسی شود.
گزارش های دستگاه
دسترسی به همه گزارشهای دستگاه، از جمله استفاده از android.permission.READ_LOGS
محدود شده است:
- اگر برنامهای در پسزمینه درخواست دسترسی به همه گزارشهای دستگاه را داشته باشد، درخواست بهطور خودکار رد میشود، مگر اینکه برنامه:
- UID سیستم را به اشتراک می گذارد.
- از یک فرآیند سیستمی بومی (
UID
<APP_UID
) استفاده می کند. - از
DropBoxManager
استفاده می کند. - فقط به بافر گزارش رویداد دسترسی دارد.
- از
EventLog
API استفاده می کند. - از تست های ابزاری استفاده می کند.
- اگر برنامهای در پیشزمینه با
READ_LOGS
درخواست دسترسی به گزارشهای دستگاه کند، سیستم از کاربر میخواهد درخواست دسترسی را تأیید یا رد کند.