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

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

एक से ज़्यादा उपयोगकर्ताओं को टेस्ट करना
संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

इस पेज पर, Android प्लैटफ़ॉर्म पर एक से ज़्यादा उपयोगकर्ताओं की जांच करने के अहम पहलुओं के बारे में बताया गया है. बहु-उपयोगकर्ता समर्थन लागू करने के बारे में जानकारी के लिए, देखें कई उपयोगकर्ताओं के साथ काम करना.

डिवाइस पाथ

नीचे दी गई टेबल में डिवाइस के कई पाथ और उनका समाधान करने के तरीके की सूची दी गई है. पाथ कॉलम में मौजूद सभी वैल्यू, उपयोगकर्ता के हिसाब से सैंडबॉक्स की गई मेमोरी होती हैं. Android के स्टोरेज की कहानी समय के साथ बदल गई है; इसे पढ़ें ज़्यादा जानकारी के लिए, स्टोरेज से जुड़ा दस्तावेज़.

पाथ	सिस्टम पाथ (ज़रूरी नहीं)	मकसद
`/data/user/{userId}/{app.path}`	`/data/data`	ऐप्लिकेशन के लिए स्टोरेज
`/storage/emulated/{userId}`	`/sdcard`	शेयर किया गया इंटरनल स्टोरेज
`/data/media/{userId}`	कोई नहीं	उपयोगकर्ता का मीडिया डेटा (जैसे, संगीत, वीडियो)
`/data/system/users/{userId}`	कोई नहीं	हर उपयोगकर्ता के हिसाब से सिस्टम कॉन्फ़िगरेशन/स्टेटस सिर्फ़ सिस्टम ऐप्लिकेशन इसे ऐक्सेस कर सकते हैं

उपयोगकर्ता के हिसाब से पाथ का इस्तेमाल करने का उदाहरण यहां दिया गया है:

# to access user 10's private application data for app com.bar.foo:
$ adb shell ls /data/user/10/com.bar.foo/

सभी उपयोगकर्ताओं के बीच adb इंटरैक्शन

एक से ज़्यादा उपयोगकर्ताओं के साथ काम करते समय, कई adb निर्देश काम के होते हैं. कुछ ये निर्देश सिर्फ़ Android 9 और ज़्यादा:

adb shell am instrument --user <userId> ने इंस्ट्रुमेंटेशन टेस्ट किया किसी खास उपयोगकर्ता को नुकसान पहुंचता है. डिफ़ॉल्ट रूप से, इसमें मौजूदा उपयोगकर्ता खाते का इस्तेमाल किया जाता है.
adb install --user <userId> किसी खास उपयोगकर्ता के लिए पैकेज इंस्टॉल करता है. यह पक्का करने के लिए कि सभी उपयोगकर्ताओं के लिए पैकेज इंस्टॉल हो गया है, आपको हर उपयोगकर्ता के लिए इसे कॉल करना होगा.
adb uninstall --user <userId> किसी उपयोगकर्ता के लिए पैकेज को अनइंस्टॉल करता है. सभी उपयोगकर्ताओं को अनइंस्टॉल करने के लिए, --user फ़्लैग के बिना कॉल करें.
adb shell am get-current-user को मौजूदा (फ़ोरग्राउंड) यूज़र आईडी मिलता है.
adb shell pm list users को सभी मौजूदा उपयोगकर्ताओं की सूची मिलती है.
adb shell pm create-user एक नया उपयोगकर्ता बनाता है और आईडी दिखाता है.
adb shell pm remove-user, आईडी की मदद से किसी उपयोगकर्ता को हटाता है.
adb shell pm disable --user <userId> किसी खास उपयोगकर्ता के लिए पैकेज बंद कर देता है.
adb shell pm enable --user <userId> किसी खास उपयोगकर्ता के लिए पैकेज चालू करता है.
adb shell pm list packages --user <userId> किसी उपयोगकर्ता के लिए पैकेज की सूची दिखाता है. पैकेज चालू होने पर -e और बंद होने पर -d दिखता है. डिफ़ॉल्ट रूप से, यह हमेशा सिस्टम उपयोगकर्ता के लिए सूची बनाता है.

यहां दी गई जानकारी से यह समझने में मदद मिलती है कि adb एक से ज़्यादा उपयोगकर्ताओं के साथ कैसे काम करता है:

