अक्सर पूछे जाने वाले प्रश्नों

सामान्य अनुमतियाँ और क्रैश

यदि हम कोई अनुमतियाँ नहीं जोड़ते हैं तो क्या होगा? क्या यह दुर्घटनाग्रस्त हो जाएगा?

नहीं, ट्रैसलेट क्रैश नहीं होगा। ट्रैसलेट को अत्यधिक लचीला बनाने के लिए डिज़ाइन किया गया है। यदि आप अनिवार्य स्थान अनुमतियों की घोषणा या अनुरोध किए बिना Tracelet.start() को कॉल करने का प्रयास करते हैं, तो ट्रैसलेट सुरक्षा अपवाद को शानदार ढंग से पकड़ लेगा, कंसोल पर एक विस्तृत त्रुटि लॉग करेगा, और आपके श्रोताओं को एक विफलता घटना भेज देगा। ऐप स्वयं सामान्य रूप से चलता रहेगा. हालाँकि, अनुमति मिलने तक कोई भी स्थान रिकॉर्ड नहीं किया जाएगा।

यदि हम गति (शारीरिक गतिविधि) की अनुमति सक्षम नहीं करते हैं तो क्या होगा?

नहीं, यह क्रैश नहीं होगा। यदि ACTIVITY_RECOGNITION (Android) या Motion & Fitness (iOS) की अनुमति नहीं दी गई है, तो ट्रेसलेट स्वचालित रूप से मानक दूरी-आधारित ट्रैकिंग पर वापस आ जाएगा। हालाँकि, बैटरी ख़त्म हो जाएगी। मोशन डिटेक्शन के बिना, डिवाइस स्थिर होने पर ट्रैसलेट जीपीएस हार्डवेयर को निष्क्रिय नहीं कर सकता है। इष्टतम बैटरी जीवन सुनिश्चित करने के लिए उत्पादन ऐप्स के लिए इस अनुमति का अनुरोध करने की अत्यधिक अनुशंसा की जाती है।

आईओएस बिल्ड और सेटअप

आईओएस बिल्ड “अपरिभाषित प्रतीक” रस्ट/यूनीएफएफआई त्रुटियों के साथ विफल हो जाता है (`_ffi_tracelet_core_rustbuffer_free`, `_uniffi_tracelet_core_checksum_method_*`)

फ़्लटर के स्विफ्ट पैकेज मैनेजर एकीकरण को सक्षम करें। ट्रैसलेट का रस्ट कोर (TraceletCore.xcframework, जो tracelet_ios द्वारा उपयोग किए गए UniFFI प्रतीकों को उजागर करता है) स्विफ्ट पैकेज मैनेजर के माध्यम से जुड़ा हुआ है। लीगेसी कोकोपोड्स-ओनली पथ पर फ्रेमवर्क tracelet_ios लक्ष्य से जुड़ा नहीं है, इसलिए Xcode का लिंकर _ffi_tracelet_core_rustbuffer_free और _uniffi_tracelet_core_checksum_method_* जैसे अपरिभाषित प्रतीकों की रिपोर्ट करता है।

इसे इसके साथ ठीक करें:


flutter config --enable-swift-package-manager
flutter clean
flutter pub get
flutter run        # or: flutter build ios

टिप्पणियाँ:

फ़्लटर सीएलआई या अपने आईडीई (वीएस कोड) से बनाएं/चलाएं, जो .xcworkspace को खोलने और सीधे Xcode से बिल्डिंग करने के बजाय SPM-अवेयर बिल्ड को चलाता है।
यह एक बार की वैश्विक फ़्लटर सेटिंग है; आपको इसे प्रति प्रोजेक्ट बदलने की आवश्यकता नहीं है.
flutter clean + केवल एक ताजा pod install ही इसका समाधान नहीं करेगा - गायब टुकड़ा रस्ट फ्रेमवर्क को जोड़ने वाला एसपीएम है, न कि बासी पॉड्स।

बैटरी और मोशन सेंसर

क्या चलते समय मोशन सेंसर अधिक बैटरी खींचता है?

नहीं, यह वास्तव में बैटरी बचाता है। हार्डवेयर मोशन सेंसर (एक्सेलेरोमीटर/स्टेप डिटेक्टर) प्रति घंटे 0.1% से कम बैटरी की खपत करते हैं। जब भी फोन डेस्क पर होता है तो ट्रैसलेट अत्यधिक बिजली की खपत करने वाले जीपीएस चिप (जो प्रति घंटे 4-8% को खत्म कर देता है) को पूरी तरह से बंद करने के लिए इस अल्ट्रा-लो-पावर सेंसर का उपयोग करता है।

