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

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

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

नहीं, ट्रैसलेट क्रैश नहीं होगा। ट्रैसलेट को अत्यधिक लचीला बनाने के लिए डिज़ाइन किया गया है। यदि आप अनिवार्य स्थान अनुमतियों की घोषणा या अनुरोध किए बिना 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 सेट नहीं करते।

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

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

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

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

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

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

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

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

1. onProviderChange की सदस्यता लें और enabled == false होने पर एक बैनर/संवाद प्रदर्शित करें।
2. वैकल्पिक रूप से उपयोगकर्ता को Tracelet.openLocationSettings() के माध्यम से सेटिंग्स के लिए मार्गदर्शन करें।
3. पुनः सक्षम करने पर 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 की जांच करें।

चलते समय मेरा ट्रैक बाएँ और दाएँ उछलता है और दूरी स्ट्रावा से 2-3 गुना अधिक है। मैं इसे कैसे ठीक करूं?

जीपीएस शोर को वास्तविक गति के रूप में दर्ज किया जा रहा है। चलने की गति (~1.4 मीटर/सेकेंड) पर एक हैंडसेट की क्षैतिज त्रुटि खुले आसमान के नीचे 5-8 मीटर है और पेड़ों की आड़ में या इमारतों के बीच काफी बदतर है - उपयोगकर्ता वास्तव में दो फिक्स के बीच कितनी दूर चला गया इसका एक बड़ा हिस्सा। किनारे पर प्रत्येक घबराहट “स्पाइक” एक वास्तविक समन्वय परिवर्तन है, और एक ओडोमीटर जो हर फिक्स पर भरोसा करता है वह सब कुछ जोड़ता है। फिटनेस ऐप्स अधिक सहज दिखते हैं क्योंकि वे विशेष रूप से ऑन-फ़ुट केस के लिए ट्यून होते हैं; एसडीके डिफ़ॉल्ट वाहनों, साइकिल चालकों और पैदल चलने वालों के बीच जानबूझकर तटस्थ हैं।

सबसे पहले, 3.8.0-beta या बाद में अपग्रेड करें। 3.7.6 पर या उसके नीचे दो दोषों ने बिल्कुल यही लक्षण उत्पन्न किया और इसे ठीक नहीं किया जा सका:

• useKalmanFilter: true ने केवल रेंडर किए गए ट्रैक को सुचारू किया। लोकेशन प्रोसेसर के बाद में स्मूथिंग चली और केवल coords फीड किया गया, इसलिए ओडोमीटर रॉ जिटर को एकीकृत करता रहा - नक्शा साफ दिखता था जबकि दूरी गलत रही। यह अब फिल्टर से पहले चलता है, इसलिए दूरी, सटीकता/अंतर्निहित-स्पीड गेट और ओडोमीटर सभी डी-नॉइज़्ड ट्रैक देखते हैं। उम्मीद करें कि अपग्रेड करने के बाद आपकी रिकॉर्ड की गई दूरियां कम हो जाएंगी; वह बूंद वह शोर है जिसे आप पहले गिन रहे थे।
• odometerAccuracyThreshold के लिए बहुत मोटे फिक्स को सही ढंग से ओडोमीटर से बाहर रखा गया था, लेकिन ओडोमीटर का संदर्भ बिंदु वैसे भी आगे बढ़ गया था - इसलिए उस सेगमेंट के दौरान कवर की गई जमीन स्थायी रूप से खो गई थी। गेट को कसने से दूरी ठीक होने के बजाय गायब हो गई। एक मोटा फिक्स अब अपनी दूरी को स्थगित कर देता है, और अगला भरोसेमंद फिक्स पूरी अवधि तय कर देता है।

फिर सीमा का अनुमान लगाना बंद करें - ऑन-डिवाइस क्लासिफायरियर को उन्हें चुनने दें:

await tl.Tracelet.ready(tl.Config(
  geo: tl.GeoConfig(
    filter: tl.LocationFilter(useKalmanFilter: true),
  ),
  classifier: tl.ClassifierConfig(
    enableFusedClassifier: true,      // required — the classifier must be running
    autoTuneFromTransportMode: true,
  ),
));

क्लासिफायर still / walking / running / cycling / vehicle को अलग करने के लिए एक्सेलेरोमीटर ताल को जीपीएस स्पीड के साथ फ़्यूज़ करता है, और जब कोई मोड कमिट करता है तो यह अपने अनुकूल मानों के लिए distanceFilter, trackingAccuracyThreshold, odometerAccuracyThreshold और maxImpliedSpeed को स्वैप करता है। गारंटी के लिए परिवहन मोड द्वारा ऑटो-ट्यूनिंग देखें (केवल प्रतिबद्ध परिवर्तन, थ्रेसहोल्ड को जगह में बदल दिया गया है ताकि ओडोमीटर निरंतर बना रहे, unknown आपके स्वयं के मूल्यों को पुनर्स्थापित करता है)।

