Related
// New builds at http://download.cyanogenmod.com/?device=legend[/COLOR]
Always make a nandroid, and flash on your own risk!
Because teamdouche's nightly is more than a month old, I decided to build a nightly myself.
Changelog:
http://cm-nightlies.appspot.com/?device=legend
---
10. feb build:
Everything to "Fix music widget transparency in landscape layout." is included.
http://www.mediafire.com/?udu1gnbnh4dul8d
---
23. jan build:
Everything to "Backport ICS rotation animations to gingerbread (android_frameworks_base)" is included.
http://www.mediafire.com/?ebprbr233gv1b50
---
13. jan build: - the friday 13. edition with Holo theme for ring lockscreen
Everything to "CM: Add p500 (LGE Optimus One) device (android_vendor_cyanogen)" is included.
http://www.mediafire.com/?pu4xfomdzxmvu5e
---
10. jan build:
Everything to "Exchange: calendar sync window linked to email sync window (android_packages_apps_Email)" is included.
http://www.mediafire.com/?9cckq1q24rqb9km
---
4. jan build:
Everything to "init: Let radio user manipulate service properties (android_system_core)" is included.
http://www.mediafire.com/?wb073sdj3b80k5y
---
2. jan build:
Everything to "CM: Add p925 (LGE ATT Thrill 4G) device (android_vendor_cyanogen)" is included.
http://www.mediafire.com/?8qo1rkjc5st21bs
---
23. dec build:
Everything to "Camera: Autofocus camcorder only if needed (android_packages_apps_Camera)" is included.
http://www.mediafire.com/?sze4uat4rl9weob
---
19. dec build: + T9 Dialer
Everything to "Preference to disable bootanimation for faster boot. (1/2 CMParts) (android_packages_apps_CMParts)" is included.
http://www.mediafire.com/?8ka5ouhorodnrzj
---
18. dec build:
Everything to "Fix emergency dialing on Samsung CDMA phones. Tested on Epic 4G, may also help others. DOES NOT FIX VIBRANT. (android_frameworks_base)" is included.
http://www.mediafire.com/?yon4treurcv557h
Nice to see that the Belgian keyboard layout is finally corrected
Just installed it and no problems so far, runs the same as 7.1
An update for HTC Legend, wow ! Thank you dude
Market does not work for me afte update!
stewie01 said:
Market does not work for me afte update!
Click to expand...
Click to collapse
After what update? Market is working fine here
Dialpad : T9 Dialer (android_packages_apps_Contacts) version building right now!
Edit: Up!
Tried to flash the one from 18th december, but CWM failed to verify the package, trying to download new one from the 19th...
ranger4740 said:
Tried to flash the one from 18th december, but CWM failed to verify the package, trying to download new one from the 19th...
Click to expand...
Click to collapse
I haven't encountered any problem while flashing.
can I update without wipe from regular 7.1? tnx
guap said:
can I update without wipe from regular 7.1? tnx
Click to expand...
Click to collapse
I guess so, but make a nandroid!
done
the stock t9 dialer doesn't show dial pad for default... really unuseful to have a t9 dialer (finally!!!) but still having to hold down a button to have the keyboard... that was the main reason to me for upgrade, and because of this I reverted back to my original 7.1 in ~10 minutes... also seemed a bit choppy, unable to use wavesecure, lost all my google apps settings... sounds like a NO for the upgrade with no wipe to me and no time to set all again at this time
thanks anyway
Well I tried this rom also just for this T9 Dialer...
I wiped before flashing so to be sure having a clean system.
Nothing special to mention about the rom itself... It works as the 7.1 does. (well, tested one hour only... Can't say for battery drain or else)
Regarding the dialer... Well, I think I don't get it well.
First, in the parameters, ensure you choose what the dialer will look for: Numbers or name. In my case, names.
Then, typing the numbers shows.... The numbers. the only way I found to get proposal according to the first digits is to go to another tab (contact for instance), and coming back to the dialer tab it will show me the possible contacts I wish to call.
Not very useful, neither practical.
I hope someone will find another way to use it ... More efficiently?
Thank you anyway for the work, mate! Really appreciated!
slovenec88 said:
I haven't encountered any problem while flashing.
Click to expand...
Click to collapse
Hi, thanks, I flashed the one from 18th dec. hung on the HTC boot screen for 10 mins reflashed and turned on signature verification in CWM and failed, downloaded again still no good, downloaded the one from the 19th, working ok, no problems.....
The nightly update seams to work really good, seams to be even more stable than 7.10, seams to fix the issue with ADW having to reload itself after a while.
GPS is still an issue, takes forever to get lock if at all...
Thanks, keep up the good work!
cyanogenmod fix for gps
$ su
# stop rmt_storage
# dd if=/dev/zero of=/dev/block/mmcblk0p13
# dd if=/dev/zero of=/dev/block/mmcblk0p14
# reboot
better do a nandroid backup if it doesn`t boot up anymore
this fixes the gps lock in about 5-10 sec and its been available since 6.0 cyanogen
caretaker01 said:
$ su
# stop rmt_storage
# dd if=/dev/zero of=/dev/block/mmcblk0p13
# dd if=/dev/zero of=/dev/block/mmcblk0p14
# reboot
better do a nandroid backup if it doesn`t boot up anymore
this fixes the gps lock in about 5-10 sec and its been available since 6.0 cyanogen
Click to expand...
Click to collapse
Thanks, trying as i type, in my case the above didn't seam to make any change, it was seeing the sats and using them eg. 6 in view 6 in use even after 10 mins no lock.
Right now it is seeing 12 sats, 10 in use been waiting over 5mins, still no lock.
Why are you guys copy-pasting commands you don't know what they actually do?
Sent from my HTC Legend
this fix was for vision and ace
I do not know if the partitionmapping is the same on the Legend
I do not recommend doing a dd zero until someone confirms the partitions
EDIT: the commands won't brick your device, in fact they DO NOTHING since the devs do not exist
Code:
block # ls -lha
brw------- 1 root root 179, 0 Dec 19 00:43 mmcblk0
brw------- 1 root root 179, 1 Dec 19 00:43 mmcblk0p1
brw------- 1 root root 31, 0 Dec 19 00:43 mtdblock0
brw------- 1 root root 31, 1 Dec 19 00:43 mtdblock1
brw------- 1 root root 31, 2 Dec 19 00:43 mtdblock2
brw------- 1 root root 31, 3 Dec 19 00:43 mtdblock3
brw------- 1 root root 31, 4 Dec 19 00:43 mtdblock4
brw------- 1 root root 31, 5 Dec 19 00:43 mtdblock5
I found it nice to see that someone picked the from source builds up and want to take some load off
http://datatomb.de/mirror/ROMs/CM7.2/update-cm-7.2.0-RC0-111222-Legend-KANG-signed.zip
this is my build from now, all changes until 21.12.2011 21:00 CET are included
DooMMeeR said:
EDIT: the commands won't brick your device, in fact they DO NOTHING since the devs do not exist
Click to expand...
Click to collapse
People stupid enough to copy/paste these commands would rather deserve /boot, /recovery, /system and /data wiped if you ask me.
@Blayo and Ali Ba, I did do a search before blindly typing the commands given, once I was satisfied they seamed to be legit, and not malicious i did the deed, obviously not every thing is equal in android land and something for one flavour of android O/S is transposable to another one.
---------- Post added at 02:53 AM ---------- Previous post was at 02:47 AM ----------
ranger4740 said:
Thanks, trying as i type, in my case the above didn't seam to make any change, it was seeing the sats and using them eg. 6 in view 6 in use even after 10 mins no lock.
Right now it is seeing 12 sats, 10 in use been waiting over 5mins, still no lock.
Click to expand...
Click to collapse
Ok, so after over 30 mins still no location lock, gps seeing and using upwards of 12 sats.
Oh Well, [email protected] Happens
Hi !
My note is running CleaNoteV6 (LRQ) with XXLRK model and kernel.
I recently wanted to use my GPS and after activating the GPS in the drop-down menu, I started a GPS app like Gmaps or Waze or even GPS Test, the GPS icon is not showing in the status bar and I obviously can't get a single satellite signal nor a fix.
I tried GPS after flashing the rom and it was working at this time.
I have tried to reflash modem, different kernels and a dalvik cache wipe. Nothing worked!
Any suggtestions ?
Thanks!
For me, I will reinstall the rom and take only 20 min with clean install
simplelife said:
For me, I will reinstall the rom and take only 20 min with clean install
Click to expand...
Click to collapse
I think it wouyld take more than this with all the apps I have
I keep this option as a final solution, but I actually was waiting for JB to perform a full wipe / clean install.
Thank U for answering !
sibere said:
I think it wouyld take more than this with all the apps I have
I keep this option as a final solution, but I actually was waiting for JB to perform a full wipe / clean install.
Thank U for answering !
Click to expand...
Click to collapse
Since you know what to do and ready try everything ( changed modem, kennel...etc) that why I come up with final solution ( clean install rom)...hihi
Flashing kernels and cache/dalvik wipes sometimes doesn't fix the problem. What fixes most problems is to flash stock GB. Do a full wipe. See if that gps works. Then start over.
This seems time consuming considering the number of apps you have but it may be quicker than finding an "easy" fix. You can go on with this problem for days. On the other hand you can be done in a day if you do the "final" solution.
ginopunsalan said:
Flashing kernels and cache/dalvik wipes sometimes doesn't fix the problem. What fixes most problems is to flash stock GB. Do a full wipe. See if that gps works. Then start over.
This seems time consuming considering the number of apps you have but it may be quicker than finding an "easy" fix. You can go on with this problem for days. On the other hand you can be done in a day if you do the "final" solution.
Click to expand...
Click to collapse
Yep seems a good idea. I'll try to flash rom again with a wipe and if it's still dead I'll flash GB and then ICS again. What a pain in the *ss !
Found the solution!
I finally found the solution to this issue!
After rebooting, I decided to have a look at the logcat before flashing/wiping.
I found issues with two pipes used by GPSD in /data/gps
These are the WRONG files (pipes) that gpsd couldn't open:
Code:
[email protected]:/data/gps # ls -la
ls -la
drwxrwx--x 2 system system 4096 Oct 23 13:24 .
drwxrwx--x 28 system system 4096 Oct 23 14:13 ..
prw-rw---- 1 gps system 0 Oct 18 01:27 .gps.interface.pipe.to_gpsd
-rwxrwx--x 2 app_139 app_139 6786 Oct 18 16:28 .gps.interface.pipe.to_jni
I deleted those files, rebooted the phone one more time, and voilà ! I've got my little GPS icon flashing again in the notification bar!
So if this appends to you, turn off GPS, go to /data/gps , delete any .gps* file you can find there, reboot and you'll get your GPS back to life. gpds is creating the files when you turn on any GPS app.
These have the right system rights.
Code:
[email protected]:/data/gps # ls -la
ls -la
drwxrwx--x 2 system system 4096 Oct 23 14:24 .
drwxrwx--x 28 system system 4096 Oct 23 14:23 ..
prw-rw---- 1 gps system 0 Oct 23 14:25 .gps.interface.pipe.to_gpsd
prw-rw---- 1 gps system 0 Oct 23 14:25 .gps.interface.pipe.to_jni
I am sure this will soon be moved into general ware it will sit among questions not related to compiling or Rom building but I am in hope it is her long enough to be read and maybe addressed.
I rely a bit on init.d support for my Rom's especially CM12. I do this so changes can be made without changing the code or default.xml as much as possible in adition to Google Apps I would like not included. My basic philosophy is if it can be installed via Play Store than I would like the first boot only to include the Google Core files and Play Store so for example if you look at the below github link will see the changes I needed in CM11 to replace the default launcher with the Now Launcher, Replace Stock Camera with Google Camera and the same for the Calendar but would like the users to decide if they would like to include whatever apps they would like as oposed to needing to remove the APK. Anyhow in short I use init.d to avoid making as little changes to code or default.xml as possible as well as what gapps package is used. Many include incompatible libs as a few for my CM based incarnation need to be replaced using either the Stock lib or libs taken from data/app that are more current so the script on first boot after flashing gapps will move files from a staging directory and place or replace ware needed and then remove the staging directory.
CM11
https://github.com/Starship-Android/android_device_starship-common/blob/cm-11.0/app-update
https://github.com/Starship-Android/android_device_starship-common/blob/cm-11.0/cleanup
CM12
https://github.com/Starship-Android/android_device_starship-common/blob/cm-12.0/app-update
https://github.com/Starship-Android/android_device_starship-common/blob/cm-12.0/cleanup
So far have done a decent amount of Google work and have learned my problem with both AOSP and CM is that SELinux is blocking init.d but have not found anything on how to address steps on fixing for what I use it for. The above links are just a small part but give enough of an idea of what I am trying to accomplish via init.d.
Any help would be appreciated. Until now I had fought a bit with SELinux once introduced to apply to the Kernel for the device I was developing at the time HTC EVo V 4g & EVO 3D but since then is still unfamiliar territory as I have not needed to learn much about it other than implementing into a Kernel when cm-10.2 was released. Both Devices had not been updated past ICS by HTC. I am thinking that maybe I need to add or change permissions in one of the rc files in the boot.img but honestly not sure as mentioned I have found plenty of mentions that SELinux is what is causing my init.d problems but have not seen anything on a solution or even just a link to an explanation of what specific changes had been made regarding SELinux or a further more detailed explanation specific to what in SELinux is responsable so can try to understand enough to figure out myself how to make the necessary changes .
Otherwise like my previous thread on What needs to be done differently developing with AOSP for developers who have gained all their experience bringing Cyanogen to new devices and other Sources who are now trying to develop AOSP Rom's for Nexus devices think this is a topic that would help developers save time and research but will probably be moved to general Q&A. Is off topic but with other Devices if questions or topics required basic knowledge of compiling source, Kernel changes or github would see the opposite in the threads being moved into developer discussions and not for example move a thread discussing say compiling the AOSP Kernel in line compiling both Rom and Kernel together or code changes needed in the build repository / Directory to stop custom recovery from being replaced with Stock recovery when users flash a custom Rom and reverting from Block based update zips to using the old school non Block based update zips. So far though I have posted these topics here as you don’t see members with such knowledge looking through the general Q&A section. Maybe I just inadvertently made an enemy of an admin as was surprised almost besides myself when a previous thread in the middle of discussing what changes would be needed for in line AOSP Kernel compiling in line like CM does compiling the Kernel along with the Rom and doing away with pre built Kernels. Needless to say the discussion was moved and died in general Q&A so if this is actually read I am asking that this thread remain in Developer Discussion long enough for an answer or at least a link to a resource covering the topic as a topic regarding the implementation of SELinux policy in a custom Rom will surely die in general Q&A, Thanks!
Are you OK with just disabling selinux? That's what I ended up doing. I recompiled the kernel with the option of using a boot command-line parameter to enable or disable as I see fit.
Gene Poole said:
Are you OK with just disabling selinux? That's what I ended up doing. I recompiled the kernel with the option of using a boot command-line parameter to enable or disable as I see fit.
Click to expand...
Click to collapse
When you have the option to disable or enable it, how do you set it to "disabled" afterwards?
I tried to compile a kernel+rom with selinux disabled many times but got only bootloops. With Kitkat it was working flawless.
L changed a partition entry adding a selinux policy to the mounting information. You need to change this entry int fstab.hammerhead to keep it from hanging on boot:
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337[COLOR="Red"],context=u:object_r:firmware_file:s0 [/COLOR] wait
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337 wait
Then your kernel should boot. You can add a command line entry to the boot image to turn it off or on.
Edit:
You may also have to comment out a line at the top of init.rc. I'm not sure, but mine is commented so I must have done it for some reason.
Code:
# Copyright (C) 2012 The Android Open Source Project
#
# IMPORTANT: Do not create world writable files or directories.
# This is a common source of Android security bugs.
#
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.${ro.zygote}.rc
import /init.trace.rc
on early-init
# Set init and its forked children's oom_adj.
write /proc/1/oom_score_adj -1000
# Apply strict SELinux checking of PROT_EXEC on mmap/mprotect calls.
[COLOR="Red"]#write /sys/fs/selinux/checkreqprot 0[/COLOR]
# Set the security context for the init process.
# This should occur before anything else (e.g. ueventd) is started.
setcon u:r:init:s0
# Set the security context of /adb_keys if present.
restorecon /adb_keys
start ueventd
# create mountpoints
mkdir /mnt 0775 root system
Thanks, will give it a shot!
Any downside on disabling it?
Well, obviously, anything that selinux might be protecting you from would be able to get through, but as developers, we're pretty pessimistic about what we run on our devices.
Gene Poole said:
Well, obviously, anything that selinux might be protecting you from would be able to get through, but as developers, we're pretty pessimistic about what we run on our devices.
Click to expand...
Click to collapse
So its only f*** the NSA for us then!
So i add this to boardconfig: androidboot.selinux=disabled
Then do those things you said. Would i need to put on kernel defconfig :
#CONFIG_SECURITY_SELINUX=is not set
Or will i have to add that "allow selinux disabled on boot"
Or is it enough to have that boardconfig parameter and your things.
Thank you very much mate!
Oh and yes im building a full rom with inline kernel
I think that should do it. I've got a pretty hacked up boot.img so I can't be sure what's in there for what.
I have the following setting in my kernel config:
Code:
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y
Ok thanks for all the Selinux help but may look like I’m not able to run init.d scripts because root is disabled by default. So bringing up a new topic about starting first boot with root access. I have been looking over the CM github for a commit that turns it off so I can either manually revert or rebase a clone.
Gene Poole said:
L changed a partition entry adding a selinux policy to the mounting information. You need to change this entry int fstab.hammerhead to keep it from hanging on boot:
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337[COLOR="Red"],context=u:object_r:firmware_file:s0 [/COLOR] wait
Code:
/dev/block/platform/msm_sdcc.1/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337 wait
Then your kernel should boot. You can add a command line entry to the boot image to turn it off or on.
Edit:
You may also have to comment out a line at the top of init.rc. I'm not sure, but mine is commented so I must have done it for some reason.
Code:
# Copyright (C) 2012 The Android Open Source Project
#
# IMPORTANT: Do not create world writable files or directories.
# This is a common source of Android security bugs.
#
import /init.environ.rc
import /init.usb.rc
import /init.${ro.hardware}.rc
import /init.${ro.zygote}.rc
import /init.trace.rc
on early-init
# Set init and its forked children's oom_adj.
write /proc/1/oom_score_adj -1000
# Apply strict SELinux checking of PROT_EXEC on mmap/mprotect calls.
[COLOR="Red"]#write /sys/fs/selinux/checkreqprot 0[/COLOR]
# Set the security context for the init process.
# This should occur before anything else (e.g. ueventd) is started.
setcon u:r:init:s0
# Set the security context of /adb_keys if present.
restorecon /adb_keys
start ueventd
# create mountpoints
mkdir /mnt 0775 root system
Click to expand...
Click to collapse
Bumb to this method. Something is changed in Nougat, after editin all these stuff, i will loose data and cell connections..
THIS THREAD IS FOR DEVELOPERS ONLY. IF YOU ARE NOT A DEVELOPER (or very tech-savvy and well-versed), MOST LIKELY YOU SHOULD NOT POST HERE.
By request, I am creating this thread for developer discussion. This is the place for developers to ask questions about how to handle/implement/embed SuperSU, discuss the operation of SuperSU, suggest improvements to compatibility, etc.
This thread hopefully reduces important developer related matters from being buried in the more user-oriented threads.
Please always include the version number of SuperSU you are referring to, even if it's the latest version right now. If applicable, also include information about phone and firmware you are testing with.
Chainfire said:
The stop-gap solution is to disable this caching completely, which is what the 000000deepsleep script does, which you can find mentioned or quoted in many posts around the forum. From SuperSU 2.66 onwards, that script is automatically installed on Samsung devices when systemless root is used.
Click to expand...
Click to collapse
Please forgive me for posting (in a cf-auto-root thread) and digging afterwards. I had thought I'd just dump the info and forget about it, but I couldn't stop digging...
...which led me to the quoted material.
Digging in the supersu 2.66 update-scriptbinary, I see that you're detecting "samsung" in the build fingerprint, and if true, doing a systemless install AND applying a deepsleep fix. This works for Galaxy S6 devices, but not for some other similar platform devices. In particular, the Note5 has THREE devices that need caching disabled in order for deep sleep to function. (0:0:0:3 as well as :2 and :1.)
My first question is: does the SGS6 even have a file named "/sys/class/scsi_disk/0:0:0:3/cache_type"? If not, just write to all three files and don't worry about it. The third write would fail on the SGS6 and all would be good. It'd be no worse of a work-around than already exists (and I think it's a bad work-around.)
If that file DOES exist in the SGS6, then something would have caching turned off that really shouldn't. Of course, existing or not, automatically tossing in this deepsleep patch for every single device that has "samsung" in the build fingerprint would seem likely break proper caching in some yet unknown samsung device. Perhaps the SGS7 will change things up so that :1 should be left cache flushable, and :2 would be the only one that should block cache flushing.
As well, it's also possible that Samsung will pull in the kernel fix to resolve this issue before they release Android M. (Okay, perhaps it'd be more likely for Samsung to open source touchwiz... but we can always have fantasies.)
My problem with the work-around is expressed above: it can break something in the future (and cause a support headache when some ONE exynos7420 device is fixed, but the rest aren't.) As well, it sets precedent of having platform specific hacks in the generic update.zip (but only allowing for a single platform and not in an easily expandable way.)
Obviously, it would be a maintenance nightmare to have different "00000deepsleep" files for every different device model. (if 'zerolte.*', SGS6. If 'nobellte.*', Note5, etc.)...
In keeping with what I tell other people, I feel I now have an obligation to suggest A Better Way. (a person shouldn't complain about something unless they can make a reasonable suggestion on how it'd be better.)
So, here's my slightly convoluted (but expandable) suggestion:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
Code:
echo PLATFORMSTARTUP='echo "temporary none" > /sys/class/scsi_disk/0:0:0:1/cache_type' >> /data/.supersu
(I'd have included both (or all three) needed lines for samsung deep sleep, but I forget how to include CR in a shell cmdline.. )
Then, the supersu installer script would just read PLATFORMSTARTUP and write it's contents to /su/su.d/00000platformstartup (and set perms.)
Given this type of thing, the existing 000000deepsleep hack would be removed. Then, individual devs could easily create simplistic "pre-installers" for supersu for specific platforms that need changes. Those "pre" installers would just write the needed PLATFORMSTARTUP lines to /data/.supersu...
... and then supersu.zip no longer needs platform specific hacks.
Some random XDA developer could then generate a simple "SGS6-supersu.zip" would only contain an edify script to mount /data and add/edit the .supersu file's PLATFORMSTARTUP variable to contain the two lines needed for deep sleep (and another dev could write a Note5 for the 3 lines needed on that platform... and so on..)
Take care
Gary
garyd9 said:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
...
Click to expand...
Click to collapse
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep. The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
NZgeek said:
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep.
Click to expand...
Click to collapse
The problems with the existing solution are:
1. It blindly alters the system kernel behavior for every single device samsung manufactures.
2. It only actually does any good for a single one of the dozens of devices from that sam manufacturer.
3. It completely ignores every OTHER device that might need a bit of help (and potentially does more harm than good for those devices.)
4. It encourages device developers (users on XDA) to download SuperSU.zip and re-package it to have device specific hacks in the .zip archive (creating a mess.)
Actually, I don't think I need to explain all the problems with the existing hack. I'd imagine (hope) that it was done as something quick to test out an idea, and was never intended to be left in place in it's current form.
NZgeek said:
The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
Click to expand...
Click to collapse
Which 5 devices? Who maintains that list? Who updates it for each firmware change that might require an update? Will there be a new "SuperSU.zip" package each time a firmware change on a device requires that one of those 5 be changed? Who deals with the support nightmare of saying "use SuperSU v a.bc for device X firmwawre Y" and "superSU v d.ef for device X firmware Z", etc?
My proposed solution takes all the device-specific stuff completely out of the SuperSU package. It changes it from a device-specific solution to be a more generic and expandable solution that requires LESS support from SuperSU and places the device specific burden outside.
Instead of encouraging device developers to repackage supersu to device specific packages, it encourages device developers to package something else alongside supersu that would work with the existing (and unaltered) supersu.zip (and would be future compatible.)
Take care
Gary
spiral777 said:
would there be a way to get kexec/ multirom working with systemless root?
and would flashing a modified boot image to a rom also effect the kexec hardboot partch of the kernel?
Click to expand...
Click to collapse
1- the current versions of systemless root make changes/additions to the kernel, but you're not "flashing a modified boot img", so kexec is not broken, since the kernel is in essence the same as before
2- yes it is possible for systemless root (tested with 2.65) to get it working on multirom, however some changes were needed; we're still debugging the problem to try to narrow down the issue, to get it to work with as little changes as possible
EDIT: I'll just mention the problems encountered in case @Chainfire wants to be aware of them
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
EDIT2: thanks @Captain_Throwback for the reminder
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
just FYI, but I'll check more thoroughly when I get a chance
@garyd9 @NZgeek
Some good points are raised. I am not going to go into them all individually.
There is one core point of disagreement though. While I do not think device-specific patches generally have a place in the SuperSU ZIP installer, the deep sleep issue affects so many million users it is too big to ignore. (By the way, as far as I know this issue affects all recent high-end Samsungs).
While I don't disagree with your ideal of custom pre/post installers, in reality most users will never discover the issue, and just blame SuperSU for suddenly bad battery life. This leads to many support emails, thread posts, bad rep, etc.
Contrast this to for example the LG G3 compatibility patch, which requires the user to indeed write a file to /data or use a pre-installer that does that, the device will simply not boot, which forces the user to either go back to stock, or search for and discover the fix.
Either way, you are right, the patch doesn't even work right for Note users. Thank you for pointing that out - nobody else ever did. I have come up with the following improved script. If for the moment, we put aside our differences regarding the inclusion of any device-specific fixes, what do you think of the following?
It will perform the cache_type change for any scsi_disk, but will skip the ones not set to write protected. This should catch the problem with devices that have a different disk layout, and prevent accidental reduced I/O speed for devices that are not affected.
Note that it is my understanding that the write protection mode cannot be reset without a flash chip power cycle, and as the protection is set by the bootloader long before our check, checking once at boot should suffice.
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Chainfire said:
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Click to expand...
Click to collapse
I won't be able to properly test this until at least tomorrow (Wed) evening... However, in the meantime, the following screenshots suggest that it'd also work on the Note5:
https://goo.gl/photos/61JWzoA5ir3PcDNr9
(This is with a custom kernel, however. I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Let me know when you'd like to debate on if SuperSU should fix (non-root related) bugs in only specific devices, all devices, no devices, or if it should just support a hook to allow third parties to fix both current and future/past devices. (Please don't get the wrong impression from that statement. SuperSU is your product, not mine... However you implement things is up to you.)
Please do let me know if I can be of further assistance to fix compatibility.
nkk71 said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
Click to expand...
Click to collapse
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
Click to expand...
Click to collapse
Where is this?
Chainfire said:
Please do let me know if I can be of further assistance to fix compatibility.
Click to expand...
Click to collapse
Thank you, I will let you know once I've had a chance to properly debug further
I initially only wanted to get systemless root to work, which using the workarounds (even though not ideal), was proof it can be done
(at the time it was SuperSU v2.65)
Chainfire said:
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
No need to take double symlinks into account, only the real one is changed as follows:
the real one is renamed with a "-orig" extension, and a symlink is created to an imaginary normal file:
Code:
cd [B][COLOR="Blue"]/dev/block[/COLOR][/B]
ls -l
...
brw------- 1 root root 259, 24 Jan 12 18:18 mmcblk0p40
brw------- 1 root root 259, 25 Jan 12 18:18 mmcblk0p41
[B]lrwxrwxrwx 1 root root 67 Jan 12 18:19 mmcblk0p42 -> /realdata/media/0/multirom/roms/HTC_One_M8_GPe_Marshmallo1/boot.img[/B]
[B]brw------- 1 root root 259, 26 Jan 12 18:18 mmcblk0p42-orig[/B]
brw------- 1 root root 259, 27 Jan 12 18:18 mmcblk0p43
...
all other symlinks to the block device remain as is:
Code:
cd[B][COLOR="Blue"] /dev/block/platform/msm_sdcc.1/by-name[/COLOR][/B]
ls -l
...
lrwxrwxrwx 1 root root 21 Jan 12 18:18 adsp -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 Jan 12 18:18 board_info -> /dev/block/mmcblk0p3
[B]lrwxrwxrwx 1 root root 21 Jan 12 18:18 boot -> /dev/block/mmcblk0p42[/B]
lrwxrwxrwx 1 root root 21 Jan 12 18:18 cache -> /dev/block/mmcblk0p46
...
Chainfire said:
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Will check, thanks.
Chainfire said:
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
Click to expand...
Click to collapse
Not really, everything else in init.rc get's executed properly; (and obviously the in launch_daemonsu.sh as well)
Chainfire said:
Where is this?
Click to expand...
Click to collapse
at the beginning of launch_daemonsu.sh:
Code:
if [ ! -d "/su/bin" ]; then
# if we fstab'd system/vendor/oem to rw, remount them ro here
remount_ro /system
remount_ro /vendor
remount_ro /oem
^^ I commented all three of them out, which worked out fine.
MultiROM's secondary ROMs always have system mounted rw, and the above remount_ro will force an immediate reboot
I need to do further testing on these issues, as soon as I come up with something more concrete, I will report back.
EDIT: forgot to mention, can confirm this for the HTC One M7, M8 and M9
garyd9 said:
I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Click to expand...
Click to collapse
So, two replies. I've edited the results to just show the device and value of write_protect. The first one is a KNOX tripped device with completely stock firmware/kernel (no root):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 1
scsi_disk/0:0:0:2 1
scsi_disk/0:0:0:3 1
The second is from a stock device where KNOX has never been tripped (the results are expected, but nice for confirmation):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 0
scsi_disk/0:0:0:2 0
scsi_disk/0:0:0:3 0
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
garyd9 said:
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
Click to expand...
Click to collapse
Knock yourself out. I'm not in a rush though. I don't expect to release another update for another few days at least.
Chainfire said:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Click to expand...
Click to collapse
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
dr.ketan said:
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
Click to expand...
Click to collapse
I don't know, since you changed it up, and your statement is a bit confusing.
Try this:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo Write protected: $i
else
echo Write enabled: $i
fi
done
Copy/paste the output.
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
dr.ketan said:
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
Click to expand...
Click to collapse
That's not needed, just run the other script I pasted above. It'll show what we need to know regardless of your kernel being patched or not.
[email protected]lelte:/ $ su
[email protected]:/ # ls -l /sys/class/scsi_disk/
lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:0 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:1 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:2 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:2/scsi_disk/0:0:0:2lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:3 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:3/scsi_disk/0:0:0:[email protected]:/ # cat /sys/class/scsi_disk/*/write_protect
0
1
1
1
[email protected]:/ #
dr.ketan said:
...
Click to expand...
Click to collapse
Seems fine!
I had some time to check a few things, so please find below my findings / possibly solutions
Chainfire said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
Fixed it by using the following code (perhaps the readlink -f is redundant, but it worked fine)
(at line 1199 of SuperSU 2.66 updater-binary):
Code:
if [ -b `readlink -f $BOOTIMAGE` ]; then
dd if=/dev/zero of=$BOOTIMAGE bs=4096
fi
Chainfire said:
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Turns out the loop device was in fact the problem; after umount /su, it still showed:
Code:
~ # [6n[B]losetup -a[/B]
losetup -a
/dev/block/loop0: 0 /data/su.img
so I just used/added (at line 1218 of SuperSU 2.66 updater-binary)
Code:
umount /su
[B]losetup -d /dev/block/loop0[/B]
I know it was on loop0 so I didnt need to account for anything else, but maybe using
Code:
LOOPDEVICE=`losetup -f`
or something similar, and continuing from there could be an option
Haven't tried checking on the other issues, but will report back when I have something on those
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
nkk71 said:
I had some time to check a few things, so please find below my findings / possibly solutions
Click to expand...
Click to collapse
Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.
This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...
garyd9 said:
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
Click to expand...
Click to collapse
Good news, as expected.
This is an update to the Ubuntu Touch build that I shared a while back.which was based on halium 7. Now we are moving to halium 9. Even with quite a few unsolved issues ,these builds are marginal improvement over the previous ones.
This port had been no means easy, in reality, the initial builds was even more buggy compared to previous gen ,but most of them were much easier to fix, as I got lots of help from the porting community.I was able to get it to a booting state in about 3 months time as compared to more than a year with halium 7 , to be fair the delay was also due to the fact that I was not exactly an android developer or a developer for that matter, and had to read a lot at first .
anyways I share it here as I have reached a point where further bug fixing is beyond my capability . or in other words, Googling error codes and testing all possible methods /solutions don't seem to yield any meaningful full result, I do really wish someone better than me would look into it and make it even better ;- )
In the meantime let me add more Verbose ;-P
What is ubuntu touch
ubuntu touch is different from other oses as it is fork of Linux as compared to all our favorite mobile oses being forks of android. in other words, it is a fully functional Linux os optimized to run on arm64 device in a touch environment.The original idea was conceived by canonical and later they stoped their work and open-sourced the project and transferred the assets to the ubports community, the community is actively improving it, and trying to bring it to feature parity with Android .
whats working on this port
calls,data ,wifi
sound, vibration
auto rotation
auto, manual brightness
Offline charging
GPS
and other misc things
whats partially working
camera (preview and take video works clicking picture not working)
fingerprint (fingerprint wakes the device but cant enroll fingerprints)
Bluetooth (everything works except file transfer)
what does not work
adb,mtp
one of the feature improvements amongst other things is the support for waydroid
Waydroid
waydroid is a containerised approach to get an android environment running in a Linux system with the added advantage of full hardware access.so we can android apps and games natively. more details can be found here. to install way droid open terminal and paste the following
sudo -s
mount -o rw,remount / && apt update && apt install waydroid && waydroid init
It also need a fix as waydroid is intended for treble devices which can be found in this post. Thank you @erfanoabdi for enabling support for non treble devices.
Installation
- flash the halium-boot and the following zip file
- clean flash recommended
- reboot after the initial setup is done
Halium-boot .img
ubuntu_touch_installer_Kenzo_halium9_v7.zip
Please Donate
Every rupee ,euro ,doller counts. It would feel wounderful to be gifted something no matter how small.
If you like to do more, please consider buying me a coffee or may be even another Kenzo.
if you are in India please use this upi id -- > [email protected]
else do pm me.
default user password is " a "
For the History book
ubuntu_touch_installer_Kenzo_halium9_v6.zip
ubuntu_touch_installer_Kenzo_halium9_v5.zip
ubuntu_touch_installer_Kenzo_halium9_v4.zip
ubuntu_touch_installer_Kenzo_halium9_v2.zip
The sources
[https://github.com/mathew-dennis
[https://github.com/LineageOS
[https://github.com/Halium
[https://github.com/ubports
Thankyou
ubports community --> TheKit ,FlowHack, kn8rider divin, ari and everyone else
Redmi note 3 community --> thanks to all Dev's for keeping the device alive for the community .
This port would have never reached anywhere without their efforts..
And the truth is my efforts are very little as compared theirs...thank you ...
changelog
"Why not make something new from old code!" (Also because my pc can't handle A10+ builds)
v7
- updated to latest rootfs (ota-24)
V6
- updated to latest rootfs (ota-22)
- rebuild android image
- auto-brightness
V5. 1 (this is a patch for v5)
- bluetooth (everything else except file transfer )
- offline charging
- gps ( for real this time ) ( as ut dont have A-GPS support 1st fix might take 5+ min ,then it should work as normal)
v5
- gps is working now ( it's broken again)
-changed audio hal to a late start service
-enabled wireless display option (should work on miracast devices ) (not tested )
-fixes from ubports --> magnetometer and notification led is working and other fixes from ota 18 to ota 20
v4
- fixed issue with initial setup --thankyou Kn8Ryder
-audio should come up more often during boot than before
Telegram
If you are interested in bug fixing and contributing to this project , report a bug , click here to reach Telegram group
#Screenshots
what is default user password...
KrutosVIP said:
what is default user password...
Click to expand...
Click to collapse
"123" if u flashed old rom first, else "a"
mathew..denniss said:
"123" if u flashed old rom first, else "a"
Click to expand...
Click to collapse
ok, will try
Touch not working! after initial setup
mathew..denniss said:
"123" if u flashed old rom first, else "a"
Click to expand...
Click to collapse
Working for me, thanks for porting this amazing system.
BraveAmbush said:
Touch not working! after initial setup
Click to expand...
Click to collapse
For me the fix was to firstly install old ubuntu touch, load it and configure. After that,flash bootimage of new Ubuntu Touch with Halium9, then flash .zip with new Ubuntu Touch. It will give error, it is normal - go to /data/ and delete dir "ubports", then try again.
After that - just reboot, system will start with configured profile "Ubuntu"
The password is just "a"
Also, for me sound not working.
KrutosVIP said:
For me the fix was to firstly install old ubuntu touch, load it and configure. After that,flash bootimage of new Ubuntu Touch with Halium9, then flash .zip with new Ubuntu Touch. It will give error, it is normal - go to /data/ and delete dir "ubports", then try again.
After that - just reboot, system will start with configured profile "Ubuntu"
The password is just "a"
Click to expand...
Click to collapse
both flash may end with flash error that not a problem its a busybox compatibility thing.(not relevant )
KrutosVIP said:
Also, for me sound not working.
Click to expand...
Click to collapse
try a hard reboot(long press power button) .it should work afterwards
BraveAmbush said:
Touch not working! after initial setup
Click to expand...
Click to collapse
mathew..denniss said:
both flash may end with flash error that not a problem its a busybox compatibility thing.(not relevant )
Click to expand...
Click to collapse
For me deleting ubports helps to end without error-
When i don`t delete and get error, the system just don`t want to boot.
No animation, just black screen and when reboot
um that for me sound dont work too..
if not delete ubports in recovery and install, it 'll show a short black screen with a small mouse and reboot.
Also there are strange permission issues in the system dirty flashed from halium 7
Can I ask for some clarification? I managed to install the alpha version from your previous post, but how do you flash these update zips? I tried flashing them via TWRP on the device but I keep getting "recovery busybox setup failed" error.
jeangjenq said:
Can I ask for some clarification? I managed to install the alpha version from your previous post, but how do you flash these update zips? I tried flashing them via TWRP on the device but I keep getting "recovery busybox setup failed" error.
Click to expand...
Click to collapse
An update on this, after two more tries of reinstalling old ubuntu touch > flashing halium-boot through fastboot > Flashing zip through TWRP. It flash without issue and booted. Initially the sound isn't working, but after several weird restarts (select poweroff but it restarted, select poweroff but it froze on boot logo, etc etc), sound is working. This is a fun project
updated the flashable zip .. thankyou for the fix @Kn8Ryder
t
jeangjenq said:
Can I ask for some clarification? I managed to install the alpha version from your previous post, but how do you flash these update zips? I tried flashing them via TWRP on the device but I keep getting "recovery busybox setup failed" errotry v4
Click to expand...
Click to collapse
jeangjenq said:
Can I ask for some clarification? I managed to install the alpha version from your previous post, but how do you flash these update zips? I tried flashing them via TWRP on the device but I keep getting "recovery busybox setup failed" error.
Click to expand...
Click to collapse
try v4 ,it has some more fixess.busybox things are gone now
how many minutes does waydroid open to you ?
I did clean install
boot halium + v4 update
then install waydroid thru terminal
loading screen boot logo waydroid? is this alright?
im waiting to it