जब आप चलना शुरू करते हैं, तो मोशन सेंसर यात्रा को रिकॉर्ड करने के लिए तुरंत जीपीएस को सक्रिय कर देता है। समग्र परिणाम पारंपरिक ट्रैकिंग की तुलना में बैटरी जीवन के लिए बड़े पैमाने पर सकारात्मक है।

जब फ़ोन नहीं चल रहा हो तो मुझे लगातार अपडेट क्यों नहीं मिलते?

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

यदि आप अभी भी स्थिर अवस्था में आवधिक “मैं यहाँ हूँ” स्थान चाहते हैं, तो heartbeatInterval (सेकंड) सेट करें। पार्क करते समय जीपीएस का छोटा बहाव ओडोमीटर को नहीं फुलाता है - odometerAccuracyThreshold (डिफ़ॉल्ट 50 m) से भी खराब सुधारों को दूरी से बाहर रखा जाता है।

मैं बैटरी उपयोग को और भी कम कैसे करूँ?

ट्रैसलेट स्थिर होने पर पहले से ही जीपीएस को निष्क्रिय कर देता है, लेकिन आपके पास कई लीवर हैं:

बैटरी बजट - batteryBudgetPerHour को GeoConfig में सेट करें (उदाहरण के लिए 3.0 3%/घंटा के लिए)। ट्रैसलेट तब उस लक्ष्य के अंतर्गत रहने के लिए रनटाइम पर distanceFilter और desiredAccuracy को स्वतः समायोजित करता है।
वेकलॉक रिलीज़ - उपयोगकर्ता के स्थिर होने पर सीपीयू को पूरी तरह से सोने देने के लिए AndroidConfig में releaseWakelockWhenStationary: true सेट करें (MotionDetectionMode.smart की आवश्यकता है)।
दूरी फ़िल्टर - एक बड़ा distanceFilter (मीटर) चलते समय कम सुधार रिकॉर्ड करता है।
कम सटीकता - medium/low का desiredAccuracy high/best की तुलना में कम पावर लेता है।
आवधिक मोड - “मोटे तौर पर वे कहां हैं” उपयोग के मामलों के लिए, आवधिक एक-शॉट फिक्स (startPeriodic) निरंतर ट्रैकिंग की तुलना में नाटकीय रूप से सस्ते हैं।
गति की अनुमति प्रदान रखें - ACTIVITY_RECOGNITION के बिना ट्रैसलेट जीपीएस को इतनी आक्रामकता से सो नहीं सकता है।

`motionDetectionMode` विकल्पों में क्या अंतर है?

motionDetectionMode तय करता है कि जीपीएस को शुरू/बंद करने के लिए ट्रैसलेट किस प्रकार की गतिविधि का पता लगाता है:

accelerometer - हार्डवेयर मोशन सेंसर (और जहां अनुमति हो वहां गतिविधि पहचान) का उपयोग करता है। सबसे कम बिजली, घर के अंदर और जीपीएस फिक्स के बिना काम करता है।
speed - केवल जीपीएस स्पीड का उपयोग करता है। सरल और पूर्वानुमेय, लेकिन आपके रुकने का पता लगाने के लिए इसे जीपीएस फिक्स की आवश्यकता होती है, इसलिए यह धीमी गति से प्रतिक्रिया करता है और अधिक शक्ति का उपयोग करता है।
smart - दोनों को जोड़ती है: यह निरंतर ट्रैकिंग में रहता है यदि या तो एक्सेलेरोमीटर या जीपीएस गति बताती है कि आप आगे बढ़ रहे हैं, और केवल तभी स्थिर होता है जब दोनों सहमत होते हैं कि आप रुक गए हैं। झूठे बदलावों के खिलाफ सबसे मजबूत; अधिकांश ऐप्स के लिए अनुशंसित.

स्थान सेवाएँ एवं ट्रैकिंग स्थिति

यदि ट्रैकिंग सक्रिय होने पर उपयोगकर्ता स्थान सेवाएँ बंद कर दे तो क्या होगा?

