Related
I like Droidwall. Here's my review: Droidwall is a nifty program which can easily be configured to block wifi and/or data communication for each individual application. Perhaps allows small savings in battery, data usage, and slight improvement in security. Particularly when app had no logical purpose to acces internet other than advertisements etc. Also does not cost any significant cpu or memory resources... just modifies a table somewhere.
Now onto my question:
One of the applications that I blocked was labeled “(Kernel) – Linux Kernel”
Blocking the “kernel” has no effect on items like browser, gmail etc.
Based on Droidwall log, over the past several weeks since I installed the program, it has blocked 397 outbound packets from “kernel” which were destined for a variety of IP’s that all seems to be associated with Google, XDA, or Microsoft.
Below is an example of three of the IP’s:
Google
74.125.227.140
https://ipdb.at/ip/74.125.227.140
xda
50.23.216.69
https://ipdb.at/ip/50.23.216.69
Microsoft
65.52.32.12
https://ipdb.at/ip/65.52.32.12
Another thing I noticed, these are the only log entries where the external IP is recorded in the log. In all the other non-kernel blocked-application log entries, the IP recorded is my router IP.
I’m using Entropy’s DD kernal on GB.
It seems to me a little strange that these outbound transmissions are associated with the kernel. And at the same time, they don’t seem to be associated with any obvious legitimate purpose....because my phone works fine on normal internet application even with “kernel” blocked by Droidwall.
Does anyone have any ideas what would be the explanation for these packets sent from kernel to Google, MS, xda ?
Well I don't know much of anything about programming, however some people say that it isn't just apple that collects information about people without them knowing. Could be that or I could be completely wrong.
Just for curiosity, do you allow anonymous data to be collected and sent to Google?
Sent from my SGH-I997 using xda app-developers app
If no answer here, maybe post your question here: http://forum.xda-developers.com/showthread.php?t=1957231
Well I don't know much of anything about programming, however some people say that it isn't just apple that collects information about people without them knowing. Could be that or I could be completely wrong.
Just for curiosity, do you allow anonymous data to be collected and sent to Google?
Click to expand...
Click to collapse
I generally answer no the the “anonymous data collection”.... thinking about battery, data usage, and privacy. I think several apps have that question. I don’t doubt there are a lot of programs trying to communicate for a variety of non-obvious (possibly suspicious) reasons regardless of how you set up the options. ....there were a several installed Apps attempting access that had no obvious reason to do so.
What initially struck me as strange was that this was attributed to the kernel.. that didn’t quite compute. Trying initially to formulate an intelligent thought about what that meant, I utterly failed and came up with the notion that these items must somehow be related to programming by the developer of the kernel. When I actually engaged my brain, I realized that was just plain silly because:
1 – That would be Entropy. Enough said.
2 – The kernel is open source.
3 – There are several different destination ip’s. If one person was trying to collect data, he wouldn’t send it to different places. So it must be several applications interacting with the kernel.... just shows up attributed to the kernel by Droidwall.
If no answer here, maybe post your question here: [afwall link][
Click to expand...
Click to collapse
Thanks Pony Ex. I didn’t know that program afwall existed. Looks like it might have some good improvements to an already-great program (Droidwall). Will definitely give it a try. But I’m not bold enough to post this type of question in the developer’s thread though... several others were scolded for non-appropriate posts in that thread.
To my limited understanding, and I apologize if I am wrong, entropy just modified the kernel that was already there? Hence why the new ICS and jelly bean ROMs are still using a gingerbread kernel.
So who actually wrote the kernel? Samsung? Google? Both?
I agree I don't see entropy gathering personnel data.
However, apple was caught doing it and to the conspiracy minded individual, Google (a company that made it's fortune with information) would be in a similar position to do the same.
Again I have no evidence or knowledge to back up anything I'm saying, however what better way to collect information then distributing a free open source program with 100's of millions of users?
Sent from my SGH-I997 using xda app-developers app
electricpete1 said:
Thanks Pony Ex. I didn’t know that program afwall existed. Looks like it might have some good improvements to an already-great program (Droidwall). Will definitely give it a try. But I’m not bold enough to post this type of question in the developer’s thread though... several others were scolded for non-appropriate posts in that thread.
Click to expand...
Click to collapse
electricpete,
http://forum.xda-developers.com/showpost.php?p=35352916&postcount=256
I'll fade the heat.
Edit: His first reply: http://forum.xda-developers.com/showpost.php?p=35360652&postcount=257
Pete,
Are you using the Droid Wall to stop the outgoing packets to ensure privacy or are you using it to stop the wakelocks that may be contributing to the wifi drain bug on gingerbread?
Here is a reply from someone else... pretty good read:
http://forum.xda-developers.com/showthread.php?p=13148076#post13148076
post # 47
Pony Express said:
Here is a reply from someone else... pretty good read:
http://forum.xda-developers.com/showthread.php?p=13148076#post13148076
post # 47
Click to expand...
Click to collapse
Thanks Pony Express, for posting that question. Good info in the responses and other links.
qkster said:
Pete,
Are you using the Droid Wall to stop the outgoing packets to ensure privacy or are you using it to stop the wakelocks that may be contributing to the wifi drain bug on gingerbread?
Click to expand...
Click to collapse
There is the potential to improve all three (limit data usage, limit battery usage, improve privacy).
I think the improvements in battery life and data usage are probably relatively small (especially because I also manage those by turning my connections off when not in use while away from home wifi)... whereas I think the improvement in privacy may be substantial... so I guess that's my main interest (improving privacy).
But since the $ cost and resource cost is basically zero, it almost seems to me like no-brainer choice to use it regardless of the level of benefit we expect (unless there is some hidden disadvantage...which I haven't seen yet).
I wasn't aware of a particular wakelock problem on Gingerbread. I haven't particularly noticed a change in batteryusage one way or the other (and I really wouldn't expect to notice unless it was a dramatic change), but it stands to reason that reducing traffic from unwanted Ads, pinging, data-gathering etc could help. Here are some links that may support that view:
http://gizmodo.com/5894572/in+app-ads-are-destroying-your-battery-life
http://www.theverge.com/2012/3/19/2884902/android-apps-battery-efficiency-study
There was one poster in the AFwall thread that suggested an App that is denied access will keep trying again and again, and therefore use more juice..... which also sounds plausible, but several others disagreed with that.
* I have installed AFwall now, in place of Droidwall. It is the same program with a few improvements (fixed hole in the security wall during reboot) and a lot of extra features. But still keeps the same basic simple user interface.
Purpose: To share my personal experiences how I achieved an enhancement of my battery’s life, privacy and security.
INDEX:
Post #1 - General Statements, ROM and Kernel.
Post #2 - Privacy Measures and Considerations.
Post #3 – Better Battery Stats.
Post #4 – Greenify.
Post #5 – Amplify.
Post #6 – Power Nap
Post #7 – AppOpsXposed
THE BASICS:
Please read the XDA Forum Rules provided by @MikeChannon; from my personal point of view a definite MUST READ for everybody who intends to post on XDA or to contribute to this great site. Other MUST READ's I certainly recommend to everybody who wants to "breathe" what I believe the spirit of XDA is, are the following posts:
Forum Etiquette by @TheByteSmasher,
http://forum.xda-developers.com/showpost.php?p=16682226&postcount=2441 by @zelendel, and last but not least
http://forum.xda-developers.com/showpost.php?p=2031989&postcount=44 by @kyphur.
Do me the favour and really inhale what I just linked above!
Disclaimer:
Your device requires to be rooted, and in most cases that the Xposed framework is installed, too.
I am not responsible for any damages to your device if you follow any of the suggestions or my experiences provided in this thread.
If you do your warranty is now void. I am not responsible for bricked devices, dead SD cards, thermonuclear war, or if you’re getting fired because the alarm app failed. Please do some research if you have any concerns about features mentioned in this thread before flashing anything! YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
Whatever you do, before you do it ensure you save a NANDROID backup. If you don’t know what this means you’d probably rather discontinue further reading. Alternatively, you might want to start reading this and then return: What is?Boot loader,custom roms, CWM, modem, kernel?? by @esimon311.
Background: In December 2015, I got a used SGS 3 LTE that was running on CM 10. Immediately, I started to search for others ROMs especially on XDA (actually my first contact with this fantastic forum), thoroughly read the OPs and the subsequent posts, flashed and tried a few of them, till I've ended up in the configuration I'm now using for nearly nine months (details are available in the hidden part of my signature). I'm extremely happy, and my phone completely fulfils my requirements and desire; thanks to @rodman01, the dev of "my" ROM, I certainly don't need a different phone.
I'm quite "paranoid" in regard to privacy i.e. I don't and won't ever use things like FB, Whatsapp etc., and I’m not having experiences with them. Privacy is also my main driver to have my devices to only carry a minimalist suite of Google (“pico” and even some of that crap uninstalled) because I only use Play Store (unfortunately, some of my favourite apps incl. their betas are only available there) and broad location. If I'd get MicroG to run on my device Google had already been totally eliminated.
Desired End State: A device, which runs in a well-balanced ratio between battery endurance or drainage and performance specific to my objectives.
Criteria for Success: Battery lasts at least for 36 hours while all functionalities in regard to the objectives are applied; no unintended or random reboots occurring; no frozen screen.
Own Centre of Gravity: Maximum privacy.
Objectives:
Phone calls 24 hours per day, 7 days a week (24/7).
Text messaging 24/7.
Email reception and transmission 24/7.
Email and messenger encryption.
No “social networks” at all unless provider fulfils all privacy requirements.
No “messenger” except “Signal” but Signal 24/7.
All what can be accessed via a (slim line) browser, will be accessed via browser but not via dedicated applications.
If possible and achievable, no use of any Google “tool” or service.
If possible, no use of Chinese or Russian “products” or from any other country of “similar quality”. If unavoidable to use such a product, no WiFi, mobile data, or VPN access at all; all private or confidential data will be spoofed.
Control of access to private or confidential data like contacts, calendar, location, telephone number, IMEI etc. Spoofing as access control is acceptable.
Control of permissions only via ROM tools.
Control of broadcast receivers, services, wakelocks, and alarms.
Battery endurance of at least 24 hours.
Scenario: Remote location close to a national border with low 4G and 3G reception, even GSM reception occasionally weak and weather depending. No gaming at all.
Initial Steps: As stated above at background, I quite intensively and thoroughly scanned XDA for a ROM that could suit me; reading at least all the Ops but screened the respective thread, too. I finally but quickly found my desired one with [ROM][6.0.1][i9305 OFFICIAL] Resurrection Remix® M by @rodman01 in April 2016; it became my daily driver, and I’m using it till today.
Very fast, I concluded that performance of my phone might be enhanced by replacing the stock ROM kernel by a custom one i.e. I commenced the same search for a suitable kernel as I did for the ROM. Please be aware that kernel totally depend on the device and highly on the ROM. Read extremely thoroughly through the respective OP of the kernel you’ve in mind and get a clear indication if the kernel is really suitable for your device and your ROM. Even then, there might be more than one version available (as it’s the case for my current kernel); simply try, which one runs the best on your phone but also study the thread – others might have already shared experiences.
Next step was to experiment with the kernel settings especially the governor, governor and GPU frequencies and under-voltage. It became a try-and-error process including frozen locked screens and unintended reboots but the result was worth the torture. I was able to find kernel settings in accordance with my objectives especially improving the battery duration. I found the following thread extremely helpful in working out “my” kernel settings: [REF][GUIDE]Most up to date guide on CPU governors, I/O schedulers and more! by @Saber. If you search the thread of my kernel but also the Q&A section of my ROM you’ll certainly able to find some of the experiences I tried to share. Attached is a zip-file with screenshots of my current kernel settings.
Please be aware that not all kernel come with the same types or number of available governors. Some come with a dedicated control tool, some use the tool e.g. provided by the ROM; and as this would be off-topic and isn’t important to me, some offer different sound control like “boeffla”. Unless you’re on AGNi like me with its own AGNi Control application or on another kernel with its own control tool, I’ve very good own experiences with a tool called [APP] [4.0+] Kernel Adiutor by @Grarak. From my point of view, besides the marginal ROM settings to decrease battery drainage, installation of the right kernel and manipulation of its settings were the first major step to enhance my battery’s life!
Soon, I realised there are two versions of my ROM available, the “regular” one but also a so called “Sammy version” (for those who are interested, the differences are explained in post #3 of the above linked Resurrection Remix thread). I converted to the Sammy version and was impressed; first, how smooth my device performed “on Sammy” but second and more important to me that battery charging was much faster.
Nonetheless, if required I'm tweaking my system by tools like [APP] [4.0.3+] L SPEED Android tweaking APP by @Paget96 and keep it clean and tidy by [APP][1.6+] SD Maid - System cleaning tool by @Dark3n. SD Maid additionally offered me the possibility to easily control the “autostart” behaviour of my installed applications; however, there are certainly other tools available for this purpose e.g. My Android Tools that I'm also mentioning in post #2 for another reason.
Please be advised that for all somewhere in this thread mentioned applications or tools, I personally started using them with the recommended settings in their OPs if available i.e. you must thoroughly read them but eventually commenced to experiment with different settings until I achieved the results I wanted. This certainly also applies to the use of e.g. different governors or other kernel settings. I collected some of the guides and tutorials, which were very useful and supportive to me, in post #3 of this "How-to...". This whole thread is meant in conjunction with the SGS3 but some parts might be helpful even for your device.
EDIT (2016-11-11): If you experience WiFi drops you might be interested in experiences that @Wood Man is sharing with us, and he gratefully allowed me to quote him regarding WiFi drops that occured to him several times. It never happened to me because my setup was (just by accident) always different; however, if WiFi drops occur to you please have a look at this post. The explanation is so reasonable and makes so much sense from my point of view. Thanks very much to Wood Man for sharing his knowledge. I do mention this issue in this OP as I assume that these type of connected inteferences might even lead to a higher battery drainage in turn.
Last but not least a few words regarding Xposed – I apologise to the multiple XDA users who already know for covering this here but just by monitoring all the Xposed threads I’m convinced a lot of guys just don’t know. The Xposed framework in available in different versions pending e.g. on the brand of the device or its architecture, on the ROM respectively the Android SDK or if systemless root is used. I refrain from quoting all the different Xposed threads at this point; simply search the Xposed forum by yourself, and you certainly find the framework suitable to you. In the hidden part of my signature you can retrieve the Xposed version I’m using.
We talked about ROMs and kernels, now let’s mention the other key players for my satisfying battery endurance but as stated you certainly need Xposed:
BetterBatteryStats, Greenify, and Amplify, and PowerNap. EDIT (2016-11-11): Please refer to post #6 (about PowerNap) why I "removed" PowerNap.
I tried all of them, it worked out for me, and I'm continuing to use them; however, that what I stated in the paragraph above applies for them too: Comply with the recommendations and develop it further till you are satisfied.
EDIT (2016-11-19): If interested how I made my system GApps free, please check post #54.
Remarks:
If a donation option is available please consider to take advantage of this chance as you not only occasionally get a better capability but you're supporting the dev and the development.
None of the mentioned apps has got permission granted to the internet, and all are spoofed by XPrivacy. I'm pretty cautious regarding applications if so much power has been made available due to root and Xposed, and I always take their origins into consideration (a reason why I don't update my SuperSU anymore and continue to use SuperSU v2.76).
Occasionally, it's required to post you logs on XDA, and quite a few guys have problems with attaching files to their post; me too. In such a case, I suggest to try a different browser; I can only post all allowed attachments via Microsoft Edge and Chrome. FF, IE and Chrome doesn't allow for whatever reason; they even don't provide any possibility to select a file for upload. I have no experiences with XDA Labs. EDIT (2016-10-18): I don't know what changed a few minutes ago but I'm now able to use Chrome for the upload of files. Weird! Another option is to upload e.g. to http://hastebin.com and to post the link.
Now, you know more or less what I did to achieve a really good battery life.
ATTENTION: In accordance with my objectives
No so called "social network" applications (e.g. Whatsapp, Twitter, Instagram, Facebook or how you name them) at all are installed on my devices i.e. you couldn't find any settings/limitations regarding them.
All my described settings/limitations are in that way that no push notifications at all are allowed (because I want it this way). Every wakelock and alarm connected to Google Play Services (GPS) is somehow limited; not one is unlimited. Quite a few services of GPS and/or Google Services Framework (GSF) are disabled. Edited because all devices are GApps-free.
If you just copy my settings without any reflection do not wonder that all of your push notifications are (even extremely) delayed. If you require anything of above you need to play with your system yourself.
The following posts provide you with details of all the applications I use to monitor and to limit the drainage of my battery.
CREDITS: To everybody who I mentioned in this OP or the subsequent posts. If I forgot someone I apologise. Please let me know in this case or if you want to be more prominently given credit; I'm happy to immediately follow such a request!
Off topic comments are allowed as long they are generally related to the overall topic, are in the general interest of the followers of this thread and add value to the thread. The ultimate decision rests with me as the OP!
Privacy Measures and Considerations
You might be wondering why I post this and actually so far on top of this thread. As you can read above, I recognise maximum privacy as my centre of gravity (COG) i.e. everything needs to be done to defend the COG. Or in other words, without all the steps below, I wouldn’t be able to install and use some of the applications i.e. tools to decrease the drainage of my battery. The following measures and considerations are therefore the prerequisite to continue further.
Prevent Google's and other applications from "calling home” by controlling access to WiFi, mobile data (including roaming), or VPN through “AFWall+ (Donation)” and control effectiveness through Network Log.
EDIT (2016-11-18): Google is no longer an issue as I'm "GApps free" for some days, and I'm extremely happy with the performance of my system. If you are interested in more information please search this thread for "GApps free".
Limit all unnecessary use of services and broadcast receivers not only in support of privacy but also “to save fuel” e.g. by “MyAndroidTools”. As an example, here’s a link to one of my posts in a different thread, where I showed how to manipulate some broadcast receivers used by “Google Play Services” in order to decrease its wakelocks.
If using MM+ control of all permissions in the ROM settings granted to the installed applications including system applications. In the ROM privacy settings, by default don’t allow any application including system applications access to your private data; just grant this permission on a strict case-by-case policy if absolutely necessary. Check in the advanced privacy settings if the granted permissions correspond with your objectives. Use AppOpsXposed for additional implementations (refer to post #7).
XPrivacy - The ultimate, yet easy to use, privacy manager by @M66B. Actually, I deem XPrivacy to be the most powerful tool on an Android device to protect privacy. XPrivacy can only run on devices with an installed Xposed framework. XPrivacy doesn’t control permissions an application gets granted but is able to spoof all data that are made available to an application or are requested by it. The advantage of this method is that the application itself “believes” it’s correctly functioning whereas denial of a requested permission quite often leads to a force closure of the application.
XPrivacy isn’t only extremely powerful but also highly complex albeit easily to use from my point of view if you familiarised yourself sufficiently; however, this takes a bit of time but it’s the effort worth. And M66B has provided a very detailed user manual and FAQ tutorial.
And just to reiterate: Without the mentioned measures, I would personally never have installed some applications; to name them I leave it with your imaginations.
Remark: If someone decides to go for one or all of the mentioned applications please consider to use the donation versions (if available) or to donate to the developers in order to support them and the further development!
EDIT (2017-06-11): Due to the (hopefully only temporarily) non-availability of Xposed for Nougat, I had to terminate the utilisation of XPrivacy i.e. to try to use my brain more intensively. It's a pity.
If interested in Privacy, these two posts might be interesting to you: Post #64 and post #66.
Better Battery Stats
For me, it’s was immediately obvious that I needed to know how and what is when draining my battery before I could commence reducing the drainage. In order to monitor drainage of the battery, I finally learnt about [APP][2.1+][06 Sept. - V2.2RC3] BetterBatteryStats (BBS) by @chamonix.
BBS serves my personal requirements the best; the application is well maintained and supported by a really active XDA thread. BBS is also able to run on non-rooted devices; however, some modifications via ADB are required. As an example, I attached a BBS log but please be aware it isn’t really informative at all because I used the phone while logging was running. Clear guidance is in this thread [GUIDE] 0% [0.0%/h] Idle Battery Drain on Stock ROM (XPosed & Amplify Required!) of @Celestial Fury how the BBS log must be taken in order to provide valuable information for a diagnostic assessment of your battery’s drainage, literally it has to be an idle log. It’s also very helpful to establish first baselines for your device and its current battery i.e. for you to known how much is the battery draining even with the phone switched off and the next time when it’s not transmitting/receiving at all (i.e. in airplane mode).
EDIT (2017-06-08): From my point of view, this procedure by @Davey126 is the best way to achieve a suitable dump file.
Just for completeness: Besides the log (dump file), BBS is able to provide you simultaneously with a logcat and dmesg file. You can retrieve the logs by pressing on the "triangle sign" located in the middle between the refresh and the menu symbols (see screenshots).
EDIT (2016-10-13): Idle Dump attached. Drainage of 1.5%/h i.e. a theoretical battery duration of slightly more than 60 hours, which is fully in line with my given objectives, especially under consideration that neither K-9 Mail and ChompSMS nor Signal are hibernated. From my personal evaluation and conclusion - however, I'm happy to receive experts' opinions, nearly no partial wakelocks but the "standard" (at least from my point of view) kernel wakelocks. As you see at post #1, my kernel's settings are a fair compromise between battery savings and performance. I haven't had any frozen screen or unintentional reboot for month, which is equally important to me as a good battery duration. I doubt that I'm able to further minimise kernel wakelocks. Final remark: Within our home WiFi network, the phone has a fixed IP address assigned respectively reserved.
EDIT (2016-10-17): If you experience issue with "net scheduler wakelock" maybe my post here is interesting to you?
EDIT (2016-10-18): Again thanks to @Wood Man as already so often (eventually I believe he knows the whole XDA by heart) I've become aware of another thread dealing with "net scheduler" by @spencetj. Maybe this helps you in case of any problems e.g. this workaround.
Greenify
Greenify supports my objectives by “hibernating” most of my installed applications. The screenshots below are supposed you to show you the applications, which I haven’t “greenified”. What Greenify does respectively is supposed to achieve can be taken from the XDA threads. Please be aware that the thread regarding [APP][4.1+] Greenify v2.9 Final (Updated on Aug.1) has been closed by @oasisfeng; instead he opened this new one: [BETA] Greenify 2.9.5 beta 3 (Sep. 21, 2016) [BETA]. Please check the Greenify Forum for applicable threads.
Further guidance, actually the one I initially used, is also available in this guide: [GUIDE][26-07-2016]Extreme Battery Life Thread(Greenify+Amplify+Power Nap) by @v7.
EDIT (2019-01-02): Meanwhile, hibernation on Oreo and later seems to work nearly perfectly that Greenify is probably unnecessary in conjunction with these Android versions. However, no own personal experience as our devices are still and will remain on Nougat.
Amplify
By the use of Amplify, I manipulated wakelocks, alarms, and services connected to my installed applications. Using Amplify probably requires the most manual input of all other mentioned applications (except maybe MyAndroidTools and/or AppOpsXposed) but the outcome is tremendous in my opinion.
Amplify is available via this thread [Mod][Xposed] Amplify - Battery Extender - Control alarms, services, and wakelocks by @cryptyk who also nicely explains in his thread what wakelocks and alarms are.
My screenshots below (zipped due to their amount) are supposed to provide an impression, which wakelocks, alarms, and services I limited by Amplify; however, it’s a pity I can’t show you the exact settings for each one of them. Till today, I’ve been unable to figure out how to export or save my settings of Amplify.
EDIT (2016-10-12): Additionally, the attached xml-file contains my current Amplify limitations for those interested. I found it thanks to this post by @Sam Nakamura and the hint to it by @Davey126.
EDIT (2016-10-27): For completeness, I must mention that some highly experienced users e.g. @Davey126 are questioning the let's call it effectiveness of Amplify and from my understanding seem to achieve less drainage without the use of Amplify. If interested in these conversations I suggest to search for respective posts (e.g. by @Davey126) relevant threads. Some of his very valuable thoughts and paradigmatic attitude can be retrieved here.
In the very beginning, I initially took the settings suggested at [GUIDE][26-07-2016]Extreme Battery Life Thread(Greenify+Amplify+Power Nap) by @v7 but in turn continued to modify them more and more. Meanwhile, all Google Play Services related wakelocks and alarms are limited, by the way without any problems for me or my device; however, remember how limited my intended use of Google crap is (post #1).
@Celestial Fury provides very helpful guidance in his thread [GUIDE] 0% [0.0%/h] Idle Battery Drain on Stock ROM (XPosed & Amplify Required!) “[GUIDE] 0% [0.0%/h].
If you use the powerful XDA search engine it’s going to drag you to other valuable, sometimes specialised posts e.g. to this one: Getting rid of wlan_rx_wake wakelocks by @laxor.
EDIT (2016-10-31): Just in order to gain some own experiences, I uninstalled Amplify three days ago after resetting to its defaults. My intention was to observe battery drainage of my system without a running Amplify; everything else remained unchanged.
Observation: Within the two days, the system had higher battery loss of 1.5%/hour during idle without an installed Amplify compared to the values before with the running Amplify.
EDIT (2016-11-16): For two days now I'm GApps free!!! System is running thousand times smoother, fixing the location is very fast even without GPS, blanketstore does what it's supposed to do, and in a few days I'm going to observe my battery drainage more closely; just this morning resetted my Amplify statistics.
But talking Amplify: Obviously due to the lack of the original Google Play Store, it doesn't recognise my donation anymore i.e. no pro-features available and by this now useless to me. Most likely, I'm going to uninstall Amplify having also in mind that some very experienced guys like @Davey126 doubt its necessity anyway.
Alternatively, I hope that @Paget96 is eventually forking Amplify to his great application L SPEED.
Davey126 said:
FYI - I am Amplify free on most of my devices and have profited from reduced maintenance (monitoring/tweaking/optimising blocks) and undesirable side effects that often manifest in subtle ways. In some cases I accepted a modest increase in drain rates while still enjoying overall performance that ranks in the top 20% based on values reported here and similar threads. All day battery life is a must; no compromises there. Arguably drain rates improved a bit with the removal of Amplify but hard to isolate (hint: reset stats on occasion and observe results with no other changes). I do have Amplify running on a couple of older devices that rely on stock ROMs and tight Google Play Services integration. I find a minimal configuration works best with carefully selected conservative blocks (items/durations) along with a weekly stat reset.
Amplify continues to be a fine (albeit stagnant) tool with no apparent equal. It is the right solution for many who experience excessive battery drain and/or wake time due to unconstrained alarms/wakelocks. I prefer to go after these pups at the source which mitigates the need for Amplify.
Click to expand...
Click to collapse
EDIT (2017-04-14): A few weeks ago, I decide to no longer use Amplify as @Davey126's philosophy quoted above and below makes sense to me. Meanwhile, I'm able to fully concur to his deductions and conclusions.
Davey126 said:
I'm certainly no expert but take a different approach to wakelock management after spending am embarrassing amount of time with Amplify and similar tools. I don't limit anything that does not contribute to unwanted wake time and associated battery drain. That reduces the number of candidates from hundreds to a handful. From there I target the app/service/function vs going after wakelocks. For example I disable Firebase Analytics vs limiting/blocking the associated WLs. Currently enjoying 0.2%/hr idle drain will LTE, WiFi and location service on 7x24. Haven't used Amplify in months. Greenify and native Doze are my power management tools of choice on Android 6 w/Xposed. Also use MyAndroidTools and SD Maid to rein in a few rogue services and broadcast receivers. The rest is pure stock.
Bottom line: the vast majority of wakelocks are benign. It's the receiver that determines what actions, if any, will be taken.
Click to expand...
Click to collapse
Power Nap
Please allow me to phrase from [GUIDE][26-07-2016]Extreme Battery Life Thread(Greenify+Amplify+Power Nap) by @[I]v7[/I], as I couldn’t explain it better: “Power Nap for Xposed is the SONY's stamina mod for non-Sony devices. When your screen is off, Power Nap maximizes your device's deep sleep time by stopping services, alarms and wakelocks from waking the device when the screen is off. You can get notification from the apps you've whitelisted.” The application itself is still available here:; however, the corresponding XDA thread [MOD][APP][XPOSED][4.1+] Power Nap for Xposed - Sony's Stamina Mode for all devices! by @waylaidwanderer currently seems not to be very active because waylaidwanderer didn’t contribute since nearly April 2015 anymore. Anyhow, the application does its job from my point of view, and I amended this post by some screenshots of my applications on the whitelist.
EDIT (2016-10-22): @waylaidwanderer is back on air.
EDIT (2016-11-03): I was wondering if PowerNap really has an influence on the battery drainage of my device. For this reason, I uninstalled PowerNap and observed the power consumption for about two days. Attached is last night's idle dump. Actually, I wasn't able to detect any difference to the times when PowerNap was installed. I know my device is more than idling when asleep but this is due to my personal objectives; however, even without PowerNap I got a drainage of (in my opinion) only 1.1%/hour. My decision is now: I don't re-install PowerNap 'cause I don't require applications I don't benefit from in some way - less apps, much better.
AppOpsXposed
AppOpsXposed is a permission manager on Android, and by that you’re also able to deny permission to “keep awake” of e.g. Google Play Services, Google Services Framework, and other applications; However, I again suggest to look into the recommendations at [GUIDE][26-07-2016]Extreme Battery Life Thread(Greenify+Amplify+Power Nap) by @[I]v7[/I]. Actually, I used AppOpsXposed to re-check and to modify my advanced privacy settings of the ROM if required.
The application is available via its thread [Xposed][MOD][1.30.3] AppOpsXposed - AppOps for 4.3+ “[Xposed][MOD][1.30.3] by @caspase.
Spare #1
Spare #2
Spare #3
Wow and again wow!! :good: Congrats and many thanks for the time you spent
and the effort you did for such a contribution, the thread and the posts.
And also thanks for what you do and did for our beloved i9305 in this thread and all in all the other threads you participate. Thanks!! :good:
rodman01 said:
Wow and again wow!! :good: Congrats and many thanks for the time you spent
and the effort you did for such a contribution, the thread and the posts.
And also thanks for what you do and did for our beloved i9305 in this thread and all in all the other threads you participate. Thanks!! :good:
Click to expand...
Click to collapse
I'm surprised how many thanks you had available. Getting slightly embarrassed now; however, I believe it's my duty to share my experiences like so many others do on XDA. I learnt incredibly much from them. Superb community.
Anyhow, I not only guess - I know as soon as my wife left the hospital and is back home, I won't and actually don't want to spend the same amount of time at XDA as I did in the past.
You are welcome and all my best to and for your wife and you. Enjoy your life together and when she is back home and you find the way back to xda from time to time, we would appreciate it.
Wow, great thread! I'll be following this closely as I can only get 1.5 hours of SOT max with my current setup.
thanks man....apreciate
carlitobahsoun said:
thanks man....apreciate
Click to expand...
Click to collapse
If you like it I don't mind you'd hit the thanks button in the lower right corner of the OP and/or the post(s) helpful to you.
rodman01 said:
You are welcome and all my best to and for your wife and you. Enjoy your life together and when she is back home and you find the way back to xda from time to time, we would appreciate it.
Click to expand...
Click to collapse
You won't definitely lose me. I get so much out of XDA and its great community; you made such a great tool out of my device, and I want to see RR "N" (despite not knowing if or when I convert - RR v5.7.4 Sammy is running so smoothly. Shall I really change a well running engine?)
limjh16 said:
Wow, great thread! I'll be following this closely as I can only get 1.5 hours of SOT max with my current setup.
Click to expand...
Click to collapse
I'm convinced I'm going to further decrease my battery's drainage as soon as I'm able to modify my objectives: No requirement for 24/7 framework operations (calls, text messaging, email, messenger). And this will occur when my wife is returning home.
Well executed write up with a nice balance of general guidance and specific detail. Thanks for sharing your experiences; should prove a helpful starting point for those seeking tighter control and improved battery life from their devices.
Update of OP
OP Updated: Amended post #3 by an idle dump from BBS, and amended post #5 by my Amplify settings.
I hope both is interesting to check.
Update of Post #3
Added a remark regarding "net scheduler wakelock" to post #3.
EDIT (2016-10-18): Updated post #3 thanks to @Wood Man I've become aware of another thread dealing with "net scheduler" by @spencetj.
Gave all my thanks for today
Great guidance, hope i can improve my batterylife and SoT
I already followed most threads you suggested but this one sums up everything very nice and easy
Hello all! I'm sure most of you are familiar with Google Play Services, the base of Google's Android framework and the brains behind all the Google things you do on your phone. Less of you, however, might also know that Play Services is notorious for being a beast of an application that no one truly knows the function of.
Below here is a rough explanation of Play Services from what I know about it. You can skip this if you already know and move on to the bread and butter of this post.
Play Services is proprietary software, meaning that its source code is not available to the public. All of Google's apps are proprietary like this as well. While developers like Chainfire have legitimate reasons to close off their app source code so others don't steal it, and so does Google, it is extra worrying from a company that makes a profit off of collecting userdata. Many people, including me, do not trust Google with our data, so we try to avoid their products as much as possible.
I thought that it would be nice to create a megathread of sorts with various users' suggestions on how to subvert the constant surveillance of Play Services, while also attempting to maintain the useful functionality of it. Below are some of the primary methods that I have thought of, and that I and some others have tried:
LineageOS/CyanogenMod Privacy Guard - If you are using LineageOS or any derivative thereof, you can go to Privacy Guard and deny certain permissions from Play Services. I and another user have denied permissions from Play Services without side effects, but your mileage may vary. @javelinanddart said on Reddit that Privacy Guard does indeed block permissions from Play Services and other system apps, so rest assured that Privacy Guard actually does something rather than being a placebo.
XPrivacyLua - This is an Xposed module that feeds false data to apps rather than blocking it entirely. I haven't tried this method myself, but the XDA post I linked above reports that XPrivacyLua works, even in tandem with Privacy Guard.
microG - microG is an open-source alternative to Play Services. It emulates many key functions of Play Services - push notifications, location services, etc - without the data collection running alongside such functionality. To clarify, this is a full replacement for Play Services, so you would flash a microG package instead of a GApps package. There are lots of bugs, though, even admitted by the developer. If you want to learn more, I suggest you visit the XDA thread for it, or view the implementation progress for various pieces of functionality.
There is nothing else that I know of, so if anybody knows of another viable method or can provide their own experiences with the above ones, your contributions would be appreciated by me and the rest of the privacy community.
Thanks for thread.
My only reason to use custom ROM is because they are GApps-free. In nearly every other aspect stock ROMs are better. Phones without good custom ROM I simply setup without Google account and install f-droid and yalp stores.
Another idea:
Imagine: Google is not as evil as we think: there are many privacy related settings in your Google account. You can login with a web browser and try through all these settings - and hope.
Device is a Samsung i9305 with RR-N-v5.8.5-final, Magisk v16.0, XPosed, XPrivacyLua, microG (via NanoDroid). No genuine Google services; Google Play Store is the one and only Google application installed.
I hope it suits into this thread (thanks very much for creating it!), and I'd like to share my settings. Please refer to the screenshots; I think it's self-explaining where they where taken from.
Actually no restrictions to microG, only to Play Store.
Remarks: µG has no restrictions in the firewall (AFWall+ Donation Beta); Play Store only granted internet access via WiFi and VPN. Just for completeness; running a RaspberryPi in the home network with Pi-Hole installed and acting as the DNS-server in the network. Unless using the home network i.e. using a foreign WiFi network or mobile data, ALWAYS establishing my own secure VPN to my RaspberryPi (with PiVPN installed) via OpenVPN and again the Pi acting as the DNS-server. If interested in further details please refer to this thread.
Thanks for this.
I was considering asking for a forum section here devoted to privacy, but it doesn't seem like a popular subject here. (After all, most of the people who have already picked the most snoopery OS in the world could be assumed to be not particularly worried about privacy. ? )
I come from a different motivation: the hope that by using a somewhat hackable OS, one can theoretically modify it in ways to achieve one's objectives, including privacy. But the last few years have made it rather clear that the Big G is working determinedly to foil such efforts.
Lately that seems to take the form of pushing more and more essential services into the Gplay frameworks, and deprecating perfectly working things like GCM in favor of intertwining it with Firebase, which may saddle us with that analytics data vacuum in order to get another essential service, push notifications.
Re: revoking permissions from Gplay frameworks, I feel like Google's determination to get their hands on data by hook or by crook (eg their ignoring of user preferences to disable various radios and enabling them in the background anyway, to track location and such) means they will quite possibly circumvent these preferences at some point as well.
As I mentioned in another thread I've experienced various problems in the past when I tried to aggressively restrict perms on the Gplay services using CM/LOS Privacy Guard, but perhaps some of that came from choosing interactive restriction prompts rather than blanket revoking. I do know that so many essential services are tied-into the Gplay frameworks these days that blocking tons of perms will inevitably cause breakage of some things depending how you use your device.
Jrhotrod said:
...
There is nothing else that I know of, so if anybody knows of another viable method or can provide their own experiences with the above ones, your contributions would be appreciated by me and the rest of the privacy community.
Click to expand...
Click to collapse
Due to your request above, please allow me to draw your attention to two threads by me. In these threads I tried about one and a half year ago to initially capture but also to update how I believe to have enhanced the battery duration, privacy and security of my GT-i9305 and how I went for a GApps-free device with microG.
Over the time until today, some of the described implementations, applications and measures became absolete or were replaced by others (e.g. using NanoDroid - or Nanomod as it was called in the beginning, since it has come out). Some changes occured due to the step from Marshmellow to Nougat or the non-availabilty of the official Xposed framework for Nougat in the very beginning. However, over all the time I've tried to maintain both threads updated and amended but currently not to much occuring on that frontline, probably because I've received a privacy status on our devices that obviously satisfies me in my personal opinion.
Oswald Boelcke said:
Due to your request above, please allow me to draw your attention to two threads by me. In these threads I tried about one and a half year ago to initially capture but also to update how I believe to have enhanced the battery duration, privacy and security of my GT-i9305 and how I went for a GApps-free device with microG.
Over the time until today, some of the described implementations, applications and measures became absolete or were replaced by others (e.g. using NanoDroid - or Nanomod as it was called in the beginning, since it has come out). Some changes occured due to the step from Marshmellow to Nougat or the non-availabilty of the official Xposed framework for Nougat in the very beginning. However, over all the time I've tried to maintain both threads updated and amended but currently not to much occuring on that frontline, probably because I've received a privacy status on our devices that obviously satisfies me in my personal opinion.
Click to expand...
Click to collapse
Wow, this is really great! Very high-quality thread.
Will add to OP later today
I apologise for the double post (original in my thread here) but I guess it also suits in this thread.
Found the below quoted post by @jawz101 in the XPrivacyLua thread here. Pretty interesting, and therefore I like to share:
Looking around on Data Transparency Lab website http://datatransparencylab.org/ - they fund grants for research in privacy stuff.
...I found an app called AntMonitor, an academic research project that does a MITM SSL cert + local VPN to look at sensitive traffic - even that which is encrypted. https://play.google.com/store/apps/d...it2.anteatermo
Anyways, it shows some apps trying to send my gps coordinates even though it doesn't have Android permission. Like, my coordinates are actually attempting to be sent encrypted to a destination. XPrivacyLUA doesn't trigger so I can only assume they grab my coordinates in a way that circumvents the traditional Android permission model.
To test, just try the app and open a few apps. I think it's apps with the Facebook graph API that is maybe doing it.
If you like ANTMonitor another app that does an SSL cert+ VPN is Lumen Privacy Monitor- a project by Berkely, but it doesn't seem to detect raw coordinates like ANTMonitor does.
Click to expand...
Click to collapse
However, I suggest to also follow the discussion/conversation between jawz101 and M66B, which has developed after this post.
Oswald Boelcke said:
Found the below quoted post by @jawz101 in the XPrivacyLua thread here. Pretty interesting, and therefore I like to share:
However, I suggest to also follow the discussion/conversation between jawz101 and M66B, which has developed after this post.
Click to expand...
Click to collapse
This is certainly an important discovery, thanks for the news.
Now for the sidenote that's 10x longer than the main comment. ?
One of the key issues I have with the various "privacy tools" is trying to figure out whether or not I trust all these entities that produce these diagnostic things to not be a solution worse than the problem when it comes to possessing and safeguarding my sensitive personal data.
It's getting to the point where I'm no longer enamored of giving *anyone* access to such stuff if I can help it, no matter *who* they are.
Even if they're not lying about their intentions and their commitment to security/privacy, there are still matters like carelessness/incompetence and targeted attacks to worry about.
@Exabyter: You're statement and expressed concerns are abolutely correct. Nothing to add except that I wouldn't limit it to "privacy tools" but especially include all applications that require root (and get it granted by the user) or all Magisk and Xposed modules. The latter should definitely concern.
My personal decision:
I'm not willing to trust anybody from the very beginning but I'm willing to trust single persons, groups or agencies. I've developed my own, private criteria, to which I stick but I've also admit the final decision isn't always based on rationality but also a lot on my feeling (in my stomage).
I don't held any confidential data on my device but privacy related ones, and I don't use my device for any kind of banking, shopping or payments.
I consider to use tools, modules and applications if their functionality rests within my defined specifications for the use of my device. Then I go for "the shopping tour" while I try to look into the details of the tools under closer examination, which includes where is it from, who's the developer etc.
I'll continue with the measures already described in one of my threads.
Oswald - I think we have largely similar stances on such things. In my case I will sometimes sway towards the pragmatic over the pedantic when the pedantic involves so many inconveniences that the tech becomes more of a burden than a help to me.
For example, I really don't like the idea of 3rd-parties keeping data pertaining to my daily geographic movements, but I also use several tools and services that by their nature rely on location data which could in some cases end up in the hands of parties I'd rather didn't have access to it. So I have to regularly weigh the apparent cost/benefit of such services and there are certainly some of them which have a high enough value to me that I willingly lower my default "protection level" in order to keep the other benefits of such tools/services.
Certainly microG is an important tool in that toolchest as it has a major disruptive impact on some of the most common ways Google and other parties snoop on users. But some of its imperfections also threaten to keep me from my ultimate goal of carrying a single phone which performs all the tasks I need to accomplish with it without undermining my privacy in a major way. (And ultimately, my freedom and agency as a citizen in a nominally and allegedly "free and democratic society", which is the actual "big picture" problem with privacy incursions in general IMHO)
I have spent several years now, with varying degrees of effort and success, trying to come up with a hardware/software solution to this problem, and I've never reached a point where I'm fully satisfied with the results. The fact that I am still carrying several mobile devices with me everyday is proof enough that I haven't achieved my objective in this regard and it gets tiring. As does all the time spent on venues such as XDA, researching, discussing and keeping-up with all the relevant issues, not to mention the large amount of time spent tinkering with HW/SW in order to keep all the special measures working. (And after we finally get things working more or less the way we want, we are faced with the particularly customized hardware wearing out, becoming unsupported, 3rd-party ROM and other compatible and necessary software being abandoned/deprecated, and so on and so forth.)
Truth to tell I'm a bit bitter about the amount of time/energy I have to spend to achieve something which should have been part of the mobile platforms in the first place. The current de-facto mobile platform duopoly certainly doesn't help matters.
---------- Post added at 03:39 PM ---------- Previous post was at 02:57 PM ----------
Now that I've gotten that philosophical rant out of the way ? ...
So as far as technical specifics:
microG of course is a big help as it either neuters or removes many troublesome anti-privacy vectors. For example, at the present time it does not support Firebase Analytics at all, which means (as far as I can tell) any app that expects to get telemetry on users via Firebase Analytics will not get anything if the app user's device is Gapps-free and using microG instead. (It remains to be seen if adding Firebase Cloud Messaging capability to microG will negate this presumed benefit. Cynics like myself are inclined to think one of Google's key objectives in deprecating Google Cloud Messaging and rolling push notification frameworks into Firebase instead was specifically to undermine the ability of users to avoid/circumvent Firebase Analytics)
XprivacyLUA looks interesting and is on my list to test. I found its predecessor Xprivacy to be an extremely tedious and labor-intensive option so I never seriously pursued it after my initial testing.
There are various tools I find handy to help get a sense of how dangerous certain apps may be to privacy. Here are a few:
AppBrain Ad Detector
https://play.google.com/store/apps/details?id=com.appspot.swisscodemonkeys.detector
Addons Detector
https://play.google.com/store/apps/details?id=com.denper.addonsdetector
Checkey (also on f-droid)
https://play.google.com/store/apps/details?id=info.guardianproject.checkey
Applications Info (also on f-droid)
https://play.google.com/store/apps/details?id=com.majeur.applicationsinfo
Permission Friendly Apps
https://play.google.com/store/apps/details?id=org.androidsoft.app.permission
I got a good Custom rom overview from this post, especially the google spreadsheet: https://forum.xda-developers.com/oneplus-6/how-to/custom-rom-t3867290
I looked into a coupe of those, and found some questioable features. For example: Havoc OS lists something like wather info on lock screen. This made me think about where this functionality would get the telemetry for my location.
TLDR; Are there any Custom Roms that are especially focused on user privacy or with this concern at least in mind?
In general I know about the custom rom Replicant but they only support very old smartphones. I decided that the Oneplus 6 is the perfect phone for me I also want to find the perfect custom rom.
If searched on google and the only the other os showing up is lineage. Other than beeing open source what would be the difference to lets say aosp extended regarding special features and privacy?
I won't be using gapp and i am still thinking about microg. Since Google is such a great company I wont get notifications without going though their ****ing gcm unless sacrificing significant battery life (more info: https://www.reddit.com/r/fossdroid/comments/9ayrgc/privacy_on_gcm_microg/ ).
Hi, I think when it comes to privacy, regular custom ROMs have little impact. As long as you're not using OOS or a port (like MIUI), all ROMs should be pretty good, as long as you don't install gapps.
Lineage has a good reputation, it's well known and they made a lot of basic apps so you don't need to rely on others (they're often based on older AOSP apps). LOS also comes with Privacy Guard, which is similar to the default Android permissions manager, but with a few extra options, including a very basic firewall. If you want to use microG, you have to go for a special edition that you can find here: https://lineage.microg.org/
But other ROMs are fine as long as you have the proper apps installed and a proper setup overall. You can check my thread which is related to microG but also privacy: https://forum.xda-developers.com/oneplus-6/how-to/guide-microg-oneplus-6-source-ligthway-t3874469/
Depending on your current knowledge, it's mostly a lot of reading about what apps you can use, what browser you should use, what firewall, what ad/tracker blocker, etc.
If you're on telegram, I'd recommend you join @nogoolag , it's full of useful notes about what apps to use, what settings are ideal, infos related to VPNs, etc.
EDIT: about weather in custom ROMs: you can usually very easily disable the service or even remove the related APKs, so it shouldn't be a criteria imo.
@Tomatot-
Thank you very much for you awesome reply. Your thread about microg helped me a lot. I will follow your guide there.
Material Files
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
An open source Material Design file manager, for Android 5.0+.
https://github.com/zhanghai/MaterialFiles
Downloads
Google Play
F-Droid
GitHub releases
Screenshots
Features
Open source: Lightweight, clean and secure.
Material Design: Like the good old Cabinet with attention into details, and optional MD2 style.
Breadcrumbs: Navigate in the filesystem with ease.
Root support: View and manage files with root access.
Archive support: View, extract and create common compressed files.
Themes: Customizable UI colors and night mode.
Linux-aware: Like Nautilus, knows symbolic links, file permissions and SELinux context.
Robust: Uses Linux system calls under the hood, not yet another ls parser.
Well-implemented: Built upon the right things, including Java NIO2 File API and LiveData.
Why Material Files?
Because I like Material Design, and clean Material Design.
There are already a handful of powerful file managers, but most of them just isn't Material Design. And even among the ones with Material Design, they usually have various minor design flaws (layout, alignment, padding, icon, font, etc) across the app which makes me uncomfortable, while still being minor enough so that not everybody would care to fix it. So I had to create my own.
Because I want an open source file manager.
Most of the popular and reliable file managers are just closed source, and I sometimes use them to view and modify files that require root access. But deep down inside, I just feel uneasy with giving any closed source app the root access to my device. After all, that means giving literally full access to my device, which stays with me every day and stores my own information, and what apps do with such access merely depends on their good intent.
Because I want a file manager that is implemented the right way.
This app implemented Java NIO2 File API as its backend, instead of inventing a custom model for file information/operations, which often gets coupled with UI logic and grows into a mixture of everything. On the contrary, a decoupled backend allows cleaner code (which means less bugs), and easier addition of support for other file systems.
This app doesn't use java.io.File or parse the output of ls, but built bindings to Linux syscalls to properly access the file system. java.io.File is an old API missing many features, and just can't handle things like symbolic links correctly, which is the reason why many people rather parse ls instead. However parsing the output ls is not only slow, but also unreliable, which made Cabinet broken on newer Android versions. By virtue of using Linux syscalls, this app is able to be fast and smooth, and handle advanced things like Linux permissions, symbolic links and even SELinux context. It can also handle file names with invalid UTF-8 encoding because paths are not naively stored as Java Strings, which most file managers does and fails during file operation.
This app built its frontend upon modern ViewModel and LiveData which enables a clear code structure and support for rotation. It also properly handles things like errors during file operation, file conflicts and foreground/background state.
In a word, this app tries to follow the best practices on Android and do the right thing, while keeping its source code clean and maintainable.
Because I know people can do it right.
Nautilus is a beautifully-designed and user-friendly file manager on Linux desktop, and it's fully Linux-aware. Phonograph is an open source Material Design music player app (which I've been using for years), and it has just the right Material Design and implementation.
So, it's time for yet another Android file manager.
License
GPL-3.0-or-later
Code:
Copyright (C) 2018 Hai Zhang
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>.
XDA:DevDB Information
Material Files, App for all devices (see above for details)
Contributors
dreamingincode
Source Code: https://github.com/zhanghai/MaterialFiles
Version Information
Status: Stable
Current Stable Version: 1.0.0
Stable Release Date: 2019-12-02
Created 2019-12-08
Last Updated 2019-12-09
Reserved
Reserved
Reserved
Thank you for opening this thread on XDA. 謝謝 ！
I was following this on GitHub since I saw the application on F-Droid.
Stunning 1.0 release !
A feature request I think I haven't seen yet on GitHub's issues; would it be possible to implement full long filenames ? Currently they get truncated with a "..." and some file listings show the same partial filename for all items.
dreamingincode said:
Reserved
Click to expand...
Click to collapse
Tried the app.Very nice app for first release and its open source(cool)
Requesting for adding cloud (drive,mega) file management feature... Thank u
Ultramanoid said:
Thank you for opening this thread on XDA. 謝謝 ！
I was following this on GitHub since I saw the application on F-Droid.
Stunning 1.0 release !
A feature request I think I haven't seen yet on GitHub's issues; would it be possible to implement full long filenames ? Currently they get truncated with a "..." and some file listings show the same partial filename for all items.
Click to expand...
Click to collapse
You can copy the full name in the "Properties" dialog. I intentionally put the ellipsis in middle in hope that it can help distinguishing different files with numbers at end, etc. Unfortunately the file name cannot be two-line/multi-line because fast scrolling requires every item to be of fixed height
thisisarjun said:
Tried the app.Very nice app for first release and its open source(cool)
Requesting for adding cloud (drive,mega) file management feature... Thank u
Click to expand...
Click to collapse
See https://github.com/zhanghai/MaterialFiles/issues/95 or https://github.com/zhanghai/MaterialFiles/issues/148
dreamingincode said:
You can copy the full name in the "Properties" dialog.
Click to expand...
Click to collapse
Well, thanks, but that is not really a solution. In a list with dozens or hundreds of files it's not realistic to check each single filename, dozens or hundreds of times.
Organizing photos or sound files, I have listings with hundreds of files that all seem to have the exact same name.
Sorry to hear it is not possible. ( You could check Ghost Commander to see it implemented in another open source file manager. FX, MiX, not open source, but also with threads in XDA, or the venerable Total Commander, all can show full filenames. Linux file managers as well. )
Well, good luck with the project.
Ultramanoid said:
Well, thanks, but that is not really a solution. In a list with dozens or hundreds of files it's not realistic to check each single filename, dozens or hundreds of times.
Organizing photos or sound files, I have listings with hundreds of files that all seem to have the exact same name.
Sorry to hear it is not possible. ( You could check Ghost Commander to see it implemented in another open source file manager. FX, MiX, not open source, but also with threads in XDA, or the venerable Total Commander, all can show full filenames. Linux file managers as well. )
Well, good luck with the project.
Click to expand...
Click to collapse
I tried MiX with full file name enabled, and fast scrolling indeed became broken :crying:
dreamingincode said:
I tried MiX with full file name enabled, and fast scrolling indeed became broken :crying:
Click to expand...
Click to collapse
I'm not sure what fast scrolling means, but at any rate if all filenames look exactly the same, no operation is possible. Here's an example comparing with FX.
Ultramanoid said:
I'm not sure what fast scrolling means, but at any rate if all filenames look exactly the same, no operation is possible. Here's an example comparing with FX.
Click to expand...
Click to collapse
Oh, fast scrolling means if you drag the scrollbar, the scrollbar actually follows you so that you can scroll through the entire content quickly. That requires knowing the item height without laying all of them out, so dynamic item height will most likely break it.
Maybe I should consider adding an option to make all items take the height of a two-line file name. Created https://github.com/zhanghai/MaterialFiles/issues/205.
Btw I also happened to listen to that song, a really beatiful one It has been in my personal music library for years, the piano arranged version.
dreamingincode said:
Oh, fast scrolling means ... the piano arranged version.
Click to expand...
Click to collapse
I understand. Thank you very much for considering it. I had been testing the F-Droid build and this was my only serious problem. It is a really solid file manager.
Yes, I have the piano version too. It is a good soundtrack. (^^♪
dreamingincode said:
Oh, fast scrolling means if you drag the scrollbar, the scrollbar actually follows you so that you can scroll through the entire content quickly. That requires knowing the item height without laying all of them out, so dynamic item height will most likely break it.
Maybe I should consider adding an option to make all items take the height of a two-line file name. Created https://github.com/zhanghai/MaterialFiles/issues/205.
Click to expand...
Click to collapse
The fixed height schema is malapropos and can be problematic...
Maybe we can refer to how web browsers rendering lengthy web pages.
I checked the 1.0.1 release from GitHub since the F-Droid build is always slower to appear. Very disappointed to see it's loaded with trackers; Firebase, CrashLytics, GCM...
Hopefully the F-Droid build will be clean and without all those things, but still worrisome.
I am also an enthusiastic Android user myself (which is why I built the app) and I do share your concern, but as a developer I also need analytics and telemetry to know how my app works and debug issues, so I hope you could understand it.
Meanwhile, Firebase Crashlytics is one single thing (source), and I didn't use GCM which is for push notifications. So it feels kinda unfair to say the app is "loaded with trackers".
Different people may have different expectations of privacy, and I fully understand it which is why I published the app on F-Droid. F-Droid only allows building from open-source code (Firebase surely isn't open source), and makes it very hard to do otherwise, so you don't need to worry about the F-Droid version. You can check my F-Droid build file to see how nonfree code is removed before build, and the GitHub repo to see the full source code.
Regarding latency of F-Droid build, unfortunately it's a limitataion of F-Droid and I cannot do anything about it. The build file linked above already has the recommended auto update mechanism configured, so we just have to wait one or two days (see the previous link, F-Droid signing needs human intervention) for a new version to be there. You can also download the F-Droid tool to do your own build using the build file if you really want the free version quickly, which I did for once when testing the build file.
EDIT: Didn't see you screenshot. Yes Firebase Analytics and Firebase Crashlytics are two things, but both under Firebase and viewed at the same place, one for analytics and one for telemetry.
dreamingincode said:
So it feels kinda unfair ...
Click to expand...
Click to collapse
Thank you for the reply, and developer myself. But surely much older and missing the era where software was paid with money instead of personal information.
Still won't allow a single tracker on my system on any device. That's one tracker too many. Unusual, I know, but no Play Services, no social data miners, no malvertising, no crash reporters, no trackers, and no internet permission for anything other than the web browser and terminal, period. And if possible, only open-source applications to be able to audit the code.
I understand 99% of users just want convenience, and prefer a "free" pretty application that records everything they write, say, eat, do, and uses it or sells it, than running a clean but ugly Linux binary in a terminal...
Edit : Sorry if it seems I was complaining about the F-Droid delay, I wasn't, I know it's not something you can control.
Ultramanoid said:
Thank you for the reply, and developer myself. But surely much older and missing the era where software was paid with money instead of personal information.
Still won't allow a single tracker on my system on any device. That's one tracker too many. Unusual, I know, but no Play Services, no social data miners, no malvertising, no crash reporters, no trackers, and no internet permission for anything other than the web browser and terminal, period. And if possible, only open-source applications to be able to audit the code.
I understand 99% of users just want convenience, and prefer a "free" pretty application that records everything they write, say, eat, do, and uses it or sells it, than running a clean but ugly Linux binary in a terminal...
Click to expand...
Click to collapse
I'm more of a pratical user for myself, but I agree people should have the freedom to not be tracked. This app is my hobby project created for myself and others, and I surely don't want to track anyone with it, so rest assured.
The source code of this project is free (as in freedom) with GPLv3, and the F-Droid version contains only FOSS code and should be a clean and beautiful app to use. I believe free software should be as good as, or even better than proprietary ones ?
dreamingincode said:
Because I want a file manager that is implemented the right way.
This app implemented Java NIO2 File API as its backend, instead of inventing a custom model for file information/operations, which often gets coupled with UI logic and grows into a mixture of everything. On the contrary, a decoupled backend allows cleaner code (which means less bugs), and easier addition of support for other file systems.
This app doesn't use java.io.File or parse the output of ls, but built bindings to Linux syscalls to properly access the file system. java.io.File is an old API missing many features, and just can't handle things like symbolic links correctly, which is the reason why many people rather parse ls instead. However parsing the output ls is not only slow, but also unreliable, which made Cabinet broken on newer Android versions. By virtue of using Linux syscalls, this app is able to be fast and smooth, and handle advanced things like Linux permissions, symbolic links and even SELinux context. It can also handle file names with invalid UTF-8 encoding because paths are not naively stored as Java Strings, which most file managers does and fails during file operation.
This app built its frontend upon modern ViewModel and LiveData which enables a clear code structure and support for rotation. It also properly handles things like errors during file operation, file conflicts and foreground/background state.
In a word, this app tries to follow the best practices on Android and do the right thing, while keeping its source code clean and maintainable.
Click to expand...
Click to collapse
With no intent to disappoint you... But I'd like you to know:
Being of higher level of abstraction does not necessarily ensure being of higher level of quality...
...what's under the hood may be not much different from another `ls` parser.
And usually... those abstraction layers inevitably introduced some losses in the runtime efficiency of the program.
dreamingincode said:
However parsing the output ls is not only slow, but also unreliable...
Click to expand...
Click to collapse
It doesn't have to be slow... nor unreliable. When properly implemented.
If necessary, you can adapt your own version of `ls` specifically optimized for your specific purpose, to reduce the performance overhead. (though generic `ls` already works well... for most purposes, and usually still faster than calling similar functionalities from the abstraction layer of higher levels)
Indeed anything unfamiliar can be considered unreliable... though `ls` indeed gives consistent output.
dreamingincode said:
...which made Cabinet broken on newer Android versions.
Click to expand...
Click to collapse
I believe the cause is this. (check the adjacent posts too)
Something about Google's whims: the approach towards "No file in the system"... (the exact opposite of the creed of Unix)
dreamingincode said:
By virtue of using Linux syscalls...
Click to expand...
Click to collapse
More accurately, it's calling native Linux applications/libraries through the JNI.
Meanwhile... how's the app's performance in this test? (unfortunately I'm unable to verify on my system due to dependency issues)
gdgsdg123 said:
Being of higher level of abstraction does not necessarily ensure being of higher level of quality...
...what's under the hood may be not much different from another `ls` parser.
And usually... those abstraction layers inevitably introduced some losses in the runtime efficiency of the program.
Click to expand...
Click to collapse
There must be an abstraction to represent files and paths in a file manager written in Java, however you get the file data (via `ls`, Java File or custom native things). Java NIO2 file API is a good abstraction so it's an improvement over bad ones.
It's very diffrent from an `ls` parser in that it doesn't parse the output of an unknown version of a binary, and it doesn't start new processes.
It doesn't have to be slow... nor unreliable. When properly implemented.
If necessary, you can adapt your own version of `ls` specifically optimized for your specific purpose, to reduce the performance overhead. (though generic `ls` already works well... for most purposes, and usually still faster than calling similar functionalities from the abstraction layer of higher levels)
Indeed anything unfamiliar can be considered unreliable... though `ls` indeed gives consistent output.
Click to expand...
Click to collapse
It is unreliable and cannot be properly implemented, because things like newline in file name. In a word, it doesn't provide an option to separate lines with a NUL byte, and thus cannot be reliably parsed. `find` provides such an option as mentioned in the HackerNews thread, but it cannot output all the needed file metadata like `ls` and launching separate processes to retrieve metadata is painfully slower.
It has to be magnitudes slower than JNI because every time it is creating a new process, waiting for it to finish and collecting its output. This will be a huge slow-down comparing to any number of layers of abstraction within Java.
Building and bundling `ls` only solves parsing, but cannot avoid creating a new process every time in any way.
`ls` isn't something completed and untouchable, and it can be inspected, modified and improved. I consulted the source code of `ls` (and various others) in toybox (the AOSP implementation now) and OpenJDK NIO2 implementation before writing my own, not inventing something new.
I believe the cause is this. (check the adjacent posts too)
Something about Google's whims: the approach towards "No file in the system"... (the exact opposite of the creed of Unix)
Click to expand...
Click to collapse
The cause of Cabinet stopped working is unlikely the Scoped Storage work happening in Q and beyond, because it is broken on P. It is showing every file/folder name as `0` which is likely due to modification to `ls` output that added a new column, and Cabinet thought that was where the file name should be.
About the trend in Android towards scoped storage: Rooting itself is against the Android permission system, etc, and is much less supported than raw file access. So as long as root is supported on Android, having a Linux file manager makes sense to me.
More accurately, it's calling native Linux applications/libraries through the JNI.
Click to expand...
Click to collapse
Yes this is the point. Using JNI to call into a custom native library avoids the overhead of creating new processes. However, these JNI calls are simple wrappers around the original Linux syscalls, so I believe it's fine to say that the app is utilizing Linux syscalls (there's no other way of using Linux syscalls in Java).
syscalls.c is the source code for syscall wrappers written in C. Syscalls.java is the Java interface. As you can see, they are merely wrappers around the original syscalls.