microg / microg/GmsCore

GCM connections never last for more than 1 minute. Is this normal?

Open
#1,340 10 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

☁️ Cloud / Push Messaging bug
Dominant language
Java
Stars
14.6k
Forks
3.2k
Avg merge
12d 11h
Merged PRs (30d)
4

Description

Describe the bug
It seems microG's GCM is not stable. In my case, it disconnects once every 60 seconds and recovers about 5 seconds later.

The Status' "Connected since x seconds ago" never went beyond 1 minute for me.

Setting different ping intervals doesn't help, either. It seems the "Automatic" option is already setting an interval higher than 1 minute so I might be having a different issue than #1011.

I haven't gotten a logcat yet, but a hint about what kind of log messages to look for is greatly appreciated.

To Reproduce
Steps to reproduce the behavior:

  1. Go to microG settings
  2. Click on Google Cloud Messaging
  3. Check Status
  4. The Status would say "Connected since xxx seconds ago", but when it reaches 1 minute, it becomes Disconnected and about 5 seconds later it becomes Connected again.

Expected behavior
Unless this being a normal behavior, the Connected status should stay for long enough, disconnections should not be frequent.

Screenshots
No screenshots for as it's self-explanatory.

System
Android Version: 10
Custom ROM: Havoc GSI 3.8 running on Razer Phone 2 (with arter97 r14)

Additional context
All self-test states are checked so microG is running normally. I'm using NanoDroid, with microG installed systemlessly.

I noticed I'm receiving messages very late (can be as much as 10-15 minutes), unless I put that particular app in the foreground before I set the phone to sleep. Maybe this is related.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the reproduction steps in the issue: observe the GCM status through the one-minute disconnect and collect the requested logcat output. Compare the disconnect and delayed-message behavior to determine whether it is expected or identify the failing connection path; done means the behavior is explained or a concrete fix scope is established.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, java
Domain
mobile
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.