संक्षिप्त उत्तर: ट्रैसलेट ट्रैकिंग को रोकता, क्रैश या नष्ट नहीं करता। यह ट्रैकिंग सत्र को सशस्त्र रखता है, एक providerchange ईवेंट उत्सर्जित करता है ताकि आपका ऐप प्रतिक्रिया दे सके, स्थान बंद होने पर कोई नया स्थान रिकॉर्ड नहीं करता है (नीचे दो प्लेटफ़ॉर्म-विशिष्ट अपवादों के साथ), और स्वचालित रूप से फिर से शुरू होता है जब उपयोगकर्ता स्थान को फिर से सक्षम करता है - हर स्थिति में (अग्रभूमि, पृष्ठभूमि, समाप्त)। आपको start() को दोबारा कॉल करने की नहीं जरूरत है।

यहां “स्थान सेवाएं बंद” का अर्थ है ओएस-स्तरीय स्थान टॉगल (एंड्रॉइड: सेटिंग्स → स्थान; आईओएस: सेटिंग्स → गोपनीयता → स्थान सेवाएं)। ऐप की अनुमति रद्द करना एक संबंधित लेकिन अलग मामला है - इस उत्तर के अंत में नोट देखें।

इसका पता कैसे लगाएं


final sub = tl.Tracelet.onProviderChange((tl.ProviderChangeEvent e) {
  if (!e.enabled) {
    // Location services were turned OFF — prompt the user / show a banner.
  } else {
    // Back ON — Tracelet has already resumed; no action required.
  }
});

ProviderChangeEvent में enabled, status (प्राधिकरण), gps, network, accuracyAuthorization, gpsFallback और mockLocationsDetected शामिल हैं। वही ईवेंट पृष्ठभूमि/मारे गए स्थिति (यदि पंजीकृत है) में हेडलेस कॉलबैक में वितरित किया जाता है और providerchange रिकॉर्ड के रूप में तब तक जारी रहता है जब तक कि आप disableProviderChangeRecord: true सेट नहीं करते।

स्थिति और मंच द्वारा व्यवहार

स्थिति	एंड्रॉइड	आईओएस
अग्रभूमि	`providerchange` (`enabled: false`) आग; अग्रभूमि सेवा जीवित रहती है; पुन: सक्षम होने तक कोई नया सुधार नहीं।	`providerchange` आग; `didFailWithError` को शालीनता से नियंत्रित किया जाता है (एक-शॉट अंतिम ज्ञात स्थान पर वापस आ जाता है); कोई नया सुधार नहीं.
पृष्ठभूमि	फ़ोरग्राउंड सेवा (और इसकी अधिसूचना) चलती रहती है; फ़्यूज़्ड अपडेट बस रुक जाते हैं; `providerchange` अभी भी भेजा गया है। पुन: सक्षम करने पर पुनरारंभ होता है.	`CLLocationManager` सदस्यता पंजीकृत रहती है; स्थान वापस आने तक iOS कुछ भी वितरित नहीं करता है, फिर फिर से शुरू होता है (और क्षेत्र/एसएलसी के माध्यम से ऐप को फिर से लॉन्च कर सकता है)।
समाप्त (मारा गया)	यदि कोई पृष्ठभूमि/बूट सत्र सक्रिय है (`stopOnTerminate: false` / `startOnBoot`), तो सेवा उपरोक्त पृष्ठभूमि की तरह व्यवहार करती है। यदि प्रक्रिया सक्रिय नहीं है, तो जब तक ओएस इसे शुरू नहीं करता तब तक कुछ भी नहीं चलता है।	iOS महत्वपूर्ण-स्थान/क्षेत्र निगरानी के माध्यम से ऐप को फिर से लॉन्च करता है केवल तभी जब कोई स्थान/क्षेत्र घटना घटती है - जो कि स्थान बंद होने पर नहीं हो सकता। एक बार पुन: सक्षम होने पर, अगला क्वालीफाइंग इवेंट पुनः लॉन्च और फिर से शुरू होता है।

सभी मामलों में सत्र स्थिति संरक्षित रहती है, इसलिए स्थान को पुन: सक्षम करने से पुन: प्रारंभ किए बिना स्वचालित रूप से ट्रैकिंग फिर से शुरू हो जाती है।

ट्रैसलेट क्या नहीं करता है

यह सत्र को स्वतः बंद नहीं करता है या आपकी कॉन्फ़िगरेशन/स्थिति को साफ़ नहीं करता है।
यह नहीं फेंकता है या दुर्घटनाग्रस्त होता है - प्लेटफ़ॉर्म “स्थान बंद/अस्वीकृत” त्रुटि पकड़ी गई है।
यह स्थानों का निर्माण नहीं करता है (नीचे एंड्रॉइड डेड रेकनिंग को छोड़कर) - आपके डीबी में उस अवधि के स्थान के लिए बस एक अंतर है जो बंद था।

