गैर-रूट किए गए डिवाइस पर ADB के माध्यम से बैकअप / रिस्टोर एसएमएस / एमएमएस?


10

क्या डिवाइस के रूट नहीं होने पर, एडीबी का उपयोग करके एसएमएस / एमएमएस संदेशों को बैकअप / रिस्टोर करने का कोई तरीका है?

  • adb pull/data/data/com.android.providers.telephony/databases/mmssms.dbअगर यह असुरक्षित (रूट) मोड में नहीं चल रहा है , तो संबंधित डेटाबेस ( ) एडीबी द्वारा पढ़ा नहीं जा सकता है, क्योंकि यहां काम नहीं करेगा
  • adb shell "cat /data/data/com.android.providers.telephony/databases/mmssms.db > /sdcard/mmssms.db रूट एक्सेस के बिना भी काम नहीं करता है
  • adb backup किसी कारण से मैंने इस डेटाबेस को उस डिवाइस पर कवर नहीं किया है जिसे मैंने (खाली बैकअप - परिणामी फ़ाइल में बैकअप हेडर के सिर्फ 41 बाइट्स के साथ) चेक किया है।

मुझे विशेष रूप से आश्चर्य है कि adb backupयह कवर क्यों नहीं करता है। यदि यह "गोपनीयता कारणों" के लिए है, तो उसी को संपर्क डेटाबेस पर लागू करना चाहिए - जो स्पष्ट रूप से समर्थित है।

संदर्भ:

तो: एक गैर-निहित डिवाइस पर कोई समाधान? ध्यान दें कि मैं ऐप-आधारित समाधान के लिए नहीं कह रहा हूं । मुझे पूरी जानकारी है कि इसके लिए कई ऐप उपलब्ध हैं । मैं विशेष रूप से एक "शेल आधारित समाधान" चाहता हूं, जिसका उपयोग एडीबी के माध्यम से किया जाना है।


" मैं एक ऐप-आधारित समाधान के लिए नहीं पूछ रहा हूं " - फोरेंसिक फिर से?
Firelord

1
अधिमानतः हाँ (अन्य पाठकों के लिए: पसंदीदा समाधानों को डिवाइस पर संशोधित किसी भी चीज़ की आवश्यकता नहीं है)। डिवाइस-इन-क्वेश्चन पर विचार करें जो पहले से ही "अपर्याप्त मेमोरी" की रिपोर्ट करता है, इसलिए कुछ स्थापित करना संभव नहीं है। जैसा कि डिवाइस अन्य संदर्भ में भी अजीब व्यवहार कर रहा है, एक कारखाना-रीसेट किया जाना चाहिए - इसलिए जितना संभव हो उतना डेटा "सहेजना" अच्छा होगा। मैं अधिकांश चीज़ों के माध्यम से बैकअप लेने में सक्षम था adb backup: कुछ अपवाद, उनमें से अधिकांश आग्नेय थे, लेकिन उपयोगकर्ता एसएमएस रखना बहुत पसंद करते हैं जो कि कवर भी नहीं थे।
इज़ी

सुनो! परेशान करने के लिए क्षमा करें क्या आपने कभी जड़ के बिना इसका समाधान किया है? BTW उत्कृष्ट एप्लिकेशन सूची, उस लिंक के लिए धन्यवाद!
ग्रुबर

1
@Gruber नहीं, फिर भी कुछ नहीं मिला। // मेरी ऐप लिस्टिंग आपको पसंद है!
इज़ी

जवाबों:


6

मैं विशेष रूप से आश्चर्य क्यों adb बैकअप इस कवर नहीं करता है।

ऐसा नहीं है कि adb backupऐप को कवर नहीं करना चाहता com.android.providers.telephony। यह ऐप इसके आधार पर किसी भी अन्य सिस्टम ऐप से बहुत अलग नहीं है AndroidManifest.xml। समस्या उस झंडे के साथ है जिसे उसके डेवलपर ने घोषणा में घोषित किया है जो किसी कारण adb backupसे डिफ़ॉल्ट तंत्र के रूप में सम्मान के लिए बाध्य है।

यह झंडा कोई और नहीं है android:allowBackup="false"। यह ADB बैकअप और पुनर्स्थापना दोनों से ऐप का विरोध करता है। Google को यहाँ कहना है:

android:allowBackup

चाहे एप्लिकेशन को बैकअप में भाग लेने और बुनियादी ढांचे को बहाल करने की अनुमति दें। यदि यह विशेषता गलत पर सेट है, तो एप्लिकेशन का कोई बैकअप या पुनर्स्थापना कभी भी प्रदर्शन नहीं किया जाएगा, यहां तक ​​कि एक पूर्ण-सिस्टम बैकअप द्वारा भी अन्यथा सभी एप्लिकेशन डेटा को adb के माध्यम से सहेजने का कारण होगा। इस विशेषता का डिफ़ॉल्ट मान सत्य है।

(जोर मेरा)

यहांAndroidManifest.xml लॉलीपॉप संस्करण के लिए इस ऐप का चेकआउट करें , या मेरे एंड्रॉइड 4.2.1 के लिए यह सबूत देखें:

IMG: कोई बैकअप ध्वज नहीं

इस ऐप में और भी बहुत कुछ है। आप सेटिंग → ऐप्स → डेटा से भी साफ़ नहीं कर सकते हैं सभी ऐप्स →<THIS_APP> चूंकि android:allowClearUserData="false"भी घोषित किया गया है, ऐसा कुछ नहीं है जिसका सामना हम हर बार करते हैं।

