yashsingh1/xdaforums huggingface dataset:
[Xposed Framework Modules] voland66:
[MENTION=526666]cryptyk[/MENTION] Do you know if amplify's sending process is even allowed to read the stats? My guess would be that this is the most likely place for the problem. If this is the case and if the stats are read from a file, there may be a crude workaround. If the suggestion below works, it should work on all ROMs that have setenforce command (i.e. all ROMs where "SE Linux Mode Changer" works). Well, I'm assuming that all such roms will also have chcon and restorecon commands.

Here it is: just before sending the stats, change the selinux context of the relevant files (by running chcon command from the shell as root) to something that amplify can read. This change is volatile and won't survive reboot, but to minimize effects on the security, after reading stats run restorecon command on those files to restore default selinux context (or run chcon again).

In fact, if the problem is not with reading but with writing, a similar workaround could work but one would be changing the context of destination files/directory instead.

A better workaround (again, assuming that reading stats is the problem) would be to run amplify's sending process with the selinux context/permissions which are needed to read stats, but this is where my familiarity with selinux ends -- I do not know what's required to do so.
[Xposed Framework Modules] cryptyk:
Thanks for the heads up. Right now, that's all gobbledeegook to me. I'll go take a look at chcon and restorecon to see what they are. Thanks!

Ryan
[Xposed Framework Modules] voland66:
[MENTION=526666]cryptyk[/MENTION] If you could tell me which files need to be read, which need to be written and which process does does that (the latter is in the hope of finding a better workaround), I could try running chcon and restorecon manually to check if it helps. If it works, I'll send you the full command that worked.
[Xposed Framework Modules] cryptyk:
Sweet. These are the files that are shared between the processes:

/data/data/com.ryansteckler.nlpunbounce/files/nlpunbounce.stats

/data/data/com.ryansteckler.nlpunbounce/files/nlpunbounce.global.stats

/data/data/com.ryansteckler.nlpunbounce/files/nlpunbounce.push.stats
[Xposed Framework Modules] voland66:
[MENTION=526666]cryptyk[/MENTION] But where do you read the stats off from?

I now know selinux context of amplify's files (object_r:app_data_file:s0) and, given my limited understanding of selinux, the easiest direction I see is to try making source and destination files contexts the same. So I need to know what the source file's context is.
[Xposed Framework Modules] cryptyk:
The files above are initially created as writable by the Amplify activity process (i.e. the process that has the UI). That way they can be read by the limited privileged UI application. The other half of Amplify runs in the system process where it can hook requests for wakelocks and alarms. That piece generates the stats in realtime as wakelocks and alarms are requested. They're stored in memory locally on the system process and then saved to the files above every few minutes.

So the stats are never really "read" from anywhere. I create them myself.

I'm guessing that SELinux is stopping the system process from writing to Amplify's files.
[Xposed Framework Modules] voland66:
[MENTION=526666]cryptyk[/MENTION] Do you know where the system process is allowed to write to?

I hope that once the stats are somewhere in the file, temporarily changing ownership and permissions to allow UI to see them is possible.

(This is an exact opposite to my original suggestion because I thought the problem is with reading stats not writing them.)

I am obviously guessing in the dark here...
[Xposed Framework Modules] Addamas:
Just one question

Is there any option to hide wakelocks / alarms , something like whitelist ? I have apps to keep screen on, as well as I listen music. In result I have "fake" stats of 11 h wakelocks during 3d 3h time.
[Xposed Framework Modules] voland66:
[MENTION=526666]cryptyk[/MENTION] OK, the following seems to do the job for me:

chcon u:object_r:system_data_file:s0 /data/data/com.ryansteckler.nlpunbounce
chcon u:object_r:system_data_file:s0 /data/data/com.ryansteckler.nlpunbounce/files
chcon u:object_r:system_data_file:s0 /data/data/com.ryansteckler.nlpunbounce/files/nlp*

(The original selinux context was u:object_r:app_data_file:s0)

(Update: I see smileys above, they should be replaced by ":" followed by "o".)

The files are now being written to and can be read by amplify UI. I was wrong earlier about persistency of chcon's changes. They survive reboots. But they do not survive system relabel or execution of restorecon on those files. So if my change works for others, context does not have to be changed every time, but it probably should be checked at least periodically (and maybe a menu option to fix context could be added).
[Xposed Framework Modules] cryptyk:
You're an animal!