प्लेटफ़ॉर्म की विशिष्टताएँ जानने योग्य हैं

एंड्रॉइड - यदि उपयोगकर्ता जीपीएस को अक्षम करता है लेकिन वाई-फाई/सेल पोजिशनिंग अभी भी चालू है, तो ट्रैसलेट स्वचालित रूप से संतुलित-पावर पोजिशनिंग पर वापस आ जाता है और gpsFallback: true के साथ providerchange उत्सर्जित करता है, जीपीएस वापस आने पर पूर्ण सटीकता बहाल करता है। वे अनुमानित सुधार रिकॉर्ड किए गए हैं और समन्वयित किए गए हैं (locationSource और उनके वास्तविक accuracy के साथ टैग किए गए हैं)। यदि enableDeadReckoning: true, जीपीएस खो जाने के बाद कॉन्फ़िगर किए गए विलंब के लिए ट्रैसलेट वास्तविक फिक्स रिटर्न तक मोशन सेंसर से स्थिति का अनुमान लगाता है। लगातार अधिसूचना पूरे समय दृश्यमान रहती है।

आईओएस - एक असफल requestLocation() हैंग होने के बजाय अंतिम ज्ञात स्थान के साथ एक-शॉट अनुरोधों का समाधान करता है। स्थान बंद होने पर iOS कोई पृष्ठभूमि या पुन: लॉन्च ईवेंट प्रदान नहीं करता है; एक बार फिर से चालू होने पर डिलीवरी और किल्ड-स्टेट पुन: लॉन्च फिर से शुरू हो जाएगा।

आपको अपने ऐप में क्या करना चाहिए

onProviderChange की सदस्यता लें और enabled == false होने पर एक बैनर/संवाद प्रदर्शित करें।
वैकल्पिक रूप से उपयोगकर्ता को Tracelet.openLocationSettings() के माध्यम से सेटिंग्स के लिए मार्गदर्शन करें।
पुनः सक्षम करने पर start() को दोबारा कॉल नहीं करें - ट्रैसलेट अपने आप फिर से शुरू हो जाता है; start() को कॉल करना हानिरहित लेकिन अनावश्यक है।

ऐप की अनुमति को रद्द करना बनाम टॉगल को बंद करना

टॉगल को बंद करने से सभी ऐप्स प्रभावित होते हैं और ऊपर बताए अनुसार इसे पूरी तरह से पुनर्प्राप्त किया जा सकता है। ऐप की स्थान अनुमति को रद्द करना (या “हमेशा” → “उपयोग में होने पर”) को status / accuracyAuthorization फ़ील्ड के माध्यम से उसी providerchange ईवेंट के माध्यम से रिपोर्ट किया जाता है। एंड्रॉइड 12+ पर, यदि बैकग्राउंड-लोकेशन अनुमति खो जाती है, तो बूट/बैकग्राउंड रीस्टार्ट को जानबूझकर छोड़ दिया जाता है (यह अन्यथा चुपचाप विफल हो जाएगा) - अनुमति दोबारा दें और फिर से शुरू करने के लिए पुनः आरंभ करें।

स्थान कितने सटीक हैं, और मैं वाई-फाई/सेल फिक्स से जीपीएस कैसे बताऊं?

प्रत्येक Location में मीटरों में एक वास्तविक coords.accuracy और एक locationSource टैग होता है: "gps" (≤50 मीटर), "wifi" (≤200 मीटर), "cell" (बदतर), या "network" (जीपीएस फ़ॉलबैक के दौरान)। ट्रेसलेट कम-सटीकता सुधारों को चुपचाप नहीं छोड़ता है - यह उन्हें रिकॉर्ड करता है ताकि आपका निशान निरंतर बना रहे - लेकिन यह खराब सुधारों को ओडोमीटर (odometerAccuracyThreshold, डिफ़ॉल्ट 50 m) से दूर रखता है और असंभव-गति छलांग (maxImpliedSpeed) को अस्वीकार कर देता है।

यदि आप केवल जीपीएस-गुणवत्ता वाला डेटा चाहते हैं, तो अपनी ओर से locationSource == "gps" या accuracy <= 50 द्वारा फ़िल्टर करें। यदि उपयोगकर्ता ने केवल अनुमानित/मोटा स्थान (या iOS “सटीक: बंद”) दिया है, तो प्रत्येक फिक्स OS नीति के अनुसार अनुमानित है - accuracyAuthorization / reducedAccuracy की जांच करें।