debug: true और logLevel: verbose के साथ आप लॉग में प्रत्येक रीट्यून देखेंगे:

auto-tune: 'walking' → distanceFilter=8.0m trackingAccuracy=15m odometerAccuracy=10m maxImpliedSpeed=4m/s

क्या चलने, जॉगिंग और दौड़ने के लिए अनुशंसित प्रीसेट हैं?

ये सटीक मान हैं जो ऑटो-ट्यूनिंग लागू होते हैं, इसलिए यदि आपका ऐप केवल एक गतिविधि (एक रन-ट्रैकर, एक डिलीवरी-ऑन-फ़ुट ऐप) को ट्रैक करता है और आप क्लासिफायर नहीं चलाना चाहते हैं तो आप उन्हें हाथ से सेट कर सकते हैं:

जॉगिंग एक अलग प्रीसेट नहीं है। यह रनिंग बैंड (6-20 किमी/घंटा) के अंदर बैठता है और इसकी सीमाएँ साझा करता है - रनिंग से अलग एक “जॉगिंग प्रीसेट” का आविष्कार सटीकता से किया जाएगा, माप से नहीं।

स्मूथिंग ऑन के साथ एक केवल चलने वाला ऐप:

geo: tl.GeoConfig(
  distanceFilter: 8,
  filter: tl.LocationFilter(
    useKalmanFilter: true,
    trackingAccuracyThreshold: 15,
    odometerAccuracyThreshold: 10,
    maxImpliedSpeed: 4,
  ),
),

यदि आप पहले से ही हैंड-ट्यून कर चुके हैं और अभी भी ~50% लंबे हैं, तो इन तीन चीजों की जांच करें:

• जीपीएस शोर तल के नीचे एक distanceFilter शोर को दूरी के रूप में स्वीकार करता है। distanceFilter: 5 पर, एक स्थिर 6 मीटर की त्रुटि 6 मीटर चलने के रूप में पढ़ी जाती है। इसे ~8 मीटर पैदल या उससे ऊपर रखें - सहज ज्ञान के विपरीत, कम अंक रिकॉर्ड करने से अधिक सटीक कुल मिलता है।
• एक सख्त trackingAccuracyThreshold ओडोमीटर गेट को अप्रासंगिक बना देता है। trackingAccuracyThreshold: 10 के साथ, जो भी फिक्स बचता है वह पहले से ही ≤ 10 मीटर है, इसलिए odometerAccuracyThreshold (डिफ़ॉल्ट 50 m) कभी भी कुछ भी अस्वीकार नहीं करता है। जिस गेट पर आप भरोसा कर रहे थे वह कुछ नहीं कर रहा है; त्रुटि आपके द्वारा किए गए सुधारों से आ रही है, न कि आपके द्वारा छोड़े गए सुधारों से।
• useKalmanFilter डिफ़ॉल्ट रूप से बंद है, और 3.8.0 से पहले यह चालू होने पर भी दूरी को बिल्कुल भी प्रभावित नहीं करता था।

किसी अन्य ऐप के साथ सटीक मिलान की उम्मीद न करें। स्ट्रावा, गूगल फिट और ट्रैसलेट अलग-अलग फिक्स स्ट्रीम (सैंपलिंग ताल, प्रदाता सेटिंग्स, चाहे ऐप अग्रभूमि में था) का उपभोग करते हैं और अलग-अलग स्मूथिंग लागू करते हैं। ज्ञात-लंबाई मार्ग पर कुछ प्रतिशत के भीतर समझौता यथार्थवादी लक्ष्य है - उस मार्ग के विरुद्ध मापें जिसे आप सत्यापित कर सकते हैं, किसी अन्य ऐप के नंबर के विरुद्ध नहीं।

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

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

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

मैंने showNotificationOnPauseOnly: true सेट किया है लेकिन अधिसूचना हमेशा दिखाई देती है। क्यों?

क्योंकि stopOnTerminate false है, और दोनों सेटिंग्स का सम्मान नहीं किया जा सकता है।