Can someone confirm this works with SELinux in Enforcing mode? If so, I'll roll it into the next release this week!
[Xposed Framework Modules] FuMMoD:
Beast mode! This is why I love this community!
[Xposed Framework Modules] voland66:
[MENTION=526666]cryptyk[/MENTION] And I did mistype the path in the last command, of course, it should be

chcon u:object_r:system_data_file:s0 /data/data/com.ryansteckler.nlpunbounce/files/nlp*
[Xposed Framework Modules] RusherDude:
[/COLOR]

Just add it into CODE so smileys don't appear :)

chcon u:object_r:system_data_file:s0 /data/data/com.ryansteckler.nlpunbounce
chcon u:object_r:system_data_file:s0 /data/data/com.ryansteckler.nlpunbounce/files
chcon u:object_r:system_data_file:s0 /data/data/com.ryansteckler.nlpunbounce/files/nlp*

Just wondering, even if this does the job, isn't it dangerous to permanently let these 3 files be into that context? can it cause issues? We all want Amplify UI to be able to show the stats, but we don't want to create a security flaw in the process :p

Instead of having to change context, couldn't cryptyk aboard a cleaner solution? for example putting these files on the system partition wouldn't fix the problem too?

Thanks!
[Xposed Framework Modules] voland66:
It is certainly less dangerous than running in the Permissive mode. In general, I think the loss of security here is minimal. If I understand correctly what's going on (and I may be wrong), based on the default context selinux restricts write permissions for these files to the app that created/owns them. The change that I'm suggesting changes app_data_file into system_data_file. Presumably after my commands selinux restricts write permissions to the system processes and the app UI can't write to these files. Read permissions must be unaffected by the proposed change of context (since it works for me). Anyway, in the case of amplify, it looks like the app UI only needs read permissions, so it works. As far as security implications go -- some (all?) system apps/users/processes now can probably write to those files, but there is probably not much damage that can be done here.

In any case, the goal is to give system process writing permissions for these files. If putting them onto system partition were sufficient, it would probably be because the default selinux context there is different. Btw, there are files (belonging to system apps) in /data/data with system_app_data_file context and files in /data partition with system_data_file context, this is how I figured out which context to use.

Again, my understanding of selinux is rudimentary but I suspect changing the context of a few app owned files is better than writing to /system or turning the amplify into a system app (both in terms of security and because touching /system might not be ideal for some roms/devices).
[Xposed Framework Modules] wrongway213:
You, sir, are a dirty filthy LIAR - You said you had a very limited understanding of SELinux :p get that modesty outta here man... if that's a limited understanding of SELinux then my understanding of it is significantly less than none, lol... amazing work.
[Xposed Framework Modules] kenosis:
When I was testing amplify, I used Titanium backup and changed Play Store to User app. After that, i changed back to system app and now my playstore has stopped working.

I have tried to clear cache and data, removed and re-installed new playstore. I can open play store, when i pressed to update/download apps, "Unfortunately Play Store has stopped working" appears. Can I know how to solve it?
[Xposed Framework Modules] eamon0989:
Extending battery life while using MOVES

First of all, thanks for a great app, my nexus 4 can finally make it through the day! I have a question, does anyone here use the app moves? I use it to track where I've been and how far I've walked etc, but it wakes up the device a lot, has anyone found a way to keep using moves but have it wake the device up less often, without losing all accuracy? It is a know battery hog, but I would not mind sacrificing a little bit of accuracy if it meant I could continue using it while no having it kill my battery! Thanks in advance.
[Xposed Framework Modules] rpr69:
This works for me in Enforced mode. I'd love it if cryptyk fixed it in the source, but it's an acceptable risk for me, compared to Permissive everything.
[Xposed Framework Modules] aeoveu:
EntriesRefresh_wakelock (sorry - can't remember the exact wording) seems to be one of those wakelocks that are responsible for Google Now constantly refreshing information, FYI. In my (rather limited) testing, it appears to be the counter that triggers a card refresh in Google Now (because if you set the unbounce limit to 9,999,999, it won't refresh at all).

Thought I'd put this up here just in case some people want to experiment with it. I'm still trying it out, and with 3G signal, and after 1h30m, the reported battery drain was 0.7% (Location Reporting = off, Google Now = on), which is the same amount of drain when Google Now and Location Reporting = off.