`getCurrentPosition()` कुछ फोन पर `LOCATION_FAILURE` के साथ विफल क्यों होता है लेकिन अन्य पर काम करता है?

PlatformException(LOCATION_FAILURE, "Failed to obtain location") का मतलब है कि एक-शॉट अनुरोध timeout के भीतर एक नया समाधान प्राप्त नहीं कर सका और उसके पास वापस आने के लिए कोई कैश्ड स्थान नहीं था। यह आपके कोड में कोई बग नहीं है - यह डिवाइस का जीपीएस/फ्यूज्ड स्टैक है जो समय पर समाधान देने में विफल रहा है। एक उच्च-सटीकता वाला वन-शॉट ताज़ा समाधान मांगता है, और क्या वह (उदाहरण के लिए) 30 सेकंड के भीतर सफल होता है, यह डिवाइस और वातावरण पर बहुत अधिक निर्भर करता है:

“Google स्थान सटीकता” बंद है - सेटिंग्स → स्थान → स्थान सेवाएँ → Google स्थान सटीकता (वाई-फ़ाई/ब्लूटूथ स्कैनिंग)। चालू होने पर, फ़्यूज़्ड प्रदाता लगभग तुरंत ही घर के अंदर वाई-फाई/सेल फिक्स लौटा देता है; बंद होने पर, फोन को एक कच्चे जीपीएस फिक्स के लिए इंतजार करना होगा जो घर के अंदर कभी नहीं आता है। यह “मेरे फ़ोन पर काम करता है, उनके नहीं” का #1 कारण है।
घर के अंदर / भूमिगत / कोई आकाश दृश्य नहीं - एक ठंडे जीपीएस फिक्स के लिए आकाश दृश्यता की आवश्यकता होती है, और बजट चिपसेट एक ठंडे पहले फिक्स (टीटीएफएफ) के लिए 30 एस से अधिक हो सकते हैं, जबकि फ्लैगशिप को सेकंड में सहायक-जीपीएस फिक्स मिलते हैं।
जीपीएस प्रदाता ओएस स्तर पर अक्षम (केवल-नेटवर्क स्थान) - एक शुद्ध उच्च-सटीकता अनुरोध में लॉक करने के लिए कुछ भी नहीं है।
Google Play सेवाएँ अनुपलब्ध/पुरानी (कुछ Huawei/AOSP निर्मित) - फ़्यूज़्ड क्लाइंट नहीं चल सकता।
नमूना गणना - samples: 3 के साथ ट्रैसलेट को तीन सुधार एकत्र करने होंगे; मार्जिनल सिग्नल में इसे एक मिल सकता है और बाकी से पहले टाइम आउट हो सकता है। samples: 1 घर के अंदर अधिक क्षमाशील है।

इसे विश्वसनीय कैसे बनाएं - अंतिम ज्ञात स्थान पर वापस जाएँ:


Future<tl.Location?> bestPosition() async {
  try {
    return await tl.Tracelet.getCurrentPosition(
      desiredAccuracy: tl.DesiredAccuracy.high,
      timeout: 60,        // cold GPS fixes on budget phones can exceed 30 s
      samples: 1,         // more forgiving indoors than 3
      maximumAge: 30000,  // accept a <30 s-old cached fix instantly
    );
  } on PlatformException catch (e) {
    if (e.code == 'LOCATION_FAILURE') {
      // Weak/indoor signal — fall back to the cached fix before giving up.
      return await tl.Tracelet.getLastKnownLocation();
    }
    rethrow;
  }
}

maximumAge जीपीएस को सक्रिय किए बिना तुरंत हालिया कैश्ड फिक्स लौटाता है - उपस्थिति/चेक-इन के लिए आदर्श जहां 30 सेकंड पुरानी स्थिति ठीक है।
getLastKnownLocation() कभी भी किसी प्रदाता को सक्रिय नहीं करता है और फ़्यूज्ड कैश में जो कुछ भी है उसे लौटाता है, इसलिए आप केवल “कमजोर सिग्नल” संदेश दिखाते हैं जब वास्तव में कुछ भी उपलब्ध नहीं होता है।
लॉन्च के बाद पहले सुधार के लिए timeout को उदार (45-60 सेकंड) रखें, और यदि इनडोर सुधार विफल होते रहते हैं, तो उपयोगकर्ताओं को Google स्थान सटीकता को सक्षम करने के लिए प्रेरित करें (getProviderState() / getHealth() के माध्यम से प्रदाता स्थिति का पता लगाएं)।

