Closed Bug 1016041 Opened 10 years ago Closed 10 years ago

Eideticker should work on unrooted devices

Categories

(Testing Graveyard :: Eideticker, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wlach, Assigned: wlach)

References

Details

Attachments

(2 files, 1 obsolete file)

Right now Eideticker depends on using a rooted devices for really no good reason. It would be nice to fix this as keeping devices up to date with rooted software is a bit of a hassle. Also, I really don't want to root my Nexus 5.
One aspect of this is using am force-stop to stop applications instead of killing them (because the adb user doesn't have permission to do that). We need a new version of mozdevice incorporating bug 907427 for that.
Depends on: 1016042
So one aspect of this is allowing the executables that eideticker uses (orangutan, ntpclient) to be in /data/local/tmp/, as that's the only place that some devices (e.g. the Nexus 5) can write to when unrooted.
Assignee: nobody → wlachance
Attachment #8428875 - Flags: review?(bclary)
Actually it looks like the stopApplication logic in mozdevice isn't quite adequate as-is, since it doesn't support old versions of Android. Filed bug 1016073 to try to get that addressed.
Comment on attachment 8428875 [details] [diff] [review] Search for orangutan, ntpclient in /data/local/tmp as well Review of attachment 8428875 [details] [diff] [review]: ----------------------------------------------------------------- r+ with the KeyError fixed. The other comments I leave to your discretion. ::: src/eideticker/eideticker/device.py @@ +118,5 @@ > self.model, self.type)) > self.deviceProperties = DEVICE_PROPERTIES[self.type][self.model] > > + for (name, execname) in [("orangutan", "orng"), > + ("ntpdate", "ntpclient")]: Since we use 'orangutan' and 'ntpdate' as keys in several places, do you think it would be worthwhile to define them as constants and then when using them as keys use the constant variable name instead of the literal string? Mark has suggested this to me in the past. @@ +125,5 @@ > + if self.fileExists(fullpath): > + self.exec_locations[name] = fullpath > + > + if not self.exec_locations[name]: > + raise mozdevice.DMError("%s not on device! Please " the self.exec_locations[name] will raise a KeyError if it is not set and you will never raise the corresponding DMError. @@ +132,1 @@ > Do you think it would be worth while to check both files before raising the DMError and report on them both if neither is installed?
Attachment #8428875 - Flags: review?(bclary) → review+
(In reply to Bob Clary [:bc:] from comment #4) > ::: src/eideticker/eideticker/device.py > @@ +118,5 @@ > > self.model, self.type)) > > self.deviceProperties = DEVICE_PROPERTIES[self.type][self.model] > > > > + for (name, execname) in [("orangutan", "orng"), > > + ("ntpdate", "ntpclient")]: > > Since we use 'orangutan' and 'ntpdate' as keys in several places, do you > think it would be worthwhile to define them as constants and then when using > them as keys use the constant variable name instead of the literal string? > Mark has suggested this to me in the past. Sure, good idea. > @@ +125,5 @@ > > + if self.fileExists(fullpath): > > + self.exec_locations[name] = fullpath > > + > > + if not self.exec_locations[name]: > > + raise mozdevice.DMError("%s not on device! Please " > > the self.exec_locations[name] will raise a KeyError if it is not set and you > will never raise the corresponding DMError. Oops. Will fix. > Do you think it would be worth while to check both files before raising the > DMError and report on them both if neither is installed? I don't think it's really necessary. We already tell people to build + install both in the documentation.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Oops, this is actually not quite fixed, since we still have problems with the stop/start behaviour.
Status: RESOLVED → REOPENED
Depends on: 1016073
No longer depends on: 1016042
Resolution: FIXED → ---
Attachment #8431069 - Flags: review?(bclary)
Attached patch Use stopApplication, take 2 (deleted) — Splinter Review
First take of the patch had some problems, oops.
Attachment #8431069 - Attachment is obsolete: true
Attachment #8431069 - Flags: review?(bclary)
Attachment #8431075 - Flags: review?(bclary)
Comment on attachment 8431075 [details] [diff] [review] Use stopApplication, take 2 Review of attachment 8431075 [details] [diff] [review]: ----------------------------------------------------------------- Looks good.
Attachment #8431075 - Flags: review?(bclary) → review+
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: