लोकल प्रोफ़ाइलिंग के लिए डीबग करने के निर्देश

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

अनुरोध संख्या सीमित करने की सुविधा बंद करना

लोकल टेस्टिंग के दौरान, requestProfiling अनुरोधों के लिए, ऐप्लिकेशन प्रोसेस और सिस्टम अनुरोध संख्या सीमित करने की सुविधा को बंद करने के लिए, यह device_config कमांड चलाएं:

adb shell device_config put profiling_testing rate_limiter.disabled true

टेस्टिंग पूरी होने के बाद, फ़्लैग को रीसेट करें:

adb shell device_config delete profiling_testing rate_limiter.disabled

एडीबी का इस्तेमाल करके प्रोफ़ाइलें पुल करना

रूट ऐक्सेस वाले डिवाइस पर, स्थानीय तौर पर किसी ऐसी प्रोफ़ाइल की जांच करने के लिए जिसमें से संवेदनशील जानकारी हटाई गई है, getResultFilePath से मिले पाथ के साथ adb pull चलाएं:

# Pull a profile
adb pull /data/user/0/<com.example.myapp>/files/profiling/<profile-file-name>

कुछ समय के लिए उपलब्ध और बिना बदलाव वाले नतीजों को सेव रखना

लोकल तौर पर प्रोफ़ाइलिंग की जांच करते समय, नतीजों को /data/misc/perfetto-traces/profiling/ पर मौजूद अस्थायी डायरेक्ट्री में सेव रखा जा सकता है. सिस्टम ट्रेस करने की प्रक्रिया के दौरान, बिना बदलाव किए गए डेटा की तुलना, बदलाव किए गए डेटा से करने पर, आपको यह समझने में मदद मिलती है कि बदलाव करने के दौरान कौनसा डेटा हटाया गया है.

आपके डिवाइस पर मौजूद Android वर्शन के हिसाब से, कुछ समय के लिए सेव किए गए और बिना बदलाव वाले नतीजों को सेव रखने का तरीका तय होता है:

• Android 16 (एपीआई लेवल 36) और इसके बाद के वर्शन: आपके पास अस्थायी डायरेक्ट्री में, बिना बदलाव किए गए (जहां लागू हो) और बदलाव किए गए, दोनों तरह के नतीजे सेव रखने का विकल्प होता है. Android 16 में इस डायरेक्ट्री को बड़ा किया गया है, ताकि रूट ऐक्सेस के बिना सभी बिल्ड टाइप पर adb pull का इस्तेमाल करके इसे ऐक्सेस किया जा सके. हालांकि, Android 15 में /data/misc/perfetto-traces/profiling/ को पढ़ने के लिए रूट ऐक्सेस की ज़रूरत होती है. सिस्टम को अस्थायी नतीजे मिटाने से रोकने के लिए, यह निर्देश चलाएं:

  adb shell device_config put profiling_testing delete_temporary_results.disabled true
  

• Android 15 (एपीआई लेवल 35): कुछ समय के लिए इस्तेमाल होने वाली डायरेक्ट्री में, सिर्फ़ उस नतीजे को सेव रखा जा सकता है जिसमें बदलाव नहीं किया गया है. इसे सिर्फ़ रूट ऐक्सेस वाले बिल्ड पर adb से ऐक्सेस किया जा सकता है. (आपके ऐप्लिकेशन को अब भी अपनी /data/user/0/<app>/files/profiling/ डायरेक्ट्री में, बदलाव की गई प्रोफ़ाइल मिलती है. इसे आपका ऐप्लिकेशन कोड किसी भी बिल्ड पर पढ़ या कॉपी कर सकता है. हालांकि, /data/user/0/... से सीधे तौर पर adb pull के साथ पुल करने के लिए, रूट ऐक्सेस की ज़रूरत होती है. इसके अलावा, डीबग किए जा सकने वाले बिल्ड पर adb shell run-as <app> की ज़रूरत होती है.) सिस्टम को बिना बदलाव किए गए ट्रेस मिटाने से रोकने के लिए, यह कमांड चलाएं:

  adb shell device_config put profiling_testing delete_unredacted_trace.disabled true
  

प्रोफ़ाइल कैप्चर करने के बाद, सेव की गई फ़ाइल को कुछ समय के लिए बनाई गई डायरेक्ट्री से निकालें:

# Pull a retained redacted profile (Android 16 and higher)
adb pull /data/misc/perfetto-traces/profiling/<trace-name>.<profile-type-ext>

# Pull an unredacted system trace
adb pull /data/misc/perfetto-traces/profiling/<trace-name>.perfetto-trace-unredacted

इन कमांड में, <trace-name>, ProfilingResult.getResultFilePath से मिले पाथ का बेस फ़ाइल नाम (बिना एक्सटेंशन के) है. साथ ही, सिस्टम ट्रेस करने की प्रक्रिया की बिना बदलाव वाली कॉपी, .perfetto-trace एक्सटेंशन में -unredacted जोड़ती है. फ़ाइल नाम के स्ट्रक्चर और <profile-type-ext> वैल्यू के बारे में ज़्यादा जानने के लिए, फ़ाइल की जगह और नाम रखने के फ़ॉर्मैट देखें.

adb shell device_config delete profiling_testing delete_temporary_results.disabled
adb shell device_config delete profiling_testing delete_unredacted_trace.disabled

ट्रिगर टेस्टिंग के लिए, बैकग्राउंड ट्रेस को हमेशा चालू रखें

