हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

डेटा इकट्ठा करने की सुविधा को समझना

इस लेख में, लॉगिंग की प्रोसेस के बारे में बताया गया है. इसमें लॉग के स्टैंडर्ड, लेवल के दिशा-निर्देश, क्लास, मकसद, और मल्टीस्टैक अनुमान शामिल हैं.

लॉग के लिए स्टैंडर्ड

Android में लॉग इन करना मुश्किल है, क्योंकि इसमें logcat में इस्तेमाल किए गए अलग-अलग स्टैंडर्ड का इस्तेमाल किया जाता है. इस्तेमाल किए गए मुख्य मानकों के बारे में यहां बताया गया है:

Source	उदाहरण	स्टैक लेवल के लिए दिशा-निर्देश
`RFC 5424` (`syslog` स्टैंडर्ड)	Linux kernel, कई Unix ऐप्लिकेशन	कर्नेल, सिस्टम डेमन
`android.util.Log`	Android फ़्रेमवर्क + ऐप्लिकेशन लॉगिंग	Android फ़्रेमवर्क और सिस्टम ऐप्लिकेशन
`java.util.logging.Level`	Java में सामान्य लॉगिंग	सिस्टम ऐप्लिकेशन नहीं

पहली इमेज: लॉग लेवल के मानक.

हालांकि, इनमें से हर स्टैंडर्ड का लेवल एक जैसा होता है, लेकिन इनमें जानकारी की बारीकी अलग-अलग होती है. अलग-अलग स्टैंडर्ड के लिए, इनके बराबर के अनुमानित वैल्यू इस तरह हैं:

आरएफ़सी 5424 लेवल	आरएफ़सी 5424 के हिसाब से गंभीरता	आरएफ़सी 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`

दूसरी इमेज: syslog, Android, और Java के लॉगिंग लेवल.

लॉग लेवल के लिए दिशा-निर्देश

हर लॉग स्टैंडर्ड के लिए, मौजूदा दिशा-निर्देश दिए गए हैं. चुना गया लॉग लेवल, इस्तेमाल किए जा रहे सही स्टैंडर्ड के मुताबिक होता है. जैसे, कर्नेल डेवलपमेंट के लिए syslog स्टैंडर्ड का इस्तेमाल करना.

लॉग लेवल के क्रम, सबसे कम से लेकर सबसे ज़्यादा तक, यहां दिए गए तीन आंकड़ों में दिखाए गए हैं:

`ERROR`	ये लॉग हमेशा सेव रहते हैं.
`WARN`	ये लॉग हमेशा सेव रहते हैं.
`INFO`	ये लॉग हमेशा सेव रहते हैं.
`DEBUG`	इन लॉग को कंपाइल किया जाता है, लेकिन रनटाइम के दौरान हटा दिया जाता है.
`VERBOSE`	ऐप्लिकेशन को बनाने के दौरान को छोड़कर, इन लॉग को कभी भी ऐप्लिकेशन में कंपाइल नहीं किया जाता.

तीसरी इमेज: android.util.Log

`CONFIG`	स्टैटिक कॉन्फ़िगरेशन मैसेज के लिए मैसेज लेवल
`FINE`	मैसेज लेवल पर ट्रैकिंग की जानकारी
`FINER`	ट्रैकिंग के बारे में ज़्यादा जानकारी देने वाला मैसेज
`FINEST`	ट्रैकिंग के बारे में ज़्यादा जानकारी देने वाले मैसेज के बारे में बताता है
`INFO`	जानकारी देने वाले मैसेज के लिए मैसेज लेवल
`SEVERE`	गंभीर गड़बड़ी का पता चलने पर मिलने वाला मैसेज लेवल
`WARNING`	संभावित समस्या की जानकारी देने वाला मैसेज लेवल

चौथी इमेज: java.util.Logging.Level.

0	आपातकालीन कॉल	सिस्टम का इस्तेमाल नहीं किया जा सकता
1	सूचना	तुरंत कार्रवाई करना ज़रूरी है
2	सबसे अहम	गंभीर स्थितियां
3	कोई गड़बड़ी हुई	गड़बड़ी की स्थितियां
4	चेतावनी	चेतावनी की शर्तें
5	सूचना	सामान्य, लेकिन अहम स्थिति
6	सूचनात्मक	जानकारी देने वाले मैसेज
7	डीबग	डीबग-लेवल के मैसेज

पांचवीं इमेज: RFC 5424 - सेक्शन 6.2.1.

ऐप्लिकेशन लॉगिंग

चुनिंदा लॉगिंग, Log#isLoggable का इस्तेमाल करके TAG के हिसाब से android.util.Log क्लास के साथ की जाती है, जैसा कि यहां दिखाया गया है:

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 जांच करने पर, ऐप्लिकेशन कोड में लॉग के निशान बचे रहते हैं. बूलियन DEBUG फ़्लैग, 'कॉम्पाइलर ऑप्टिमाइज़ेशन' का इस्तेमाल करके लॉग ट्रेस को बायपास करते हैं. ये ऑप्टिमाइज़ेशन, false पर सेट होते हैं, जैसा कि यहां दिखाया गया है:

private final static boolean DEBUG = false;


…
If (DEBUG) {
 Log.v("FOO_TAG", "Extra debug logging.");
}

ध्यान दें: इस संदर्भ में, DEBUG का "डीबग" के लॉग की गंभीरता से कोई लेना-देना नहीं है. इसका मतलब, डेवलपमेंट से जुड़े फ़्लैग से है.

R8 के ज़रिए, ProGuard के नियमों के ज़रिए हर APK के लिए, संकलन के समय लॉगिंग को हटाया जा सकता है. यहां दिए गए उदाहरण में, android.util.Log के लिए INFO लेवल के नीचे की सभी गतिविधियों को हटा दिया गया है:

# 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

यह कई तरह के ऐप्लिकेशन बिल्ड (उदाहरण के लिए, डेवलपमेंट बिल्ड बनाम रिलीज़ बिल्ड) को मैनेज करने के लिए मददगार है. इनमें, बुनियादी कोड एक जैसा होता है, लेकिन लॉग के लिए अनुमति वाले लेवल अलग-अलग होते हैं. ऐप्लिकेशन (खास तौर पर सिस्टम ऐप्लिकेशन) के लिए, साफ़ तौर पर एक नीति सेट की जानी चाहिए और उसका पालन किया जाना चाहिए. इससे यह तय किया जा सकता है कि बिल्ड टाइप और रिलीज़ की उम्मीदें, लॉग आउट पर कैसे असर डालती हैं.

Android Runtime (ART) में सिस्टम लॉगिंग

सिस्टम ऐप्लिकेशन और सेवाओं के लिए कई क्लास उपलब्ध हैं:

क्लास	मकसद
`android.telephony.Rlog`	रेडियो लॉगिंग
`android.util.Log`	ऐप्लिकेशन की सामान्य लॉगिंग
`android.util.EventLog`	सिस्टम इंटिग्रेटर डाइग्नोस्टिक्स इवेंट लॉगिंग
`android.util.Slog`	प्लैटफ़ॉर्म फ़्रेमवर्क लॉगिंग

छठी इमेज: सिस्टम लॉग की उपलब्ध क्लास और उनके मकसद.

android.util.Log और android.util.Slog, दोनों एक ही लॉग लेवल के स्टैंडर्ड का इस्तेमाल करते हैं. हालांकि, Slog एक @hide क्लास है, जिसका इस्तेमाल सिर्फ़ प्लैटफ़ॉर्म कर सकता है. EventLog लेवल, /system/etc/event-log-tags में मौजूद event.logtags फ़ाइल की एंट्री से मैप किए जाते हैं.

नेटिव लॉगिंग

C/C++ में लॉगिंग, syslog स्टैंडर्ड के हिसाब से होती है. इसमें syslog(2) का इस्तेमाल, Linux kernel syslog के लिए किया जाता है, जो printk बफ़र को कंट्रोल करता है. साथ ही, syslog(3) का इस्तेमाल सामान्य सिस्टम लॉगर के लिए किया जाता है. Android, सामान्य सिस्टम लॉगिंग के लिए 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`

सातवीं इमेज: liblog रैपर.

Android में लॉगिंग के लिए, ऐसे इंटरफ़ेस हैं जो सीधे liblog इस्तेमाल करने के बजाय, ज़्यादा पसंद किए जाते हैं. इन इंटरफ़ेस के बारे में यहां बताया गया है:

लाइब्रेरी इस्तेमाल

async_safe यह लाइब्रेरी, सिर्फ़ ऐसे एनवायरमेंट से लॉग करने के लिए है जहां असाइनमेंट के पूरा होने का सिग्नल मिलने में देरी नहीं होती

libbase लॉगिंग लाइब्रेरी, जो लॉगिंग के लिए C++ स्ट्रीम इंटरफ़ेस उपलब्ध कराती है. यह इंटरफ़ेस, Google स्टाइल (glog) लॉगिंग जैसा ही होता है. libbase का इस्तेमाल, बाहरी दोनों प्रोजेक्ट में किया जा सकता है. साथ ही, यह libbase_ndk का इस्तेमाल करने वाले ऐप्लिकेशन में भी उपलब्ध है.