What I've done now is that I've set the unbounced value to 2400 as a test. Touch wood, everything should work without draining the battery (nor raising unnecessary alarms).

Edit: Location History seems to report location values slightly more infrequently than before... which makes me want to experiment more with throttling this particular wakelock. For those who will attempt to disable the service altogether, note that it'll render your Google Now useless (i.e. Google Now will not work, activate nor refresh... you can deactivate Google Now though).
[Xposed Framework Modules] cryptyk:
I've looked into this, and this method really is fixing it at the source. The reality is that Amplify has to communicate between processes using files. That's something that is, by default, disallowed by SELinux. The correct way to fix it is exactly what voland66 has shown above: Allow those specific files to be written by the system.

Any other change (e.g. putting the files somewhere that Amplify and the System can both read/write) has the extremely low level of risk.

I feel good about the change. I'll implement it this week!

Thanks,

Ryan
[Xposed Framework Modules] rpr69:
I wasn't trying to imply that the fix was not proper, I meant that I was hoping you would put the same fix into the app somehow so I don't have to remember to redo it if anything changes.

Sorry for the confusion!
[Xposed Framework Modules] RusherDude:
Yeah, you could put the files on /system and the problem would be solved too I think, but the changing contexts suggestion is OK. Remember to do those schmods automatically everytime the system reboots! :good:
[Xposed Framework Modules] cryptyk:
If I put the files on /system, I have the opposite problem... Now Amplify's UI wouldn't be able to access them.

That's really the crux of the problem: Amplify runs in two processes. One with only access to the System files, and one with only access to Amplify's files. The only place I think that is accessible by both is the SD card, which makes me a bit nervous. I like the idea of granting access to the System process so it can read Amplify's files.
[Xposed Framework Modules] RusherDude:
Really? I though that there were problems with stuff accesing to /data/data/, and there was no problem with /system (using su of course).

Just wondering.. couldn't use a third (chill? chill with another context?) process for changing data between the other tho some the problem? I remember reading the xposed thread between rovo89 and chainfire and I don't know If I remember well but that was said as some solution for sharing data, or I remember bad...

But anyway, use the one you have already :D
[Xposed Framework Modules] MetinKale38:
Seems like here is something wrong, or? Statistics time starts with the app, anything is 0, it was running for about half of a day. Wakelock, Alarms menu etc are empty...

I am using Lolipop CM12 latest nightlies...

Tried several tries after the Lolipop "support"...

U need logs?[emoji23] How to get them?
[Xposed Framework Modules] jfim88:
You need to set SELinux to Permissive. Read a few post
[Xposed Framework Modules] voland66:
[MENTION=526666]cryptyk[/MENTION] Ryan, the one thing you might be careful about is to find out whether the new contexts for the parent folder(s) (com.ryansteckler.nlpunbounce and files folder inside it) affect anything else residing there that amplify needs for other purposes.

I changed contexts of those parent folders at first and I think the change was needed for stats to work but I don't remember if I checked it carefully enough.

Yuri

---------- Post added at 02:12 PM ---------- Previous post was at 02:08 PM ----------

[MENTION=4811172]RusherDude[/MENTION] [MENTION=526666]cryptyk[/MENTION] I do not think chcon should be done on every boot, only after full filesystem relabel or execution of restorecon on those specific files. Neither of those things will happen frequently, so the minimalist approach would be to check for right context at boot and only change it if necessary

Yuri
[Xposed Framework Modules] BlakeSm:
I've donated for pro features awhile ago, and now on Lollipop it's asking me to donate again to unlock pro features. Is this a bug?
[Xposed Framework Modules] Pkt_Lnt:
In post #1
[Xposed Framework Modules] doubleho:
please add "*alarm" to unsafe to limit

I limited it and have a bootloop, my nexus6 reboot 30seconds after it is rebooted, work fine after I uninstalled and reinstalled amplify
[Xposed Framework Modules] Farsiris:
Hello .i already set this alarm wakelock to 600 and still got this in wakelockdetector.very huge value
[Xposed Framework Modules] mattia.b89:
I didn't edit anything in Amplify
[Xposed Framework Modules] kenzolo:
"Your device doesn't support in app billing.You won't be able to purchase the pro features.This could be because you need to update your google play store application,or because you live in a country where in app billing is disabled"