अधिसूचना को छिपाने का अर्थ है अग्रभूमि सेवा को पदावनत करना - एंड्रॉइड में अधिसूचना के बिना कोई अग्रभूमि सेवा नहीं है - और जब उपयोगकर्ता हाल ही में ऐप को स्वाइप करता है तो कोई अग्रभूमि सेवा नहीं रखने वाली प्रक्रिया को एंड्रॉइड समाप्त कर देता है। इसलिए जब अधिसूचना छिपी हुई थी, stopOnTerminate: false ने कुछ भी गारंटी नहीं दी: अंतराल के अंदर एक स्वाइप समय (पिक्सेल फोल्ड पर 285 एमएस, एंड्रॉइड 15 डिवाइस पर 700-1500 एमएस मापा गया) ने प्रक्रिया को पूरी तरह से समाप्त कर दिया, बिना किसी हेडलेस कार्य, कोई ईवेंट और कोई लॉग नहीं। कार्य-हटाने के समय SDK द्वारा किया जाने वाला कोई भी काम इसे रोक नहीं सकता है - एंड्रॉइड ने पहले ही चुन लिया है कि आपके ऐप को यह बताने से पहले कि कार्य को हटा दिया गया है, किन प्रक्रियाओं को समाप्त करना है।

ट्रेसलेट इसे अस्तित्व के वादे के पक्ष में हल करता है: stopOnTerminate: false के साथ ध्वज को नजरअंदाज कर दिया जाता है और अधिसूचना जारी रहती है। यह जीवनचक्र चैनल पर start() के अनुसार एक बार कारण लॉग करता है, इसलिए Tracelet.getLogs() इसे दिखाएगा।

यदि आप छिपी हुई अधिसूचना चाहते हैं और ऐप के स्वाइप होने पर ट्रैकिंग समाप्त होने से खुश हैं तो stopOnTerminate: true सेट करें। पूर्ण व्याख्या 📖

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

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

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

स्थान आपकी अवधारण सीमा के भीतर बफर होते हैं (maxDaysToPersist, डिफ़ॉल्ट रूप से 3 दिन, और maxRecordsToPersist, डिफ़ॉल्ट रूप से असीमित); जब इनकी संख्या अधिक हो जाती है तो सबसे पुराने को काट दिया जाता है। उस सीमा को बंद करने के लिए या तो -1 पर सेट करें - यदि आप डिफ़ॉल्ट विंडो से अधिक समय तक ऑफ़लाइन विस्तार की उम्मीद करते हैं तो जानबूझकर ऐसा करना उचित है, क्योंकि रिटेंशन द्वारा गिराया गया रिकॉर्ड कभी अपलोड नहीं किया गया था। 3.8.3 से पहले कोई भी सीमा वास्तव में लागू नहीं की गई थी, इसलिए कतार बिना किसी सीमा के बढ़ती गई। आप disableAutoSyncOnCellular: true के साथ अपलोड को सेल्यूलर से भी रोक सकते हैं।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

मुझे एक ही जियोफेंस के लिए बार-बार ENTER/EXIT क्यों दिखाई देता है, खासकर आक्रामक-ओईएम एंड्रॉइड फोन (Xiaomi, Vivo, OPPO…) पर?

ट्रैसलेट में पहले से ही एक बायोडाटा-सुरक्षित “अंदर से ज्ञात” स्थिति बनी रहती है जो प्रक्रिया मृत्यु से बच जाती है, इसलिए एक ओईएम आपके ऐप को खत्म करने और फिर से लॉन्च करने से उस डिवाइस के लिए ENTER को फिर से सक्रिय नहीं करता है, जिसने कभी ज़ोन नहीं छोड़ा।

सामान्य कारण यह है कि होस्ट ऐप किसी ज़ोन को “रीफ्रेश” करने के लिए प्रत्येक लॉन्च पर addGeofence() से तुरंत पहले removeGeofences() को कॉल करता है:

// Don't do this on every app start:
await tl.Tracelet.removeGeofences();
await tl.Tracelet.addGeofence(tl.Geofence(identifier: 'OFFICE', latitude: lat, longitude: lng, radius: radius));

removeGeofences() जानबूझकर उस अंदरूनी स्थिति को साफ़ करता है - ऐसा करना ही होगा, क्योंकि बाड़ वास्तव में चली गई है। चूंकि addGeofence() पहले से ही पहचानकर्ता द्वारा सम्मिलित है, इसलिए इसे नए निर्देशांक के साथ फिर से कॉल करने से मौजूदा बाड़ अपनी जगह पर अपडेट हो जाती है:

// Do this instead — updates OFFICE if it exists, creates it if not:
await tl.Tracelet.addGeofence(tl.Geofence(identifier: 'OFFICE', latitude: lat, longitude: lng, radius: radius));

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

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

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

वैकल्पिक रूप से, हाँ. स्थानों को बफ़र करने वाले स्थानीय 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 सिंक सभी में प्रत्यक्ष समकक्ष होते हैं। कॉन्फिगरेशन/इवेंट मैपिंग टेबल के लिए पूरी माइग्रेशन गाइड  और कुछ व्यवहार संबंधी अंतर देखें।