adb (या ज़्यादा सटीक तौर पर adbd डेमन) हमेशा सिस्टम उपयोगकर्ता (उपयोगकर्ता आईडी = 0) के तौर पर चलता है. इससे कोई फ़र्क़ नहीं पड़ता कि फ़िलहाल कौनसा उपयोगकर्ता चालू है. इसलिए, उपयोगकर्ता पर निर्भर डिवाइस पाथ (जैसे कि /sdcard/) हमेशा सिस्टम उपयोगकर्ता के तौर पर रिज़ॉल्व होते हैं. ज़्यादा जानकारी के लिए, डिवाइस पाथ देखें.
अगर किसी डिफ़ॉल्ट उपयोगकर्ता की जानकारी नहीं दी गई है, तो हर adb सब-कमांड का अलग-अलग होता है उपयोगकर्ता. सबसे सही तरीका यह है कि am get-current-user का इस्तेमाल करके उपयोगकर्ता आईडी पाएं. इसके बाद, --user <userId> का इस्तेमाल उन सभी निर्देशों के लिए करें जिनमें यह काम करता है. अश्लील कॉन्टेंट Android 9 तक, सभी निर्देशों के लिए उपयोगकर्ता फ़्लैग काम नहीं करते थे.
Android 9 से, दूसरे उपयोगकर्ताओं के /sdcard पाथ का ऐक्सेस नहीं दिया जाएगा. जांच के दौरान फ़ाइलें वापस पाने का तरीका जानने के लिए, एक से ज़्यादा उपयोगकर्ताओं के डेटा के लिए कॉन्टेंट उपलब्ध कराने वाली कंपनी देखें.

एक से ज़्यादा उपयोगकर्ताओं के डेटा के लिए कॉन्टेंट देने वाला प्रोग्राम

adb, सिस्टम यूज़र के तौर पर काम करता है और डेटा को Android 9 और उसके बाद के वर्शन में सैंडबॉक्स किया जाता है. इसलिए, आपको इन कामों के लिए कॉन्टेंट उपलब्ध कराने वालों का इस्तेमाल करना होगा: किसी नॉन-सिस्टम उपयोगकर्ता से कोई भी टेस्ट डेटा ले सकते हैं. ऐसा करना ज़रूरी नहीं है, अगर:

adbd, adb root के ज़रिए रूट के तौर पर चल रहा है. ऐसा सिर्फ़ userdebug या usereng बिल्ड का इस्तेमाल करके किया जा सकता है.
फ़ाइलों को पुश या पुल करने के लिए, Trade Federation (Tradefed) के ITestDevice का इस्तेमाल किया जा रहा है. ऐसे में, अपने टेस्ट कॉन्फ़िगरेशन में /sdcard/ पाथ का इस्तेमाल करें. उदाहरण के लिए, NativeDevice.java में pushFile का सोर्स कोड देखें.

जब कोई कॉन्टेंट प्रोवाइडर सेकंडरी उपयोगकर्ता के तौर पर काम कर रहा हो, तो उसे ऐक्सेस करने के लिए, adb shell content कमांड के साथ सही user, uri, और अन्य पैरामीटर का इस्तेमाल करें.

ऐप्लिकेशन डेवलपर के लिए समस्या हल करने का तरीका

push या pull निर्देश के बजाय, adb content और ContentProvider के किसी इंस्टेंस का इस्तेमाल करके, टेस्ट फ़ाइलों के साथ इंटरैक्ट करें.

ऐप्लिकेशन के ज़रिए होस्ट किए गए ContentProvider का एक इंस्टेंस बनाएं, जो काम कर सके और ज़रूरत पड़ने पर फ़ाइलों को सेव करें. ऐप्लिकेशन के स्टोरेज का इस्तेमाल करें.
फ़ाइलों को पुश करने या पुल करने के लिए, adb shell content read या write निर्देशों का इस्तेमाल करें.

मीडिया फ़ाइलों के लिए समस्या हल करने का तरीका

मीडिया फ़ाइलों को एसडी कार्ड के मीडिया पार्टिशन में पुश करने के लिए, MediaStore सार्वजनिक का इस्तेमाल करें एपीआई. उदाहरण के लिए:

# push MVIMG_20190129_142956.jpg to /storage/emulated/10/Pictures
# step 1
$ adb shell content insert --user 10 --uri content://media/external/images/media/ --bind _display_name:s:foo.jpg

# step 2
$ adb shell content query --user 10 --projection _id --uri content://media/external/images/media/ --where "_display_name=\'foo.jpg\'"

# step 3
$ adb shell content write --user 10 --uri content://media/external/images/media/8022 < MVIMG_20190129_142956.jpg

सामान्य कॉन्टेंट देने वाला इंस्टॉल करें