Already read the solution post but it doesn't fix the issue.

also... if I try to tap on donate button I have a force close.

Here the catlog

http://pastebin.com/dsE3XkHP
[Xposed Framework Modules] edvinn:
Get the MyAndroidTools app from google play store. Select Service from the menu, then select the System tab, and find Google Play Store. Make sure InAppBilling is not disabled.
[Xposed Framework Modules] kenzolo:
woo thanks... it work :)
[Xposed Framework Modules] Ninja_Gundam:
Maybe it's better a little unlocker app for license, like greenify has, maybe will fix user's problems and have them use luckypatcher or whatever; Then would be possible to freeze xposed and market again and let amplify do his job :)

Chooo
[Xposed Framework Modules] orbitalcomp:
OK, I just checked again and I do have the search icon. 3.0.1 is definitely working for me on Kit Kat.

What threw me off is how it still says 2.0.7 under Settings -> Developer Credit. Maybe that can be fixed on the next update.
[Xposed Framework Modules] carlese:
Guys how do i change settings in Amplify? I am on xposed lollipop and with enforcing i don't see anything to change the time interval..
[Xposed Framework Modules] aeoveu:
*facepalm*

Did you read the past few pages?
[Xposed Framework Modules] carlese:
Yes, I've seen that in order to see the wakelocks I have to be in permissive mode, but I asked another thing.. How can I set the wakelocks time for example to 600? I don't see any option..
[Xposed Framework Modules] grisu59964:
Tap on the wakelock you want to limit in the wakelock overview (reachable by the side menu). An options page with a description, the possibility to set the limit and statistics appears.

Didn't you tap on a wakelock or does the settings page not open on your device?
[Xposed Framework Modules] carlese:
Probably it's all related.. I can't see any wakelock because I'm in enforcing mode..
[Xposed Framework Modules] aeoveu:
Okay, I think I found the sweet spot - I managed a drain of 0.8% per hour (after testing for ~2h30m). These are my settings (for wakelocks only - nothing else).

- NlpWakeLock: 240 seconds (default)

- NlpCollectorWakeLock: 240 seconds (default)

- UlrDispatchingService: 240 seconds (had to enable this)

- EntriesRefresh_wakelock: 720 seconds (had to enable this) (and I STRONGLY think this is the culprit for Google Now, outside of location wakelocks)

- BleScanReporter_WakeLock: 2400 seconds (had to enable this) (this is a very pesky wakelock, and though I don't use bluetooth, those with smart watches may want to tinker with this).

The time throttle for EntriesRefresh_wakelock depends on your requirements for Google Now. By default, it seems to update very regularly, but with a throttle of once per 12 minutes, I think it's a good compromise between battery life and relevance/recency. I have to test the reminders (whether the phone shows the reminders on time, or 12 minutes late), but I do know that Google Keep tends to show the location reminders almost at the correct time (very limited testing).

Also, Location Reporting seems to function fine as well (recording my history) but with an idle drain of 0.8% on 3G.

Perhaps you can add these as the default settings in Amplify, [MENTION=526666]cryptyk[/MENTION] (minus the bluetooth throttle, since I seem to be getting that).
[Xposed Framework Modules] Derodraaa:
I concur... stupidly I tried it twice (but guess it helps to confirm its not safe to limit). Ended up in bootloop and needed to restore a nandroid backup to get out of it.
[Xposed Framework Modules] Me Gusta:
Hmm.. Guys, I've purchased the pro features back on Kitkat. Now I'm on lollipop GPE on my S4 now, but I'm not able to access the pro features. I had Lucky Patcher installed in the beginning, but by reading the OP, I found out that should uninstall it, so I did.

However, the pro features still don't work, even after reinstalling Amplify.. I'm a bit lost now, and would be very glad if someone could help me. Thanks in advance!

Me Gusta!
[Xposed Framework Modules] Pkt_Lnt:
post 4323

http://xdaforums.com/showpost.php?p=59052874&postcount=4323
[Xposed Framework Modules] Me Gusta:
Much appreciated!

Me Gusta!
[Xposed Framework Modules] str8str:
Should
[Xposed Framework Modules] doubleho:
just disable amplify before it reboot, then uninstall and reinstall the mod
[Xposed Framework Modules] condudad:
Running great here, couldn't live without this on KK and can't live without it on L ;)
[Xposed Framework Modules] s2d4:
Just can't donate. Went through all the possible reasons as mentioned, followed all suggestions to no avail. This is on nexus 6, stock ROM, app from play, no blocker and no idea what lucky patcher is so definitely don't have it, in app billing is fine for all other apps.

