を作るためにこれらの2つの両極端の間でなLocationRequestのAPIAndroidのGoogleがサービスを再生する：ベスト・プラクティスを位置要求の下
のための公式ガイドsiteから現在の引用は間違い アプリケーションは非常に一般的なユースケース、です の間隔でアップデートを受信したい場合は、利用可能な場合は速く受信することができますが、依然として の消費電力には影響しません。これらのアプリケーションは、（長い）速い setFastestIntervalと組み合わせる PRIORITY_BALANCED_POWER_ACCURACY（例えば1分）及び（ロング）遅く のsetInterval（例えば60分）を考慮すべきです。それらはsetInterval（long）で設定された間隔の間にのみ電力不足の が割り当てられますが、 のsetFastestInterval（long）までのレートで他のアプリケーションによってトリガされる の受信場所を依然として受信できます。このスタイルのリクエストは、バックグラウンドでの使用を含め、多くのロケーション認識アプリケーションに適しています（ ）。 ネットワークを使用している場合など、アップデートを受信した後に 重大な作業を実行する場合は、 もスロットルのsetFastestInterval（long）に注意してください。
私の関心は、ミリ秒単位で明示的に位置情報の更新のための最速の間隔を設定し、これらのメソッド
LocationRequest setFastestInterval(long millis)
、に関するものです。
LocationRequest setInterval(long millis)
アクティブな場所の更新に必要な間隔をミリ秒単位で設定します。
私は間隔= 30秒、最速= 8秒、t = 8、t = 16、t = 24（8の倍数）を設定すると、他のアプリケーションから更新が得られますか？実行中の位置認識アプリがない場合はどうなりますか？ 30秒で新しいアップデートを見ることができますか？そのアップデートは私のアプリの消費電力としてカウントされますか？それはどのように推定されますか？
これが正しければ、これらの2つのパラメータの間には、多くの電力を消費することなくリアルタイム更新を得るための良い関係はありますか？たとえば、interval = 6 x fastest？
私は自分自身で試してみましたが、ガイドで説明されているシナリオを繰り返すことはできません。電源の不具合を特定することはできません。