This is because from Android Nougat and onward, Chrome cannot read from /data/local/ due to restrictive SELinux permissions – however, it is really quite simple to fix. Some guides on this issue may instruct you to simply change /data/local to /data/local/tmp, however, this does not work with latest versions of Chrome and Chromium – the apps will not even attempt to use the files, unless you are in Debug Mode. Of course, most ROMs are not Debug builds! You could, of course, set Chrome into Debug Mode in your Android’s Developer Options.
Downloads
First, we need to install a Chrome command line file from the Downloads section of this guide, and flash it via recovery – your best bet is in TWRP or another custom recovery. You can also simply download and place it manually (using a rooted file explorer) into /data/local/tmp, but you need to set the file permissions to 755. Lastly you can also do it over ADB, using this ADB command line: However please note that if you use a manual deploy method (root file explorer or ADB method), you will need to manually adjust the scale factor in the “chrome-command-line.txt” file, then rename it to “chrome-command-line”. See this guide’s section on scale factors. In your Developer Options, scroll down to “Select Debugging App”. Choose Chrome, then disable the option “Wait for Debugger”. However, if for some reason Chrome is not available in the Debugging App options, you can force this over ADB using the ADB command: Chrome will now be forced into debugging mode. You can confirm by going into Developer Options again and check under “Select Debugging App”, you should see that Chrome is set. Now launch the Chrome app, go into Settings > Accessibility, and enable the option “Force Enable Zoom”. Now completely kill Chrome (such as via Kill Application), and relaunch it. You should now be in a permanent Desktop mode.
Scale Factors
Since the June 2018 builds for Chrome on Android, it seems they have been making major changes to how the Android version decides which interface method is used – such as whether you’re on phone or tablet. So previously if you were on a phone, you could simply set the scale factor to whatever you desired, and you would still get the mobile interface. However, it seems Chrome now takes force-device-scale-factor into account before making its decision. This means that if you set the force-device-scale-factor to a number too low, it will give you a tabbed tablet style interface. This may be appealing to some, but if you hate it, your only option is to increase the scale factor until it returns to the mobile style interface. You no longer need to make scale changes in increments of 0.25, which is a positive as you can now fine tune things a bit more to get a larger viewport. Some websites may decide what site version you receive by your user agent, but most of them will also look at your available viewport size (typically your screen width). So if you set scale factor too high, you could still end up with the mobile version of a website. In Portrait mode, you may also still receive a mobile version due to restricted width, but by changing to Landscape mode, you find that you receive the Desktop version of the site. So here is a rough estimate of the best scale factors to use to consistently get Desktop sites, based on screen resolution:
720p and below: Choose a scale factor between 1 to 1.25 – if you go up to 1.5, you will most likely start getting mobile websites.1080p: You should use a scale factor of either 1.5, 1.75, or 2. At a scale factor of 2, a good majority of websites will display the desktop version for you, but if you use your device in portrait mode, you may start getting mobile websites due to the restricted width.Higher than 1080p: You should probably stay between 1.75 or 2, but perhaps go higher if you have a 4k screen.
This is all subjective of course. For example, a 5” device with a 1080p screen is obviously not the same as a 10” tablet with a 1080p display. You are going to want to play around a lot with this to find what is most comfortable for you. Things will appear larger with a higher scale factor of course – its basically blowing things up. For example if you had a viewport width of 1000, and you use a scale factor of 2, your viewport is now 500 – but your screen has obviously not shrunk, things are just being displayed to you as if you had a lower resolution screen.
Nintendo sues two major ROM sitesFirefox Monitor: Mozilla Firefox’s New Safety Feature Will Show You…How to Explore FTP Sites with PCManFMHow to Block Bad Sites with “etc/hosts”