पृष्ठभूमि एवं समाप्ति

क्या ऐप बंद होने या स्वाइप हो जाने के बाद भी ट्रैसलेट ट्रैकिंग करता रहता है?

एंड्रॉइड - हाँ, stopOnTerminate: false के साथ। जब उपयोगकर्ता हाल ही में ऐप को स्वाइप करता है, तो ट्रैसलेट एक मूल पृष्ठभूमि सेवा पर नज़र रखता है जिसके लिए फ़्लटर इंजन की आवश्यकता नहीं होती है, इसलिए स्थान कैप्चर और सिंक जारी रहता है। लगातार अग्रभूमि-सेवा अधिसूचना ही उस सेवा को जीवित रखती है। stopOnTerminate: true के साथ, ट्रैकिंग उम्मीद के मुताबिक स्वाइप-अवे पर रुक जाती है।

आईओएस - यह इस बात पर निर्भर करता है कि ऐप कैसे बंद किया गया था। यदि आईओएस मेमोरी/सिस्टम कारणों से ऐप को समाप्त कर देता है, तो यह इसे अगले महत्वपूर्ण-स्थान-परिवर्तन पर पृष्ठभूमि में पुन: लॉन्च करता है और फिर से शुरू करता है। यदि उपयोगकर्ता ऐप को बलपूर्वक छोड़ देता है (ऐप स्विचर में ऊपर की ओर स्वाइप करें), तो iOS जानबूझकर अपनी सभी स्थान सेवाओं को तब तक निलंबित कर देता है जब तक कि ऐप फिर से न खुल जाए - Apple किसी भी SDK को इसे ओवरराइड नहीं करने देता है।

ऑफ़लाइन और सिंक

यदि डिवाइस में इंटरनेट नहीं है तो मेरे स्थानों का क्या होगा?

कुछ भी नहीं खोया है। प्रत्येक फिक्स ऑन-डिवाइस डेटाबेस (encryptDatabase: true पर एन्क्रिप्टेड) पर लिखा जाता है, जैसे ही इसे कैप्चर किया जाता है - नेटवर्क से स्वतंत्र। कनेक्टिविटी वापस आने पर ऑटो-सिंक उन्हें अपलोड करता है, एक्सपोनेंशियल बैकऑफ़ (maxRetries, retryBackoffBase, retryBackoffCap) के साथ पुनः प्रयास करता है। किसी बैच को डेटाबेस से केवल तभी हटाया जाता है जब सर्वर रसीद की पुष्टि करता है**, इसलिए असफल या बाधित अपलोड को बस पुनः प्रयास किया जाता है, कभी नहीं छोड़ा जाता है।

स्थान आपकी अवधारण सीमा के भीतर बफर होते हैं (maxDaysToPersist, maxRecordsToPersist); जब इनकी संख्या अधिक हो जाती है तो सबसे पुराने को काट दिया जाता है। आप disableAutoSyncOnCellular: true के साथ अपलोड को सेल्यूलर से भी रोक सकते हैं।

क्या इंटरनेट वापस आने पर ट्रेसलेट_सिंक स्वचालित रूप से मेरे बैकएंड पर चला जाएगा?

हां, स्वचालित रूप से और पूरी तरह से पृष्ठभूमि में। यदि आप tracelet_sync (या tracelet_supabase / tracelet_firebase जैसे इसके रैपर) का उपयोग करते हैं, तो आपको स्वयं कोई नेटवर्क-पुनः प्रयास तर्क लिखने की आवश्यकता नहीं है।

जब ओएस पता लगाता है कि नेटवर्क कनेक्टिविटी बहाल हो गई है, तो मूल सिंक इंजन तुरंत पृष्ठभूमि में जाग जाता है और कैश्ड स्थानों को कालानुक्रमिक बैचों में आपके बैकएंड पर अपलोड करना शुरू कर देता है। यह तब तक अपलोड करना जारी रखता है जब तक कि स्थानीय डेटाबेस पूरी तरह से सर्वर से जुड़ न जाए, जिससे लंबे समय तक ऑफ़लाइन रहने के बाद भी शून्य डेटा हानि सुनिश्चित होती है।

रिबूट और डिवाइस अनलॉक

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