लाइब्रेरी	इस्तेमाल
`async_safe`	यह लाइब्रेरी, सिर्फ़ ऐसे एनवायरमेंट से लॉग करने के लिए है जहां असाइनमेंट के पूरा होने का सिग्नल मिलने में देरी नहीं होती
`libbase`	लॉगिंग लाइब्रेरी, जो लॉगिंग के लिए C++ स्ट्रीम इंटरफ़ेस उपलब्ध कराती है. यह इंटरफ़ेस, Google स्टाइल (glog) लॉगिंग जैसा ही होता है. `libbase` का इस्तेमाल, बाहरी दोनों प्रोजेक्ट में किया जा सकता है. साथ ही, यह `libbase_ndk` का इस्तेमाल करने वाले ऐप्लिकेशन में भी उपलब्ध है.

आठवां चित्र: लॉग की उच्च लेवल की लाइब्रेरी.

मल्टीस्टैक के अनुमान

ज़्यादा जानकारी और लेवल के इंटेंट में अंतर होने की वजह से, अलग-अलग लॉगिंग स्टैंडर्ड के बीच कोई साफ़ या सटीक मैच नहीं होता. उदाहरण के लिए, गड़बड़ी के लॉग के लिए java.util.logging.Level और android.util.Log लेवल, 1:1 मैच नहीं करते:

java.util.Logging.Level	android.util.Log
गंभीर	`Log.wtf`
गंभीर	`Log.e`

चित्र 9: स्टैंडर्ड Java लॉगिंग बनाम Android लॉगिंग में गड़बड़ी का लेवल.

ऐसे मामलों में, यह तय करने के लिए कि कौनसा लेवल लागू करना है, अलग-अलग स्टैंडर्ड का इस्तेमाल करें.

एक से ज़्यादा स्टैक लेवल कॉम्पोनेंट वाले सिस्टम के डेवलपमेंट के दौरान, यह तय करने के लिए कि हर कॉम्पोनेंट के लिए किस स्टैंडर्ड का इस्तेमाल करना है, पहले चित्र में दिया गया तरीका अपनाएं. टीयर मैसेजिंग के बारे में जानने के लिए, दूसरे चित्र को देखें.

सुरक्षा और निजता

व्यक्तिगत पहचान से जुड़ी जानकारी (पीआईआई) को लॉग न करें. इसमें ये जानकारी शामिल है:

ईमेल पते
टेलीफ़ोन नंबर
नाम

इसी तरह, कुछ जानकारी को संवेदनशील माना जाता है, भले ही उससे व्यक्ति की पहचान साफ़ तौर पर ज़ाहिर न की गई हो.

उदाहरण के लिए, टाइमज़ोन की जानकारी को व्यक्तिगत पहचान से जुड़ी जानकारी नहीं माना जाता. हालांकि, इससे उपयोगकर्ता की जगह के बारे में अनुमान लगाया जा सकता है.

लॉग की नीति और स्वीकार की जा सकने वाली जानकारी को रिलीज़ करने से पहले, सुरक्षा और निजता की समीक्षा के तहत रखा जाना चाहिए.

डिवाइस लॉग से

android.permission.READ_LOGS का इस्तेमाल करके, डिवाइस के सभी लॉग ऐक्सेस करने पर पाबंदी है:

अगर बैकग्राउंड में चल रहा कोई ऐप्लिकेशन, सभी डिवाइस लॉग का ऐक्सेस मांगता है, तो अनुरोध अपने-आप अस्वीकार कर दिया जाता है. ऐसा तब तक होता है, जब तक ऐप्लिकेशन:

सिस्टम का यूआईडी शेयर करता है.
नेटिव सिस्टम प्रोसेस (UID < APP_UID) का इस्तेमाल करता है.
DropBoxManager का इस्तेमाल करता है.
सिर्फ़ इवेंट लॉग बफ़र को ऐक्सेस करता है.
EventLog API का इस्तेमाल करता है.
इंस्ट्रूमेंट किए गए टेस्ट का इस्तेमाल करता हो.

अगर फ़ोरग्राउंड में मौजूद कोई ऐप्लिकेशन READ_LOGS के साथ डिवाइस लॉग का ऐक्सेस मांगता है, तो सिस्टम उपयोगकर्ता को ऐक्सेस के अनुरोध को स्वीकार या अस्वीकार करने के लिए कहता है.