सिस्टम बैकग्राउंड ट्रेस, प्रोडक्शन में रैंडम इंटरवल पर चलते हैं. इसलिए, लोकल लेवल पर ट्रिगर पर आधारित प्रोफ़ाइलिंग की जांच करना मुश्किल हो सकता है. सिस्टम को लगातार बैकग्राउंड ट्रेस चलाने और आपके ऐप्लिकेशन के ट्रिगर के लिए, सिस्टम-लेवल पर अनुरोध संख्या सीमित करने की सुविधा को बायपास करने के लिए, system_triggered_profiling.testing_package_name सेट करें:

adb shell device_config put profiling_testing system_triggered_profiling.testing_package_name <com.example.myapp>

setRateLimitingPeriodHours के साथ कॉन्फ़िगर किया गया हर ट्रिगर का कूलडाउन अब भी लागू होता है. यह मोड तब तक लगातार चलता रहता है, जब तक इसे बंद नहीं किया जाता. इसलिए, टेस्टिंग पूरी होने के बाद फ़्लैग को हटा दें:

adb shell device_config delete profiling_testing system_triggered_profiling.testing_package_name

डीबग करने के लिए काम के निर्देश

Android 16 (एपीआई लेवल 36) और इसके बाद के वर्शन पर, Profiling मॉड्यूल के नए वर्शन के साथ, adb के बजाय cmd profiling_service टूल का इस्तेमाल किया जा सकता है. इससे, ज़्यादा जानकारी वाली लॉगिंग को चालू किया जा सकता है, मांग पर प्रोफ़ाइल कलेक्शन को ट्रिगर किया जा सकता है, और सीधे कमांड लाइन से ट्रिगर की जांच की जा सकती है.

वर्बोस डीबग लॉगिंग चालू करें

logcat में ज़्यादा जानकारी वाले ProfilingService लॉग चालू करने और अनुरोध को मैनेज करने और डिलीवरी से जुड़ी समस्या का पता लगाने के लिए, यह कमांड चलाएं:

adb shell cmd profiling_service enable-logs true

मांग पर प्रोफ़ाइल कलेक्शन का अनुरोध करना

कमांड लाइन से किसी खास पैकेज के लिए, तुरंत प्रोफ़ाइल कैप्चर करने की प्रोसेस शुरू करने के लिए, यह कमांड चलाएं:

adb shell cmd profiling_service request-profiling <profiling_type> <com.example.myapp> [--user <user_id>] [--duration <duration_ms>] [--sources <sources>]

इस निर्देश में, <profiling_type>, ProfilingManager से मिली इंटिजर कॉन्स्टेंट वैल्यू है. 1, Java हीप डंप के लिए है, 2, हीप प्रोफ़ाइल के लिए है, 3, स्टैक सैंपलिंग के लिए है या 4, सिस्टम ट्रेस करने की प्रक्रिया के लिए है. मेमोरी और स्टैक प्रोफ़ाइल के लिए, टारगेट ऐप्लिकेशन की प्रोसेस चालू होनी चाहिए. अनुरोध पर, रेट लिमिटर लागू होता है. हालांकि, ऐसा तब होता है, जब इसे बंद न किया गया हो. साथ ही, पूरा किया गया ProfilingResult सिर्फ़ उन ग्लोबल लिसनर को डिलीवर किया जाता है जो registerForAllProfilingResults के साथ रजिस्टर किए गए हैं.

ट्रिगर रजिस्टर करना और सिम्युलेट करना

किसी पैकेज के लिए ट्रिगर को रजिस्टर करने या सिम्युलेट किए गए ट्रिगर इवेंट को ट्रिगर करने और ट्रिगर कॉलबैक हैंडलिंग की पुष्टि करने के लिए, ये कमांड चलाएं:

adb shell cmd profiling_service add-trigger <trigger_type> <com.example.myapp> [--user <user_id>]
adb shell cmd profiling_service trigger <trigger_type> <com.example.myapp> [--user <user_id>]

इन कमांड में, <trigger_type>, ProfilingTrigger से मिली इंटीजर कॉन्स्टेंट वैल्यू है. उदाहरण के लिए, TRIGGER_TYPE_APP_FULLY_DRAWN के लिए 1, TRIGGER_TYPE_ANR के लिए 2 या TRIGGER_TYPE_OOM के लिए 7. add-trigger को चलाने पर, ट्रिगर को 0 घंटे के कूलडाउन के साथ रजिस्टर किया जाता है. इससे उस ट्रिगर टाइप के लिए पहले से मौजूद किसी भी रजिस्ट्रेशन को बदल दिया जाता है. बैकग्राउंड ट्रेस का स्नैपशॉट सेव करने वाले ट्रिगर को सिम्युलेट करने के लिए, बैकग्राउंड ट्रेस चालू होना चाहिए. जैसे, 1 या 2. ट्रिगर की जांच करने के लिए, बैकग्राउंड ट्रेस को हमेशा चालू रखने का तरीका जानने के लिए, ट्रिगर की जांच करने के लिए, बैकग्राउंड ट्रेस को हमेशा चालू रखना लेख पढ़ें.

ProfilingManager की पूरी स्थिति की जानकारी इकट्ठा करना

Android 16 (एपीआई लेवल 36) और इसके बाद के वर्शन पर, Profiling मॉड्यूल के नए वर्शन के साथ, profiling_service के लिए dumpsys को चलाया जा सकता है. इससे समस्याओं का पता लगाया जा सकता है और ProfilingManager की मौजूदा स्थिति की जांच की जा सकती है:

adb shell dumpsys profiling_service

dumpsys profiling_service आउटपुट का मकसद सिर्फ़ जानकारी देना और डीबग करना है. इसका फ़ॉर्मैट बदला जा सकता है. यह सेवा की अंदरूनी स्थिति का स्नैपशॉट देता है, जिसमें ये शामिल हैं:

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