कॉन्टेंट उपलब्ध कराने वाली किसी मौजूदा सेवा को इंस्टॉल और इस्तेमाल करें. यह सेवा, उपयोगकर्ता के हिसाब से बनाए गए /sdcard पाथ में फ़ाइलों को पढ़ती और लिखती है.

make TradefedContentProvider का इस्तेमाल करके, सोर्स से TradefedContentProvider.apk बनाएं:

```
# install content provider apk
$ adb install --user 10 -g TradefedContentProvider.apk

# pull some_file.txt
$ adb shell content read --user 10 --uri content://android.tradefed.contentprovider/sdcard/some_file.txt > local_file.txt

# push local_file.txt
$ adb shell content write --user 10 --uri content://android.tradefed.contentprovider/sdcard/some_file.txt < local_file.txt
```

Trade Federation की मल्टी-यूज़र सुविधा

Tradefed, Android का आधिकारिक टेस्ट हार्नेस है. इस सेक्शन में, कई उपयोगकर्ताओं वाले टेस्ट के हिसाब से सही है या नहीं.

स्टेटस की जांच करने वाले

सिस्टम स्टेटस चेकर (एसएससी) को टारगेट तैयार करने वाले से पहले चलाया जाता है और उनका क्लीनअप बाद किया जाता है उन तैयार करने वालों में शामिल न हो.

UserChecker एक से ज़्यादा उपयोगकर्ताओं की टेस्टिंग करते समय डेवलपर की मदद करने के लिए साफ़ तौर पर तय किया गया है. यह क्या किसी टेस्ट से डिवाइस पर उपयोगकर्ताओं की स्थिति बदल गई है (उदाहरण के लिए, ने उपयोगकर्ताओं को टियरडाउन में हटाए बिना उन्हें बनाया होगा). इसके अलावा, अगर user-cleanup सेट है, तो जांच के बाद यह अपने-आप क्लीन अप करने की कोशिश करता है. साथ ही, जांच को ठीक करने के लिए, काम की गड़बड़ियां भी दिखाता है.

<system_checker class="com.android.tradefed.suite.checker.UserChecker" >
    <option name="user-cleanup" value="true" />
</system_checker>

टारगेट तैयार करने वाला व्यक्ति

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

जिन डिवाइस टाइप में कोई सेकंडरी उपयोगकर्ता नहीं है उनके लिए, इस सेटिंग में, सेकंडरी उपयोगकर्ता बनाने और उस पर स्विच करने के लिए, CreateUserPreparer AndroidTest.xml. टेस्ट खत्म होने के बाद, प्रिपरर वापस स्विच करता है और सेकंडरी उपयोगकर्ता को मिटा देता है.

<target_preparer
  class="com.google.android.tradefed.targetprep.CreateUserPreparer" >
</target_preparer>

अगर आपको जो उपयोगकर्ता टाइप चाहिए वह डिवाइस पर पहले से मौजूद है, तो इसका इस्तेमाल करें मौजूदा उपयोगकर्ता पर स्विच करने के लिए SwitchUserTargetPreparer. user-type के लिए सामान्य वैल्यू में system या secondary शामिल हैं.

<target_preparer
  class="com.android.tradefed.targetprep.SwitchUserTargetPreparer">
    <option name="user-type" value="secondary" />
</target_preparer>

होस्ट-ड्रिवन टेस्ट

कुछ मामलों में, किसी टेस्ट में टेस्ट के दौरान उपयोगकर्ताओं को स्विच करना पड़ता है. ये काम न करें किसी डिवाइस-साइड टेस्ट फ़्रेमवर्क के अंदर से स्विच कर सकता है, जैसे यूज़र इंटरफ़ेस (यूआई) ऑटोमेटर, क्योंकि परीक्षण प्रक्रिया को किसी भी समय बंद किया जा सकता है. इसके बजाय, होस्ट-साइड टेस्ट फ़्रेमवर्क का इस्तेमाल करें. जैसे, Tradefed का होस्ट-ड्रिवन टेस्ट फ़्रेमवर्क. इससे ITestDevice को ऐक्सेस किया जा सकता है. साथ ही, ज़रूरत के हिसाब से उपयोगकर्ता को मैनिप्युलेट किया जा सकता है.

होस्ट-ड्रिवन टेस्ट के लिए UserChecker का इस्तेमाल करें. इससे उपयोगकर्ता की स्थिति में बदलाव होता है. ऐसा इसलिए, क्योंकि इससे यह पक्का होता है कि टेस्ट के बाद, डेटा को सही तरीके से मिटा दिया जाए. UserChecker के बारे में स्टेटस की जांच करने वाले टूल में बताया गया है.