Canonical System Image

race condition between android container and powerd may disable auto brightness availability

Bug #1540804 reported by You-Sheng Yang
46
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
Critical
Unassigned
Canonical System Image backlog
powerd
New
Undecided
Alexandros Frantzis
lxc-android-config (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

powerd has upstart startup condition "start on started dbus and android", so it's started after android container for sure. However, android init may take some time to really bring up its property service, and powerd has to read android property "ro.product.device" when initializing its device config. On some devices, there are chances that powerd starts up before android property service is ever ready and leaving following messages in syslog:

  powerd[2506]: Initializing powerd.
  powerd[2506]: owner id: 1
  powerd[2506]: Could not determine device, running without config
  powerd[2506]: libsuspend: detect module: autosleep.
  powerd[2506]: light_dev: setting brightness to 102
  powerd[2506]: Could not determine platform autobrightness capability, disabling

Revision history for this message
You-Sheng Yang (vicamo) wrote :

I tried to add following poll loop to powerd upstart conf as ubuntu-location-service does, but some device still fails to retrieve correct property.

  # wait for Android properties system to be ready
  while [ ! -e /dev/socket/property_service ]; do sleep 0.1; done

Instead, the follow poll guarantees property availability.

  while [ -z "$(getprop ro.product.device)" ]; do sleep 0.1; done

Revision history for this message
You-Sheng Yang (vicamo) wrote :

It turns out, getprop is not a good signal to go, either. getprop and powerd all link to libandroid-properties.so.1 to retrieve Android properties. In some cases getprop succeeds but powerd still fails.

Pat McGowan (pat-mcgowan)
Changed in canonical-devices-system-image:
assignee: nobody → Thomas Voß (thomas-voss)
importance: Undecided → Critical
milestone: none → ww08-2016
status: New → Confirmed
Revision history for this message
kevin gunn (kgunn72) wrote :

assigning to alf for repowerd consideration.
unsure if this is something worthy to be addressed in the near term

Changed in canonical-devices-system-image:
assignee: Thomas Voß (thomas-voss) → kevin gunn (kgunn72)
Changed in powerd:
assignee: nobody → Alexandros Frantzis (afrantzis)
Changed in canonical-devices-system-image:
milestone: ww08-2016 → backlog
assignee: kevin gunn (kgunn72) → John McAleely (john.mcaleely)
Revision history for this message
kevin gunn (kgunn72) wrote :

@john-mc not sure this is really a powerd thing as much as a launching sequence ?

Revision history for this message
John McAleely (john.mcaleely) wrote :

@w-ondra, would this get fixed with your planned 'signal when android is active'?

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in lxc-android-config (Ubuntu):
status: New → Confirmed
Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

This happened on turbo with OTA-11 for me. I haven't been able to restore the automatic control now with multiple reboots, only manual control is possible.

John McAleely (john.mcaleely)
Changed in canonical-devices-system-image:
assignee: John McAleely (john.mcaleely) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.