رصد المنطقة الزمنية للاتصالات الهاتفية

بالنسبة إلى الأجهزة التي تعمل بنظام التشغيل Android 11 أو الإصدارات الأقدم، يمكن استخدام ميزة "الرصد التلقائي للمنطقة الزمنية" في يعتمد AOSP على إشارات من النظام الفرعي للاتصالات الهاتفية. بسبب التبعية في النظام الفرعي للاتصال الهاتفي، وميزة "الرصد التلقائي للمنطقة الزمنية" على Android 11 أو الإصدارات الأقدم على الأجهزة الهاتفية.

عند توفّر ميزة تحديد المنطقة الزمنية للاتصال الهاتفي، تعمل هذه الميزة باستخدام رمز بلد الجهاز الجوّال (مركز عملائي) أو هوية الشبكة والمنطقة الزمنية (NITZ) بشكل أفضل.

على سبيل المثال، يمكن لجهاز في فرنسا تحديد المنطقة الزمنية استنادًا إلى تم إعداد تقارير "مركز عملائي" عن طريق الأبراج الخلوية القريبة. هذا ممكن لأن فرنسا معروفة تستخدم منطقة زمنية واحدة.

عندما يستخدم البلد عدة مناطق زمنية، لا يكون حساب "مركز عملائي" وحده كافيًا لتحديد المنطقة الزمنية. بالنسبة إلى هذه البلدان، يستخدم الجهاز أيضًا إشارات NITZ لتنفيذ ما يلي: لتحديد المنطقة الزمنية الصحيحة. هذه الميزة فعّالة في العديد من الأماكن حول العالم ولكنه يتطلب أن تكون إشارات NITZ متاحة وصحيحة، وبالتالي تعتمد على شركات النقل

إنّ ميزة "رصد المنطقة الزمنية للاتصالات الهاتفية" هي أداة رصد سلبية. يعمل في جميع الأوقات لذا غالبًا ما يتم تقديم اقتراحات هاتفية حتى عندما تكون الأنشطة خوارزمية time_zone_detector لا تعد اتصالاً هاتفيًا في الوقت الحالي.

تقييد رصد المنطقة الزمنية للاتصال الهاتفي

حتى مع توفُّر إشارات NITZ الصحيحة، لا تتوفّر ميزة رصد المنطقة الزمنية الهاتفية تعمل دائمًا بشكل جيد في كل بلد. وذلك لأن NITZ تحتوي فقط على إزاحة فهي لا تكفي دائمًا لتحديد المنطقة الزمنية.

هناك العديد من الأماكن في العالم التي قد تحدث فيها مشكلة المنطقة الزمنية هذه. فعلى سبيل المثال، لا يمكن لمدينتي دنفر كولورادو وفينكس أريزونا في الولايات المتحدة باستخدام إشارات NITZ خلال الشتاء، ولكن يمكن أن تحدث خلال مواسم أخرى. وقد يواجه أي موقع به مناطق زمنية متداخلة بالمثل هذا النوع من المشكلة.

يُفصّل الجدول التالي سلوك الجهاز حسب الموسم لمدينة دنفر وفينيكس كمثال:

توضح الأمثلة أعلاه أنه خلال فصل الشتاء، يمكن لأجهزة Android في دنفر أو يجب أن تختار أريزونا أحد معرّفي المنطقة الزمنية المطابقين، حيث قد يكونان غير صحيحين بالنسبة إلى بعض الأجهزة ولكن مع استمرار عرض التوقيت المحلي الصحيح على ما يبدو. الجهاز الساعة والتقويمات والتطبيقات الأخرى تعرض التوقيت المحلي المتوقع حتى إذا رقم تعريف المنطقة الزمنية غير صحيح لأنّ رقم تعريف المنطقة الزمنية يحتسبان القيمة المحلية نفسها. الوقت خلال فصل الشتاء.

ومع ذلك، في الربيع عندما يلتزم دنفر بالتوقيت الصيفي ومن لا، قد تعرض بعض الأجهزة مؤقتًا التوقيت المحلي غير الصحيح إذا تم ضبطها معرّف منطقة زمنية غير صحيح لموقع المستخدم. يتم تصحيح هذا في أقرب وقت ممكن لأنّ الجهاز يتلقّى إشارة NITZ جديدة (على وجه التحديد، تلك التي تحتوي على إشارة NITZ) "التوقيت العالمي المنسَّق (UTC-7)، بدون توقيت نهاري" معلومات التعويض) ولكن قد يستغرق ذلك بعض الوقت ويعتمد على مشغِّلي شبكات الجوّال.