नहीं - ट्रैसलेट के फिर से शुरू होने से पहले रिबूट के बाद डिवाइस को कम से कम एक बार अनलॉक किया जाना चाहिए। यह एक एंड्रॉइड प्लेटफ़ॉर्म नियम (डायरेक्ट बूट / फ़ाइल-आधारित एन्क्रिप्शन) है, ट्रैसलेट सीमा नहीं है, और यह प्रत्येक स्थान एसडीके पर लागू होता है।

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

रिबूट के बाद का क्रम इस प्रकार है:

डिवाइस बूट → ट्रेसलेट निष्क्रिय है।
उपयोगकर्ता एक बार अनलॉक करता है → BOOT_COMPLETED सक्रिय हो जाता है → ट्रैसलेट ट्रैकिंग और सिंक फिर से शुरू कर देता है।

केवल पहला अनलॉक मायने रखता है। उसके बाद स्क्रीन को फिर से लॉक किया जा सकता है (फोन जेब में, स्क्रीन बंद) और ट्रैकिंग/सिंक सामान्य रूप से जारी रहेगा।

बूट बायोडाटा के लिए आवश्यकताएँ: startOnBoot: true, stopOnTerminate: false, और पृष्ठभूमि-स्थान (“हमेशा”) की अनुमति दी गई। एंड्रॉइड 14+ पर ओएस अतिरिक्त रूप से बूट से लोकेशन फोरग्राउंड सेवा शुरू करने से मना करता है, इसलिए ऐप अगली बार खुलने तक ट्रैसलेट वर्कमैनेजर/अलार्म ट्रैकिंग (कोई लगातार अधिसूचना नहीं) पर वापस आ जाता है।

आईओएस रिबूट पर बिल्कुल भी ऑटो-स्टार्ट नहीं हो सकता है - ऐप्स बूट पर नहीं चल सकते हैं और तब तक अनलॉन्च नहीं रह सकते हैं जब तक कि उपयोगकर्ता ऐप को नहीं खोलता है या कोई महत्वपूर्ण-स्थान-परिवर्तन इसे फिर से लॉन्च नहीं करता है, जो स्वयं पहले पोस्ट-रिबूट अनलॉक के बाद ही होता है।

क्या यह पहले अनलॉक से पहले ट्रैक कर सकता है?

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

जियोफ़ेंसिंग

जब मैं मॉक/सिम्युलेटेड स्थानों के साथ परीक्षण करता हूं तो जियोफ़ेंस ट्रांज़िशन चालू नहीं होता है (यह 1.x में काम करता है)

नकली स्थान अभी भी काम करते हैं - लेकिन उच्च सटीकता वाले जियोफेंस मोड में आपके नकली फिक्स को जियोफेंस के मूल्यांकन से पहले फ़िल्टर किया जा रहा है। geofenceModeHighAccuracy: true के साथ, निरंतर-जीपीएस स्ट्रीम से इन-ऐप बदलाव की गणना की जाती है, और मूल्यांकनकर्ता केवल उन फिक्स पर चलता है जो स्थान फ़िल्टर को पास करते हैं। रूट-सिमुलेशन उपकरण आमतौर पर बिंदुओं के बीच “टेलीपोर्ट” करते हैं, और उन छलांगों को अस्वीकार कर दिया जाता है:

maxImpliedSpeed - दो दूर-दूर के नमूनों के बीच की अकल्पनीय गति को बाहरी माना जाता है और हटा दिया जाता है।
useKalmanFilter: true - सहज झगड़े अचानक, गैर-भौतिक मॉक जंप।
trackingAccuracyThreshold - कुछ नकली प्रदाता accuracy = 0 या एक अवास्तविक मान की रिपोर्ट करते हैं जो सीमा में विफल रहता है।

आपके वर्तमान स्थान पर रखा गया जियोफेंस अभी भी चालू रहता है क्योंकि geofenceInitialTriggerEntry: true पंजीकरण पर ENTER उत्सर्जित करता है (कोई हलचल आवश्यक नहीं) - इसलिए यह कभी भी फ़िल्टर से नहीं गुजरता है।

उच्च-सटीकता मोड में नकली परीक्षण के लिए, फ़िल्टर को शिथिल करें:


filter: tl.LocationFilter(
  rejectMockLocations: false,
  useKalmanFilter: false,        // disable smoothing
  maxImpliedSpeed: 0,            // 0 disables the implied-speed reject
  trackingAccuracyThreshold: 0,  // accept regardless of reported accuracy
),
geo: tl.GeoConfig(distanceFilter: 0, disableElasticity: true),