यदि यह "गोपनीयता कारणों" के लिए है, तो उसी को संपर्क डेटाबेस पर लागू करना चाहिए - जो स्पष्ट रूप से समर्थित है।

यह विचित्र है, ऐसा नहीं है कि आप इसे करने में सक्षम हैं, लेकिन आपका सिस्टम भी आपको ऐसा करने की अनुमति कैसे दे रहा है adb backup!

संपर्क संग्रहण को "ContactsProvider" ऐप द्वारा नियंत्रित किया जाता है जो pkg_name = द्वारा जाता है com.android.providers.contacts। ध्वज android:allowBackup="false"में AndroidManifest.xmlजेली बीन के लिए स्पष्ट रूप से उल्लेख किया गया है ( अन्य संस्करणों के लिए यहां क्लिक करें )।

क्या आप आईसीएस या जेबी के किसी पूर्ववर्ती का उपयोग कर रहे हैं?

मैंने पाया इस एप्लिकेशन आईसीएस के लिए कि झंडा के किसी भी घोषणा नहीं है कि यहाँ । आप वास्तव में इस रहस्य को साफ़ कर सकते हैं, क्योंकि मैं इस ऐप का बैकअप अपने JB 4.2.1 में ध्वज की परिभाषा के अनुसार नहीं ले सकता, और हमेशा उस 41 बाइट्स बैकअप फ़ाइल को प्राप्त करता है।


किसी भी अन्य विधि के रूप में एसएमएस / एमएमएस बैकअप लेने के लिए / रूट एक्सेस के बिना एडीबी का उपयोग करके पुनर्स्थापित करें - यहां सभी हाथ।


मुझे पता है कि यह वह झंडा है। लेकिन दोनों, वह ऐप और ADB सिस्टम का हिस्सा हैं - हम यहां 3rd-party-seller की बात नहीं कर रहे हैं। स्पष्टीकरण के लिए: जिस डिवाइस का मैं यहां उल्लेख करता हूं वह जेलीबीन (4.1.2) है। आपके संकेत के लिए धन्यवाद, मैं अपने अन्य उपकरणों (4.2 और 4.3) के साथ फिर से कोशिश करूँगा। गोपनीयता के बारे में: उपयोगकर्ता को पासवर्ड प्रदान करने के लिए एक संकेत भी हो सकता है। इसके अलावा, SharedStorage में "निजी डेटा" भी हो सकता है - साथ ही Google मानता है कि मैं अपने संपर्कों / कैलेंडर को डिफ़ॉल्ट रूप से सिंक करना चाहता हूं जब कोई Google खाता सक्षम करता है, तो मुझसे पूछने के बजाय (यदि आप उनके साथ इसे पहले ही जोड़ दें तो ऑप्ट-आउट करने का कोई तरीका नहीं है) )।
इज़ी

खतरे में यह एक शेख़ी बन जाता है: यदि यह बहुत ही निजी है - तो इसे "स्पष्ट डेटा" के साथ भी संरक्षित क्यों किया जाता है? "कभी भी मूर्खता के लिए विशेषता न करें जिसे शुद्ध मूर्खता द्वारा समझाया जा सकता है" ... // तो, यह रूट के बिना संभव नहीं है: जो केवल उचित एक्सपीडोज मॉड्यूल ("बैकअप सभी ऐप्स") को छोड़ देता है। जिसे फिर से डिवाइस पर स्थापित करने की आवश्यकता है - जिसे मैं बचना चाहता था ... बस डेटाबेस को (रूट के साथ) खींचना एक काम के आसपास होगा - लेकिन वह क्रॉस-डिवाइस को पुनर्स्थापित करने की अनुमति नहीं देता है (कोशिश की है कि एक बार, एक नहीं था अच्छा विचार है क्योंकि इसने एसएमएस को अनुपयोगी बना दिया था इसलिए मुझे रीसेट करना पड़ा)
इज़ी

1
मुझे पता है कि @ आप इस तरह के साधारण झंडे के बारे में जानते हैं, (आप पतली हवा से बाहर नहीं निकले, लेकिन शोध और अनुभव से :) लेकिन अन्य लोग ऐसे सरल प्रश्न के उत्तर देख रहे हैं, शायद इसके बारे में नहीं जानते हैं, और सभी यह जानकारी टिप्पणी के लिए उपयुक्त नहीं थी। मैं वास्तव में इस टिप्पणी को लिखने के लिए मन में था, लेकिन भूल गया कि अंत में यह उत्तर लिखते समय, क्षमा करें!
Firelord

1
// पासवर्ड के लिए, जबकि ADB एक पास-संरक्षित बैकअप प्रदान करता है, हो सकता है कि Google (IMO) ने सोचा हो कि संवेदनशील सामग्री तक पहुंच को रोकना एक बेहतर काम है जिससे एक्सेस की अनुमति न मिलने की स्थिति में डिवाइस खो जाने की स्थिति में अनधिकृत रूप से डेटा डंप हो सकता है। यदि किसी व्यक्ति को किसी भी मौके पर USB डिबगिंग सक्षम किया गया था, उसके बाद brute force attack हुए।
Firelord

1
- ओह, ठीक है, उन्होंने शुरू से ही यह सोचा था कि व्यवसाय के नाम पर स्वतंत्रता को कैसे प्रतिबंधित किया जाए, कुछ और हो सकता है। अगर मैं किसी तरह से मुठभेड़ करता हूं तो मैं कुछ अच्छा (गैर-शेख़ी) रिपोर्ट करूंगा।
Firelord
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.