ونتيجةً لذلك، فإن التقاويم أو التطبيقات الأخرى التي تخزِّن أو تنقل معرِّف المنطقة الزمنية من الشتاء إلى الربيع وقد يستخدم التوقيت المحلي الخاطئ حتى التطبيقات ذات الصلة معرّف المنطقة الزمنية.

تصحيح الأخطاء والاختبار

يصف القسم التالي أوامر واجهة الأوامر لتصحيح الأخطاء واختبار ميزة رصد المنطقة الزمنية للاتصال الهاتفي

إعداد بيئة الاختبار

يستخدم المختبِرون عادةً بيئة اختبار من خلال خلية اختبار أو محاكاة للاتصال الهاتفي. للتحقق من سلوك رصد المنطقة الزمنية للاتصال الهاتفي. يمكن استخدام خلية الاختبار محاكاة الشبكات ذات حسابات مركز عملائي المختلفة وإرسال إشارات NITZ إلى الأجهزة ثم مراقبة آثارها.

لكي يرصد الجهاز المنطقة الزمنية، يجب أن تكون معلومات إشارة NITZ كما يلي: صحيحة ومتوافقة مع "مركز عملائي" ومتطابقة مع نسخة الجهاز من هيئة أرقام الإنترنت المخصصة (IANA TZDB) (قواعد المنطقة الزمنية) تؤدي إشارات NITZ غير المتوافقة مع "مركز عملائي" إلى جعل الخوارزمية الهاتفية غير مؤكدة.

على سبيل المثال، إذا كان حساب مركز عملائي المستخدم بواسطة خلية الاختبار هو الولايات المتحدة الأمريكية، فإن إشارة NITZ أن يحتوي على معلومات "التوقيت العالمي" و"التوقيت العالمي" و"التوقيت الصيفي" صحيح لمكان ما في الولايات المتحدة الأمريكية.

التفاعل مع خدمة com.android.phone

للتأكّد من أنّ الجهاز يتلقّى الاقتراحات الصحيحة للاتصال الهاتفي بالمنطقة الزمنية، استخدام:

adb shell dumpsys activity service \
    com.android.phone/com.android.phone.TelephonyDebugService

يؤدي هذا الإجراء إلى تفريغ معلومات الاتصال الهاتفي، والتي يمكن العثور عليها أيضًا في تقرير خطأ Android. التقارير. في الأجهزة التي تحتوي على شرائح SIM متعددة، تتوفر معلومات لكل لاسلكي من شرائح SIM.

تعرض سجلات المنطقة الزمنية الاقتراحات التي أرسلت إليها عملية الاتصال الهاتفي. time_zone_detector وأسباب إرسال الاقتراحات.

TimeServiceHelperImpl:
          SystemClock.elapsedRealtime()=11864061
          System.currentTimeMillis()=1620652067178
          Time Logs:
...

Time zone Logs:
    18602 / 2021-05-10T09:50:21.718Z - Suggesting time zone update:
    TelephonyTimeZoneSuggestion{mSlotIndex=0, mZoneId='null', mMatchType=0, mQuality=0,
    mDebugInfo=[getTimeZoneSuggestion: nitzSignal=TimestampedValue{mReferenceTimeMillis=14098,
    mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,
    mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}},
    countryIsoCode=null, Detection
    reason=handleNitzReceived(TimestampedValue{mReferenceTimeMillis=14098,
    mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,
    mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}})]}
    18831 / 2021-05-10T09:50:21.948Z - Suggesting time zone update:
    TelephonyTimeZoneSuggestion{mSlotIndex=0, mZoneId='Europe/London', mMatchType=3, mQuality=1,
    mDebugInfo=[findTimeZoneFromCountryAndNitz: countryIsoCode=gb,
    nitzSignal=TimestampedValue{mReferenceTimeMillis=14098,
    mValue=NitzData{mOriginalString=21/05/10,09:50:18+04,01, mZoneOffset=3600000,
    mDstOffset=3600000, mCurrentTimeMillis=1620640218000, mEmulatorHostTimeZone=null}},
    findTimeZoneFromCountryAndNitz: lookupResult=OffsetResult{mTimeZone(ID)=Europe/London,
    mIsOnlyMatch=true}, Detection reason=handleCountryDetected("gb")]}