डेवलपर विकल्प → मॉक लोकेशन ऐप के तहत अपना मॉक ऐप भी चुनें, और छोटे, यथार्थवादी चरणों में सिम्युलेटेड रूट को आगे बढ़ाएं।

सबसे सरल रास्ता मानक जियोफेंसिंग मोड (geofenceModeHighAccuracy: false) में परीक्षण करना है, जो ओएस जियोफेंसिंग सेवा को सौंपता है। ओएस फ़्यूज्ड प्रदाता के विरुद्ध मूल्यांकन करता है और सिस्टम मॉक-लोकेशन ऐप का सम्मान करता है बिना एसडीके फिल्टर के - वहां ≥ ~100 मीटर के दायरे का उपयोग करें, क्योंकि ओएस एक व्यावहारिक न्यूनतम लागू करता है और उसके नीचे छोटे/EXIT संक्रमण अविश्वसनीय हैं।

debug: true और logLevel: verbose के साथ, Location filtered by Rust processor: <reason> के लिए लॉग देखें - यह आपको बताता है कि किस फ़िल्टर ने प्रत्येक नकली फिक्स को हटा दिया।

डेटा सुरक्षा एवं गोपनीयता

क्या मेरा स्थान डेटा बाकी समय एन्क्रिप्टेड है?

वैकल्पिक रूप से, हाँ. स्थानों को बफ़र करने वाले स्थानीय SQLite डेटाबेस को एन्क्रिप्ट करने के लिए encryptDatabase: true सेट करें। एंड्रॉइड पर यह SQLCipher (AES-256) का उपयोग करता है और आपको अपने ऐप में SQLCipher निर्भरता जोड़ने की आवश्यकता होती है - इसे वैकल्पिक रखा गया है ताकि डिफ़ॉल्ट बिल्ड छोटा रहे, और इसके बिना encryptDatabase को कॉल करने से एक स्पष्ट त्रुटि उत्पन्न होती है। iOS पर एन्क्रिप्टेड स्टोर को मूल रूप से प्रबंधित किया जाता है।

गोपनीयता के बजाय छेड़छाड़-साक्ष्य के लिए, ऑडिट ट्रेल (audit.enabled) प्रत्येक रिकॉर्ड (जैसे SHA-256) को हैश-चेन करता है ताकि आप यह साबित कर सकें कि तथ्य के बाद इतिहास में कोई बदलाव नहीं किया गया था। गोपनीयता क्षेत्र आपको संवेदनशील क्षेत्रों (जैसे उपयोगकर्ता का घर) के अंदर सुधारों को दबाने या संशोधित करने देता है।

क्या ट्रैसलेट नकली/नकली जीपीएस स्थानों का पता लगाता है?

हाँ, mockDetectionLevel के माध्यम से LocationFilter पर:

disabled (डिफ़ॉल्ट) - सभी स्थान बिना शर्त स्वीकार किए जाते हैं।
basic - प्लेटफ़ॉर्म के “नकली है” ध्वज पर भरोसा करता है।
heuristic - फ़्लैग को छिपाने वाले स्पूफ़र्स को पकड़ने के लिए प्लेटफ़ॉर्म ध्वज प्लस देशी अनुमान और एक डार्ट-साइड टाइमस्टैम्प जांच।

heuristic पर, प्रत्येक Location को इस बात के साथ एनोटेट किया जाता है कि इसे असली या नकली क्यों आंका गया, ताकि आप अपने तर्क में नकली सुधारों को स्वीकार, ध्वजांकित या अस्वीकार कर सकें।

फ़्लटर_बैकग्राउंड_जियोलोकेशन से माइग्रेट किया जा रहा है

मैं `flutter_background_geolocation` से आ रहा हूं - स्विच कितना कठिन है?

ट्रेसलेट का एपीआई जानबूझकर flutter_background_geolocation के करीब है, इसलिए अधिकांश ऐप्स न्यूनतम परिवर्तनों के साथ मैप होते हैं - ready/start/stop, स्थान/गति/प्रदाता ईवेंट, और HTTP सिंक सभी में प्रत्यक्ष समकक्ष होते हैं। कॉन्फिगरेशन/इवेंट मैपिंग टेबल के लिए पूरी माइग्रेशन गाइड और कुछ व्यवहार संबंधी अंतर देखें।