EDIT: noob mistake, donate via home page. Was expecting ability to donate when the popup occurs telling me to donate.
[Xposed Framework Modules] II12yanII:
Im new to this app. I just got it yesterday and so far havent seen much battery improvement. Right now its just the default settings from amplify but my phone is draining about 6% every hour. Thats alot higher than what other people are getting im just wondering why mine is using so much more power and what i can do to fix it. The screen shots are from only about 2 hours of idle time. I did send a couple texts during that time.
[Xposed Framework Modules] Pkt_Lnt:
Use Better Battery Stats and Wakelock Detector to analyze what is draining your battery, then use Amplify to control the problems.
[Xposed Framework Modules] Masrepus:
[MENTION=526666]cryptyk[/MENTION] would you mind adding a small option to reset stats every day at 00:00? Cause i would always like to see the stats of this exact day but always forget to reset stats the night before

--------------------

Phone: Nexus 4

OS: rooted Lollipop LRX21T

Bootloader: unlocked

Recovery: TWRP 2.8.2.0
[Xposed Framework Modules] aeoveu:
I'm not editing my OP so that more people can read (and see the older posts via the post links), but I found another prick in the wakelocks: TrafficIntentService_onHandleIntent

Today, I wasn't able to get the 0.8% drain on 3G - which drove me bonkers. What I did see is the presence of another wakelock. I would run a battery drain test (I ran three different tests, each for AT LEAST one hour - although I would prefer one with longer hours, my phone usually does not remain idle because some nutjob decides to message me or call me, and that drives me up the wall when testing) and the lowest drain I got (in ~2hr) was 1.3%. The highest I got was ~3 or 4%.

And using BBS and GSam Battery Monitor, I would set up a custom reference point (or in GSsam, use the "since screen off" measurement) and then turn off the screen, and not use the phone (I'm not connected to wifi, but scanning is always on, and the settings toggle was on "off"...but anyway, that was my configuration yesterday as well). So after turning back on the screen, TrafficIntentService_onHandleIntent would appear EACH AND EVERY SINGLE TIME!

Does anyone know what this is? I reset Amplify's stats today, and this has the highest drain (for non-amplified items - at 5:09... for comparison purposes, the next highest is NlpCollectorWakeLock, which stands at 1:11). I've throttled it to 2400 seconds, so let's hope it fixes things.

I ought to maintain a diary - but I think people would benefit if I write my findings (almost) as they happen. That way, people can provide feedback.
[Xposed Framework Modules] Weetbix:
You can already achieve this with tasker. Of course that depends on actually having tasker.....
[Xposed Framework Modules] Masrepus:
Yeah i actually have tasker installed, didn't think about this being possible ?

--------------------

Phone: Nexus 4

OS: rooted Lollipop LRX21T

Bootloader: unlocked

Recovery: TWRP 2.8.2.0
[Xposed Framework Modules] chrisg1548:
Hey guys, new to this and want to know which wakelock or service do i need to edit for the proximity sensor. my issue is on chroma rom i use ambient display and when a notification comes in i just wave my hand over the phone and it displays but since using amplified that feature has been some how disabled and want to have the option back, thanks
[Xposed Framework Modules] esklarski:
Just tried voland66's solution and can report it is working for me. SELinux is set back to enforcing, and Amplify seems perfectly happy.

On a Nexus 5
[Xposed Framework Modules] Dovidhalevi:
Limiting that EntriesRefresh_wakelock is the first thing that seems to make a difference. I have not seem the Ble .... , trying bluetooth now to see if I suddenly get this one, so far, no.
[Xposed Framework Modules] alexoliv88:
Did you get any luck sorting it out?

I had the same problem, i ended up uninstalling amplify and activity detection is working again.
[Xposed Framework Modules] Jongla:
installed amplify and activated in xposed..then opened it,it says something went wrong and says to enable amplify and reboot,but itt was already ticked.. :/

what to do?

i am using 4.4.4 on xperia z..

Sent from my C6603
[Xposed Framework Modules] sjors86:
Found it
[Xposed Framework Modules] supercluver:
Have you tried a soft reboot?