Related
We have been discussing in another thread the possibility of getting a CM7 rom available for the NT.
Now that we have a functional recovery this should seriously help out with testing, if it goes wrong we can just restore to a working rom and start again debuging as we go.
***UPDATED 5TH Feb 2012***
I thought it was about time I updated this post with some up to date info on current state of development.
As many of you will know we got together last week and decided that we would like to build a CM7 rom for the Nook Tablet.
Goncezilla had already been making progress building firmware and a boot.img to get the thing booting up. Initially the system booted and you couldn't do a lot with it, but it prooved it could be done. Here's the vid showing the first boot:
After that it was down to work to make it useable. After a bit of investigation and a lot of man hours this is where we are at now
HARDWARE FUNCTIONS
Touchscreen FULLY WORKING
Orientation sensors FUNCTIONAL
Sound WORKING
SDCard WORKNING
WIFI Fully WORKING
Hardware video acceleration WORKING
SOFTWARE
Custom Kernel BUILT AND FUNCTIONING
Full tablet version on Cyanogen Mod WORKING
Root Access WORKING
Gapps WORKING
Sleep mode WORKING
Brightness control WORKING
BOOT FROM SD CARD SOLUTION AVAILABLE
and the one everyone seems to think is important
Angry Birds YES IT WORKS PERFECTLY lol
Another little video of current progress
Finally we have wifi working!
Sorry it's sideways, it's changing it now but it seems Google have slow computers!
So the main things we have left to fix are
1. Ermm... hmm... I'm sure we'll think of something
Thanks to Celtic for taking on the OP of this forum!
EDIT 2/5/2012Here are the source files used to create the first CM7 beta:
Internal
1. Kernel built from source - http://www.mediafire.com/?tu5lm7q8t5pbqpf
2. Nook Color CM7 Ramdisk (the one we want to modify) - http://www.mediafire.com/download.php?epv9n97evhnuaoi
3. Stock Nook Tablet Ramdisk (the one we need to borrow from) - http://www.mediafire.com/download.php?xms3aeztgupkjco
4. Buawk's Internal Boot.img 2ndboot (this gets appended to the front of a boot.img to get around the locked bootloader) - http://www.mediafire.com/download.php?9l8uxx7rhbqzund
5. Modified CM7 /system partition files (should be good to go for NT) - http://www.mediafire.com/download.php?il5ky2l51q48e8h
6. Modified Ramdisk - http://www.mediafire.com/download.php?9l8uxx7rhbqzund
7. Wifi Driver files (built from Kindle Fire source) - http://www.mediafire.com/?vogxuygrf84xsoe
8. Kernel Config File (settings used to build kernel above) - http://www.mediafire.com/?7vjvqctmlnd4enw
9. GFX Drivers (put in /system/lib/modules and insmod) - http://www.mediafire.com/?5uw4wgytb60n485
SDCard
1. SDRamdisk - http://www.mediafire.com/?4p3wq0u4p9j9mtd
All other files are same as internal.
EDIT 2/4/2012
My Plan for success:
1. Build a boot.img from CM7 NookColor Rom - Done!
3. Get a booting rom working from SDcard to verify steps 1 and 2 - Done! SDcard working great!
4. Port to internal boot partition (CWM) -Done!
5. Tweak to get everything working - Ongoing....
All other ideas welcome here!
I'll flash and test things for you all.
Sent from my Nexus S 4G using Tapatalk
LiuAnshan said:
I'll flash and test things for you all.
Sent from my Nexus S 4G using Tapatalk
Click to expand...
Click to collapse
Thanks
Just to let anybody interested know in advance, this may or may not turn into a working rom, even if it does become a fully functional rom please remember that during testing if your tablet does a nose dive and you can't recover for some obscure reason, we take no responsibility for any damage caused.
Other than that, as and when we have something testers will efinately be needed
Goncezilla said:
Reserved.
Ill post my current working files here soon. Thanks to Celtic!
My Plan for success:
1. Build a boot.img from CM7 NookColor Rom - Kernel built, working on ramdisk
2. Port /system partition -Mostly done but untested
3. Get a booting rom working from SDcard to verify steps 1 and 2
4. Port to internal boot partition (CWM) -2ndboot.img built and waiting
5. Tweak to get everything working
All other ideas welcome here!
Click to expand...
Click to collapse
So i'd thought id put in my two cents here...
First off, whom ever is testing this will want to have 2 sd cards, one of which is the update_acclaim boot disk, so they can "unbrick" their device. This device is nearly unbrickable, and whom ever ends up testing it, can make sure that they can always return it to stock.
Second off, I would HIGHLY recommend using the stock kernel, with the security keys stripped off. This would eliminate any problems that you would encounter with the kernel not causing a boot. I can get you guys a copy of the stock if you want, as it is easiest to just take the first 288 bytes off of the existing kernel, and ramdisk. I don't have an NC, but i'm not sure that the partitions are the same, I would think about building the ramdisk by combining the two ramdisks.
Lastly if someone has the inclination, they COULD eliminate the useless partitions, DO NOT TOUCH THE X-LOADER OR UBOOT PARTITIONS, MODIFYING THEM WILL BRICK YOUR DEVICE. However there is the useless BN and rom partitions that could be consolidated.
Ill be checking in from time to time, I would recommend that you join the CM7 IRC channel and make a new one so that you will not be bothered.
I've done little more than keep the port of miui updated for the Samsung infuse, but I'd be willing to help where I can. I'll probably only be useful for testing, but I'm more than willing to soft brick several times (or risk a hard brick )
Don't modify the rom partition, it forces a wipe of the device and without a proper recovery for that (stock) you're **** out of luck.
Sent from my Nexus S 4G using xda premium
Loglud said:
Second off, I would HIGHLY recommend using the stock kernel, with the security keys stripped off. This would eliminate any problems that you would encounter with the kernel not causing a boot. I can get you guys a copy of the stock if you want, as it is easiest to just take the first 288 bytes off of the existing kernel, and ramdisk. I don't have an NC, but i'm not sure that the partitions are the same, I would think about building the ramdisk by combining the two ramdisks.
Click to expand...
Click to collapse
Interesting about the first 288 bytes. Any specific reason for stripping them? Is this the kernel header or is it for the ramdisk too? The kernel Im using was built from the BN source.
The ramdisk Im putting together is a combo of the NC and NT. Im working on porting the .rc files and build.prop. There is a lot to look at and any help is appriciated. Ill post the files when I get home this weekend.
Lastly if someone has the inclination, they COULD eliminate the useless partitions, DO NOT TOUCH THE X-LOADER OR UBOOT PARTITIONS, MODIFYING THEM WILL BRICK YOUR DEVICE. However there is the useless BN and rom partitions that could be consolidated.
Click to expand...
Click to collapse
Good call here. I was thinking about mounting the 15GB B&N partition as rw and leaving it at that. If we get brave we can try and merge the partitions.
Thanks for the input.
---------- Post added at 08:32 PM ---------- Previous post was at 08:29 PM ----------
Indirect said:
Don't modify the rom partition, it forces a wipe of the device and without a proper recovery for that (stock) you're **** out of luck.
Sent from my Nexus S 4G using xda premium
Click to expand...
Click to collapse
Maybe this is the issue Im seeing. Does this mean we have to use 2ndboot to point to another partition? Is there a mdsum check being done at boot that triggers this?
EDIT: Nevermind was thinking boot partition instead of rom. Rookie mistake No plans to touch rom partition.
Guys, we won't need testers. We all have NT's. You all will get a build once it's in alpha.
Like Indirect said, as far as startup is concerned we'll be able to do the testing, we won't really need external testing until we have something semi stable.
Thanks for all your offers though. I'm sure when we get to alpha/beta stage you'll all get a shot at it
As agreed with OP i am going to move this to general. As soon as development is posted, it will be moved back to Development.
Thanks to the OP for his co-operation, He is a gentleman and exactly the type of member we want at XDA Developers!
Peace!
clock work mod
thanks to Albert I am beginning to understand the early stages of getting things like CM7 or 9 functional for the NT and his his recent video on youtube gives a good idea on the developments going on for the NT. I am trying to understand the possible uses of CWM for the nook other than it being a framework for installing custom roms. .. Thanks
Rafael863 said:
thanks to Albert I am beginning to understand the early stages of getting things like CM7 or 9 functional for the NT and his his recent video on youtube gives a good idea on the developments going on for the NT. I am trying to understand the possible uses of CWM for the nook other than it being a framework for installing custom roms. .. Thanks
Click to expand...
Click to collapse
Link to the video, per chance? Thanks in advance!
Just a quick update before I call it a night.
I've been having a lot of trouble getting a working boot.img built. When I cat the 2ndboot to my boot.img I see the flash screen on bootup but quickly get a black screen followed by a reboot of the system.
I can't even get the stock boot.img to boot after appending the 2ndboot.img file. I was, however, able to boot into CWM from the boot partition by attaching the 2ndboot.img. This tells me that the 2ndboot is working properly.
I'm continuing to deep dive on the boot.img files, but if any other devs want to play around with cat 2ndboot to a boot.img it might help.
All I've been doing to this point is taking the boot.img from a CWM recovery, adding the 2ndboot.img to the front of it, placing the modified boot.img back into a new CWM recovery folder (and rebuilding nandroid.md5), then flashing the boot back on using CWM Advance Recovery.
Well, I can report some partial success!
I was finally able to unpack a stock boot.img, modify the ramdisk (nothing major just a small tweak to test results), repack with another unsigned kernel, flash the new boot.img and get a good boot. I did this by using the kernel extracted from nemith's CWM image and not the custom kernel I've posted, so it seems like there is an issue with that kernel for now.
Anyway, I'll try and post some more files later but in the mean time I'm moving on with trying to get a CM7 ramdisk to boot.
I think this is now at a stage that it can be moved back to development.
Good work Guys!
Goncezilla said:
Well, I can report some partial success!
I was finally able to unpack a stock boot.img, modify the ramdisk (nothing major just a small tweak to test results), repack with another unsigned kernel, flash the new boot.img and get a good boot. I did this by using the kernel extracted from nemith's CWM image and not the custom kernel I've posted, so it seems like there is an issue with that kernel for now.
Anyway, I'll try and post some more files later but in the mean time I'm moving on with trying to get a CM7 ramdisk to boot.
Click to expand...
Click to collapse
Great to see you've made some decent progress. Sorry for my total lack of input, you're a good few steps ahead of me in developing. I'm still on a serious learning curve!
I'm getting there hopefully in time I catch up with you and give some decent worthwhile input!
CelticWebSolutions said:
Great to see you've made some decent progress. Sorry for my total lack of input, you're a good few steps ahead of me in developing. I'm still on a serious learning curve!
I'm getting there hopefully in time I catch up with you and give some decent worthwhile input!
Click to expand...
Click to collapse
Hey if you have any questions throw them out there. I'm learning some things as I go along but don't have all the answers either. Hoping we can start combining efforts to move forward.
---------- Post added at 10:31 PM ---------- Previous post was at 09:31 PM ----------
EDIT:More progress!
Was able to get the stock ramdisk to boot using the compiled kernel I posted. I think the issues were with my compilers. No guarantees they are fixed but we are getting close I can feel it!
I'm not sure but I think this kernel can be overclocked, so if nothing else this should allow you to overclock a rooted stock device for now. I'll do some testing and get back....
EDIT 2:
Well it looks like this kernel should be capable of overclocking, but there are a few other bugs with it (could not turn on wifi) that still need to be worked out so I am moving on for now. I will post the boot.img if anyone else wants to play around with the custom kernel on stock firmware in the meantime.
They had issue with wifi in the cm9 thread which they've now fixed. Perhaps some help from there thread will be available?[/QUOTE]
Good call, maybe we can leverage from them. I think I'm just missing a configuation setting in my kernel build but everything else seemed to be working so I'm not too worried about fixing it right away. Would rather get CM7 to boot
EDIT:
Well more progress to report this morning! I've finally got a CM7 boot screen! I'm stuck in a bootloop but we are really close now!
Turns out my permissions were all jacked up on my system partition and it was refusing to allow the kernel to load divers. I've jacked with files so trying to get a good boot that I'm not even sure what I have right now, so I'll go back to square one and hopefully see a full boot
Whenever you get a boot loop, I suggest that you get a logcat so you know what to look at.
Sent from my Nexus S 4G using xda premium
This thread is for development updates, and an eventual release of testing candidates for the future of dual booting CM12 android roms on the Amazon Fire TV. At this time I am not planing on supporting the Fire TV stick since my development platform is based off USB3 booting.
There currently isn't even a stable branch in CM12 upstream so things are quite tricky right now.
I may eventually setup public nightlies once the core is stable.
IN PROGRESS FORM HERE: https://t.co/TXp9z7htDx
The goals for development are in this order:
Wifi [working]
Bluetooth [crashing]
Stable core [random resets possibly storage related]
Audio [possibly needs hacking to default to hdmi]
Recovery system [rom boots using the recovery partition currently]
Hardware Acceleration [untested]
Android TV addons [require stable core]
USB Formating and install app [apparently not everyone knows what gparted is]
Modified version of Rbox's bootloader [I'd like to add recovery to the loader then have stock and custom boot options]
Also, if you want to be ready for possible nightly testing, I highly recommend going to walmart and buying one of the playstation USB3 hubs. It's about $20 but allows you to plug in a USB3 drive and keyboard and mouse until bluetooth is working.
SETTING UP USB BOOTING:
Code:
#include <std_disclaimer.h>
/* * Your warranty is now void. *
* I am not responsible for bricked devices, dead USB drives,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in these files
* before flashing them! 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. */
PART ONE [Preparing the drive]:
This process will eventually be streamlined but for now I'll explain the process and how it relates to testing builds during development. Since the Fire TV only has an 8gb flash chip and has no hardware recovery trigger, it is quite the unforgiving device to develop on. The current boot method for my CM12 builds involves flashing over the recovery partition and using it as a sort of dualboot partition. The modified recovery partition then searches for ext4 partitions on and external (USB3 preferred) flash drive. Currently each build generates its own boot image to be flashed over recovery, but I'm currently in the process of exploring the possibility of following Rbox's method of loading a boot image from a system folder instead making only one flash to the actual device necessary going forward.
For USB3 booting during the development process I highly recommend using a USB3 hub for a keyboard and mouse while bluetooth pairing and control mapping is being worked on. I also recommend a USB3 drive.
1) Turn on a Linux machine or boot a Live CD
2) Open Gparted
3) Delete any partitions on the usb drive
4) Create three ext4 partitions, the first partion is system and should be about 1GB, the THIRD partition is cache, and should be about 768mb with 0mb following, you should then have the middle portion empty in the display, in this SECOND partition make your data partition fill the rest of the space.
PART TWO [Preparing the bootloader]:
WARNING this process currently involves replacing your recovery partition, remember kids dd and root is like holding a grenade, make sure you don't throw it at something you care about.
Also, if you are testing a build and it does not load using the previous bootloader, try flashing the latest one from the nightlies (and vise versa) as I am still in the process of stream lining the boot process as far as what should take place before system bring up on our device. If a different boot image loads the system with noticeably more stability let me know asap so I can track the causes of my current issues.
Code:
adb connect <STOCK FIRE TV IP>
adb push boot-<DATE>.img /sdcard
adb shell
cd /sdcard
su
dd if=boot-<DATE>.img of=/dev/block/platform/msm_sdcc.1/by-name/recovery
Next I recommend side loading this apk to make rebooting into USB boot easier.
The three most recent "boot" images have been added to the downloads section, remember these should be flashed to recovery. Although they would work in boot, that would disable Rbox's loader and prevent you from loading stock OS.
PART THREE [Playing with instability]:
Great so now you have a USB3 booting image flashed to your recovery partition and you have an empty flash drive. This is where the tinkering begins. In the download section you will find a .tar.gz archive with a somewhat booting system with the aforementioned issues. Inside this archive is a system.img file which you will use dd to flash to the first partition of the flash drive you formated. After the system image is flashed you can plug your flash drive into your hub and reboot into recovery. Things will be great, wifi will show up and if you're quick enough you can complete setup and make it to the launcher. (the issue I'm currently working on is an odd timed reset that may be kernel or storage related oddly if you make it to the launcher and don't touch anything, it takes longer to reset)
If you made it this far, welcome to development. You can help by "kanging" (replacing system apk's and files with other versions to find more stable matches, or remove apks until things don't die then report back to me) Also if you make it to this point go ahead and fill out the form I mentioned earlier. Eventually any hotfix builds I do between nightly builds will be accessible to those users to play with.
Overhauling the boot system next and working on the reset debugging.
XDA:DevDB Information
TechVendetta ROM Development, ROM for the Amazon Fire TV
Contributors
TechVendetta, rbox
Source Code: https://github.com/TechV/android_device_amazon_bueller
ROM OS Version: 5.0.x Lollipop
Based On: CyanogenMod
Version Information
Status: Testing
Created 2015-01-29
Last Updated 2015-01-29
Reserved
UPDATE: I'm pretty much settled in to my new job/home now so I'm going to resume this project shortly. The first order of business is to see what sort of driver improvements we got from Amazon and whether their modifications help resolve the issues I was having. I only have the original FireTV so I'll be only testing on that. Not sure if the new one has an unlocked bootloader or recovery system so that will be up to whichever brave soul wants to test that. Hopefully tomorrow I can resync my repos and get a look at whats changed.
Reserved
Thanks for the update! Looking forward to seeing how this progresses.
Thanks for your work!
It would be nice run a CM12 build in Fire TV
So far the main system seems promising, I feel like the reset issue, which is the primary major roadblock is either in the kernel, or in the storage management/selinux services. Selinux should be disabled in this build so I'm looking into the other two options right now.
TechVendetta said:
So far the main system seems promising, I feel like the reset issue, which is the primary major roadblock is either in the kernel, or in the storage management/selinux services. Selinux should be disabled in this build so I'm looking into the other two options right now.
Click to expand...
Click to collapse
Thank you for keeping us updated!
[email protected] said:
Thank you for keeping us updated!
Click to expand...
Click to collapse
I'll link this here for now, while I finish looking into the logs for bluetooth/wifi/audio before uploading a rough copy here. I think I'm going to use the individuals who filled out the form to test the installer and recovery apps I'll be doing after fixing the above three things.
:victory:| TEASERS |:victory:
TechVendetta said:
I'll link this here for now, while I finish looking into the logs for bluetooth/wifi/audio before uploading a rough copy here. I think I'm going to use the individuals who filled out the form to test the installer and recovery apps I'll be doing after fixing the above three things.
:victory:| TEASERS |:victory:
Click to expand...
Click to collapse
Hey,
i've got one question for the installation:
you use the recovery as boot partition (because you dont want to mess with the actual boot partition where the bootmenu is).
is there a reason we cant use rbox's bootmenu, add another entry "usb boot" which will boot from /system/boot/usbboot.img ?
Or is the only reason that this just hasnt been added by rbox so we have to use another way?
I think this would be the most brick safe version and shouldnt be a big problem for rbox to implement....
Chris
[edit]
i'm really looking forward to this
aHcVolle said:
Hey,
i've got one question for the installation:
you use the recovery as boot partition (because you dont want to mess with the actual boot partition where the bootmenu is).
is there a reason we cant use rbox's bootmenu, add another entry "usb boot" which will boot from /system/boot/usbboot.img ?
Or is the only reason that this just hasnt been added by rbox so we have to use another way?
I think this would be the most brick safe version and shouldnt be a big problem for rbox to implement....
Chris
[edit]
i'm really looking forward to this
Click to expand...
Click to collapse
Thats one of the goals I put up there, just unlike rboxs current loader I know a way to make it remote controlled. ;D I started a bit on it. The "friendly user release" will have a root installer app that will handle multiboot, formating flash drives, recovery options, updates etc.
Really looking forward to a CM12 Android TV ROM. It would be nice to know that Amazon would not be able to kill a rooted Fire TV when this becomes reality. Peace of Mind regarding the Fire TV would be Priceless!
Xposed too http://forum.xda-developers.com/showthread.php?t=3030118
hhairplane said:
Xposed too http://forum.xda-developers.com/showthread.php?t=3030118
Click to expand...
Click to collapse
I'm a big fan of exposed, I'll have to add that to my testing list. I get a bit more free time tonight so I'll be getting back to looking at WiFi and Bluetooth and the installer. I still have two possible routes for both installing and updating i have to consider.
Sent from my LG-VM670 using XDA Free mobile app
TechVendetta said:
I'll link this here for now, while I finish looking into the logs for bluetooth/wifi/audio before uploading a rough copy here. I think I'm going to use the individuals who filled out the form to test the installer and recovery apps I'll be doing after fixing the above three things.
:victory:| TEASERS |:victory:
Click to expand...
Click to collapse
Any luck with the video acceleration, eg for Kodi or others such as Netflix, etc? How about hdmi audio?
Thanks for the update!
Video acceleration appears to be working, haven't got to audio. Had a death in the family this morning so i haven't had time to test my latest build.
Sent from my LG-VM670 using XDA Free mobile app
Sorry to hear that, Family is first! Although, maybe working on this will help take your mind away from that. Feel better!
TechVendetta said:
Video acceleration appears to be working, haven't got to audio. Had a death in the family this morning so i haven't had time to test my latest build.
Sent from my LG-VM670 using XDA Free mobile app
Click to expand...
Click to collapse
Sorry to hear that.
I recently installed CM 12 on a 2012 kfhd and wow!--it really brought that device to life! Performance/OC options are built right into the OS and another Dev made a custom kernel to oc to 1.7 ghz. But I have limited experience with CM and Android TV. Can we expect a similar UI and performance options with this? Or is it different for the set top boxes?
BTW--I think it's really great you're doing this. Lots of people are excited and it's very appreciated!!!
KLit75 said:
I recently installed CM 12 on a 2012 kfhd and wow!--it really brought that device to life! Performance/OC options are built right into the OS and another Dev made a custom kernel to oc to 1.7 ghz. But I have limited experience with CM and Android TV. Can we expect a similar UI and performance options with this? Or is it different for the set top boxes?
BTW--I think it's really great you're doing this. Lots of people are excited and it's very appreciated!!!
Click to expand...
Click to collapse
I can overclock the kernel but I'm not sure if it will be necessary yet. As for the features, CM12 doesn't even have a "stable" build yet. (they call them M builds now) They are still porting customizations like that in. That rom may use some stuff pulled in by the dev from other projects like paranoid, aokp etc. I'm listening to what people are asking for and I'll be taking it into consideration once I get to tweaking release candidates.
TechVendetta said:
I can overclock the kernel but I'm not sure if it will be necessary yet. As for the features, CM12 doesn't even have a "stable" build yet. (they call them M builds now) They are still porting customizations like that in. That rom may use some stuff pulled in by the dev from other projects like paranoid, aokp etc. I'm listening to what people are asking for and I'll be taking it into consideration once I get to tweaking release candidates.
Click to expand...
Click to collapse
Sounds great. Thinking now...an OC kernel probably isn't necessary since it's already real fast. But this rom I have works well on a relatively low end/older device. So I'm super excited about your project. Thanks again!
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
lionclaw said:
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
Click to expand...
Click to collapse
Wayyyy out of my area of expertise, but here's my (completely novice) best guess.
>All Chromebooks are write-protected with a screw on the motherboard
>Putting a Chromebook in developer mode allows for some tinkering ie things like chroots, and on the asus flip, the ability to install apks from unknown sources.
>Unscrewing the write-protect screw allows for the ability to completely install a new operating system or dual boot setup.
>Maybe you need to do that before you're able to accomplish root access?
My other idea would be to try and figure out a way of doing a systemless root?
Also, total aside but since this is the only thread I've found on XDA about this device, I think chroots are theoretically possible now without the need to be in developer mode via Android apps (even without root on Android). Download the GIMP port from the Play Store to see what I'm talking about. Playing around with that for a few minutes really made me wish that it didn't use emulated mouse/keyboard in it's implementation. Also, it appears that apt-get is broken, but regardless it might interest someone out there looking for a project.
back from the dead, any progress on this?
I have been able to successfully root the Android image on my Asus Flip.
I built a blank image with dd in /usr/local, formatted it with mkfs, mounted it to a folder, mounted the original system.raw.img to a folder, copied the files across, placed *all* the SuperSU files listed as 'required' in the SuperSU update-binary in the relevant places in /system in my new image, set permissions & contexts for those files, edited arc-system-mount.conf and arc-ureadahead.conf to point to the new image and, finally, patched /etc/selinux/arc/policy/policy.30 with the SuperSU sepolicy patching tool in order to boot my rooted Android instance with selinux set to enforcing.
I have created a couple of scripts which more-or-less fully automate this procedure, which can be downloaded from nolirium.blogspot.com. Please feel free to download, open the scripts in a text editor to check them out, and try them out if you like. Only tested on Asus Flip, though.
I seem to be unable to post attachments at the moment so I will just add the descriptions here, I could probably post the entire scripts here too if anyone wants. Feel free to let me know what you think.
DESCRIPTIONS:
1-3.sh
Combines the first three scripts listed below.
01Makecontainer.sh
Creates an 900MB filesystem image in /usr/local/Android_Images, formats it, then copies Android system files therein.
02Editconf.sh
Modifies two system files: arc-system-mount.conf - changing the mount-as-read-only flag and replacing the Android system image location with a new location; and arc-ureadahead.conf - again replacing the Android system image location. Originals are renamed .old - copies of which are also placed in /usr/local/Backup.
03Androidroot.sh
Mounts the previously created Android filesystem image to a folder, and copies SuperSU files to the mounted image as specified in the SuperSU update-binary.
04SEpatch.sh
Copies an SELinux policy file found at /etc/selinux/arc/policy/policy.30 to the Downloads folder, opens an Android root shell for the SuperSU policy patching command to be entered, then copies the patched policy back to the original location. A copy of the original policy.30 is saved at /etc/selinux/arc/policy/policy.30.old and /usr/local/Backup/policy.30.old
Uninstall.sh
Removes the folder /usr/local/Android_Images and attempts to restore the modified system files arc-system-mount.conf and arc-ureadahead.conf.
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
keithkaaos said:
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
Click to expand...
Click to collapse
The R13 has a 64-bit Mediatek processor, right?
I have added a version for ARM64, but I haven't tested it.
You can find the instructions and scripts at nolirium.blogspot.com
ya, its a mediatek. and thanks ill go see if i can find it
---------- Post added at 03:31 AM ---------- Previous post was at 02:58 AM ----------
wow, ok. i can do this but im not sure i want to.. after reading the possible problems i may run into. Im going to be getting the G. Home in a couple weeks and i gotta keep things running smooth. This seems like going a tad too far then i need to. The other day i had action launcher going and it looked pretty damn good but i really want to try and get the action3.apk that i have put into the pri-app folder or whatever the chromebook uses i found the syst folder but cant access it. Im wondering if i make the machine writable it would work but im afraid of losing my updates, as long as i could do them manualy, i guess that would be cool. Also since im already going on... has anyone found a way to disable the dev boot screen without tinkering with the physical chromebook yet?
SuperSU on Chromebook
Hey there I love this post but unfortunately im on the mediatek (well not unfortunately cause i love it) but i do really want super su .. But i found this other post that i tried out but i am having a problem executing the scripts. When i go to run the first one, it says can not open "name of script" but the dev takes a pretty cool approach. Im still new to Chrome OS but thanks for the post and if you have any advice on executing scripts id love to hear it!! http://nolirium.blogspot.com/
I'm guessing the above post was moved from another thread...
Anyway, it turns out that zipping/unzipping the files in Chrome OS's file manager sets all the permissions to read-only. Apologies! sudo chmod+x *scriptname* should fix it...
Regarding OS updates, I actually haven't had a problem receiving auto-updates with software write-protect switched off; the main possible potential issue I could imagine arising from the procedure I outlined would involve restoring the original conf files if both sets of backups get deleted/overwritten. This seems unlikely, but in that case either manually editing the files to insert the original string (/opt/google/containers/android/system.raw.img), or doing a powerwash with forced update might be necessary in order to get the original Android container booting again.
I don't think anyone's found a way to shorten/disable the dev boot screen without removing the hardware write-protect screw - from what I've read, the flags are set in a part of the firmware which is essentially read-only unless the screw is removed. Perhaps at some point the Chrome OS devs will get fed up of reading reports from users whose relatives accidentally reset the device by pressing spacebar, and change the setup. Here's hoping.
Hey just jumpig in the thread right quick to see if these instructions are old or what-- got a chromebook pro and the notion of having to update a squashed filesystem every timeto install su seems like a pain..
Is there any kind of authoritative documentation/breakdown regarding what Chromeos is mounting where before I start breaking things? Also anyone happen to know if there's a write-protect screw anywhere in the chromebook plus/pro?
Other questions:
* adbd is running, but is not accessible from adb in the (linux) shell, which shows no devices. Do I need to access adb from another device (i'm short a usb c cable right now) or can I use adb (which is there!) on the chrome side to access adbd on the android side?
* Anyone know if adb via tcp/ip is available? Don't see it in the android settings.
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
I'll attach them to this post in case anyone wants to take a look. There's a readme in the zip, some more details can also be found here and below
EDIT: Fixed the SE Linux issue occurring with the previous version I uploaded (it was launching daemonsu from u:r:init:s0 instead of u:r:supersu:s0).
Anyone considering giving them a spin should bear in mind that the method does involve creating a fairly large file on the device as a rooted copy of the android rootfs. (1GB for arm, 1.4GB for Intel). There's a readme in the zip but the other couple of important points are that:
a) The SuperSU 2.82 SR1 zip also needs to be downloaded and extracted to ~/Downloads on the Chromebook.
b) Rootfs verification needs to be off. The command to force this is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --force --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))
or the regular command to do it is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
c) If, subsequent to running the scripts, there's a problem loading Android apps (e.g. after a powerwash or failed install), the command to restore the original rootfs image is:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Hey this is a great response.. thanks!
Nolirum said:
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
Click to expand...
Click to collapse
verity
Yeah playing with it now, I'm looking at these /etc/init/arc-*-conf files... I see that the /dev/loop# files are being set up... (more below)
Nolirum said:
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
Click to expand...
Click to collapse
Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is? (update: I guess that's what rootfs verification does, and we can turn it off....)
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Nolirum said:
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
Click to expand...
Click to collapse
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Nolirum said:
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Click to expand...
Click to collapse
Heh.. not gonna be me..
Nolirum said:
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
Click to expand...
Click to collapse
Cool-- adb connect 100.115.92.2 does indeed work I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon... btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example... would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default witho no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...
Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while
Nolirum said:
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
Click to expand...
Click to collapse
Cool I'll take a look at these scripts.
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:
if [ -e /etc/init/arc-setup-env ]; then
echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"
This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf
Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
fattire said:
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:
if [ -e /etc/init/arc-setup-env ]; then
echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"
This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf
Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
Click to expand...
Click to collapse
Oh, the arc-setup-env thing is intentional. There does appear to be another issue with the x86 version though. I've written up a detailed response to your previous post; it's in a text file at the moment so I'll copy it over and format it for posting here with quotes etc now - should only take a few minutes. Yeah, sticking them on github might be a good idea; I've been meaning to create an account over there anyway.
Yeah, so... Regarding the scripts, since I've put them up here for people to download - I should mention that the first person to test them (aside from me) has reported that something's not working right (I'm waiting for confirmation but I think he tried out the x86 version). It's likely either an error on my part when copying across from my Arm version, or perhaps something not working right with conditionals, meant to deal with the various OS versions ('if; then' statements, I mean). Once I find out more, I'll edit my earlier post...
fattire said:
Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is?
Click to expand...
Click to collapse
Oh, sorry for being a bit vague - I just mean perhaps implementing a kind of systemless root à la Magisk/SuperSU (from what I understand of how these work) - avoiding the need to actually replace files in /system. Since I'm mainly just using su for the privileges rather than actually wanting to write to /system, I had the idea that perhaps a sort of overlay on e.g. xbin and a few other locations, rather than actually rebuilding the whole of /system, might be an interesting approach....
Yep, I've been replacing /opt/google/containers/android/system.raw.img with a symlink to my modified image lately. Works fine... I think they've been focused on just getting the apps working properly, maybe something like dm-verity is still to come.
Although, one of the cool things with Chromebooks IMO is that once the Developer Mode (virtual) switch has been flipped, the system's pretty open to being hacked around with. I think a large part of the much-trumpeted "security" of the system is thanks to the regular mode/Dev mode feature, once in Dev Mode with verified boot disabled on the rootfs, we can pretty much do what we want (I like the message that comes up in the shell when entering the first command I posted under the spoiler - it literally says "YOU ARE ON YOUR OWN!").
So yeah, with Dev Mode switched off, verified boot switched on, we can't even get into the shell (just the walled-off 'crosh' prompt), making the system indeed rather secure (but, for some of us, rather limited).
fattire said:
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Click to expand...
Click to collapse
That's what I mean by a moving target, lol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61. Problems with being on the more 'bleeding edge' channels include:
#Sometimes stuff gets broken as they commit experimental changes.
#Any updates sometimes overwrite rootfs customizations; the higher the channel - the more frequent the updates occur.
#Some of the stuff that gets updated, may later get reverted.
And so on...
fattire said:
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Click to expand...
Click to collapse
Yeah you'd think so. Honestly, the more I use CrOS the more it seems like a (very polished) work-in-progress to me. Though, I guess most modern OSs are also works-in-progress though. (I don't mean the former statement in a critical way; I'm very happy that new features keep getting added to the OS - Android app support being a perfect case in point, that was a lovely surprise, greatly extending the functionality of my Chromebook).
fattire said:
Cool-- adb connect 100.115.92.2 does indeed work I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon...
Click to expand...
Click to collapse
Netcat's not there but socat, which I haven't any experience with but have seen described as a "more advanced version of netcat", is listed in /etc/portage/make.profile/package.installable, meaning that adding it to CrOS is supported, and as simple as:
Code:
sudo su -
dev_install #(sets up portage in /usr/local)
emerge socat
I tried socat out and it seems to work, might be interesting to play around with.
fattire said:
btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example...
Click to expand...
Click to collapse
Theres a question. I forget some of the exact details now (gleaned from browsing the developer mailing lists and the documentation on chromium.org), but from what I do remember and my experiences tinkering, I can say:
The auto-update model uses kernel/rootfs pairs, e.g. at the moment my device is booting from partition 2 (KERN-A) with the rootfs being partition 3 (ROOTFS-B). My understanding is that with the next OS update pushed to my device, CrOS will download the deltas of the files to be changed, and apply the changes to partitions 4 and 5 (KERN-B and ROOTS-B), setting new kernel GPT flags (priority=, tries=, successful=), which will, post-reboot, let the BIOS know that 4 and 5 will form the new working kernel/rootfs pair. Then the following update will do the same, but with partitions 2 and 3, and so on and so forth, alternating pairs each time. It's a pretty nifty system, and I think something similar might be happening with new Android devices from version O onward (?).
So partitions 2,3,4,5 are fair game for being overwritten (from the perspective of the CrOS updater program). Partition 1, the 'stateful partition') is a bit special, in addition to a big old encrypted file containing all of the userdata (/home/chronos/ dir?), it also has some extra dirs which get overlaid on the rootfs at boot. If you have a look in /mnt/stateful/, there should also be a dir called 'dev_image', which (on a device in Dev mode) gets mounted up over /usr/local/ at boot. As I mentioned above, if you do
Code:
sudo su -
dev_install
you can then emerge anything listed in /etc/portage/make.profile/package.installable (not a great deal of stuff admittedly, compared to Gentoo), which gets installed to subdirs in /usr/local/. So I think stuff in partition 1; /mnt/stateful/, should be safe from being overwritten with an OS update. I think crouton chroots get put there by default.
Most of the other partitions don't really get used, and shouldn't get touched by the updater, here's a design doc on the disk format, and here's a Reddit post (from a Google/Chromium employee) mentioning dual booting from partitions 6 and 7.
fattire said:
would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
Click to expand...
Click to collapse
It's not too hard to mess up the system and get it into an unbootable state, lol. The "powerwash" just seems to remove user data, mainly. If you change up (the contents of) some files in /etc, or /opt, for example, then powerwash, normally they won't get restored to their original state (unless you also change release channel).
But, as long as the write-protect screw's not been removed and the original BIOS overwritten, it's always possible to make a recovery USB in Chrome's Recovery Utility on another device, and then restore the entire disk image fresh (this does overwrite all partitions). Another thing that I did was make a usb to boot into Kali; I was experimenting with the cgpt flags on my internal drive and got it into an unbootable state, but was still able to boot into Kali with Ctrl+U, and restore the flags manually from there. (To successfully boot from USB, it was essential to have previously run the enable_dev_usb_boot or crossystem dev_boot_usb=1 command in CrOS). I understand also that the BIOS type varies with device release date and CPU architecture, and that Intel devices may have some extra potential BIOS options ('legacy boot').
fattire said:
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default with no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...
Click to expand...
Click to collapse
I think I saw something related to this on the bug tracker. If I come across any info, I'll let you know...
fattire said:
Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while
Click to expand...
Click to collapse
Yeah, I haven't built Chromium OS or anything, but apparently, there's an option to create a 'private' overlay for the build, which doesn't get synced with the public stuff.
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
"That article is a little misleading in terms of open source. While the wayland-server and services that communicate with the ARC++ container are open source, the actual ARC++ container is not."
Perhaps they're waiting to see how similar implementations of Android within a larger Linux setup (e.g. Anbox) fare.
There doesn't seem to be too much that differs from AOSP in the ARC++ container - a few binaries and bits and pieces linking the hardware to the container (e.g. the camera etc), maybe some stuff related to running in a container with the graphics being piped out to Wayland?, and so on.
Oh, I was searching the bug tracker for something else, and just saw this (quoted below). Looks like it might be possible to run AOSP based images on CrOS soon!
arc: Implement android settings link for AOSP image
Reported by [email protected], Today (72 minutes ago)
Status: Started
Pri: 1
Type: Bug
M-60
When ARC started without the Play Store support there is no way for user to activate Android settings. We need implement corresponded section that has
Title: Android settings:
Link: Manage android preferences:
Inner bug: b/62945384
Click to expand...
Click to collapse
Great response! I read it once and I'll read it again in more detail then will probably have questions For whatever it may be worth, my only experience with chromiumos was building the whole thing maybe 4 years ago for my original 2011 Samsung "snow" Chromebook-- and making a bootable USB (or was it an SDcard?) to run it on (with a modified firmware that did... something I can't remember.. i think it was basically a stripped down uboot and I remember adding a simple menu or something-- I think I was trying to bypass that white startupscreen or something..). However, after doing this a few times to play with it, I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
I did have it re-partitioned to run linux as a dual boot from the SD slot or something-- I remember using that cgpt thing to select the different boot modes and vaguely recall the way it would A/B the updates (which "O" is now doing)... but anyhoo I was using the armhf ubuntu releases with the native kernel and ran into all kinds of sound issues and framebuffer only was a little crappy so...
I'm gonna re-read in more detail soon and I'm sure I'll have questions-- one of which will be-- assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
ol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61.
Click to expand...
Click to collapse
This is the -env file I'm missing, I presume?
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
Click to expand...
Click to collapse
It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?
Here's what I'd ideally like to see:
* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos
* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...
* what else... I dunno watch this space.
An update from a couple of guys that have tested out the scripts on Intel: It seems to be that while they are able to launch daemonsu manually (with daemonsu --auto-daemon), it apparently does not seem to be getting launched at boot.
I am waiting for some more information on this. Previously, for Marshmallow, the script was setting up the app_process hijack method in order to to launch daemonsu at boot; to support Nougat I changed it to instead create an .rc file with a service for daemonsu, and add a line to init.rc importing it. This works for me, and from what I can gather, it copied/created all files successfully on the testers devices, too, so I'm not sure at this point what the issue is there.
Edit: Fixed the issue. I updated my previous post with further details.
fattire said:
I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
Click to expand...
Click to collapse
lol yeah. True, that.
fattire said:
...assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
Click to expand...
Click to collapse
It's literally just two things that differ: the few lines where we copy the su binary over e.g.
/x86/su.pie → /system/xbin/su, daemonsu, sugote
vs
/armv7/su → /system/xbin/su, daemonsu, sugote
...and also the size of the created container. The x86 container is about 30 percent larger than the Arm one.
I had a little look at how to determine the CPU architecture programmatically on Chrome OS a while back, but couldn't seem to find a reliable way of doing this, at least not without maybe getting a bunch of people with different CrOS devices to run something like, as you mentioned, uname -i (which returns 'Rockchip' on my device, uname -m (which returns 'armv7'), or such similar, and collating the results. It was just easier to do separate versions for x86/arm, rather than introduce more conditionals (with potential for errors). I'm certainly not averse to adding a check for $ARCH, and thus standardizing the script, as long as it's reliable.
fattire said:
This is the -env file I'm missing, I presume?
Click to expand...
Click to collapse
Yep! It's just the same few envs as in the .confs, moved into a new file. I'm fairly confident that the script's conditionals deals with them OK.
fattire said:
It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?
Click to expand...
Click to collapse
Yeah, although the respondant there perhaps doesn't seem to realise that he's talking to a Google/Chromium dev, the way he responds. Not that that makes anything he says in his post is necessarily less valid, though.
fattire said:
Here's what I'd ideally like to see:
* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos
* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...
Click to expand...
Click to collapse
Interesting... I agree, those would both be useful additions to the functionality of ARC++...
Quick question-- has Samsung provided the source for the GPL components (including the kernel, obviously)? I looked here but didn't see anything...? Previously the kernel was included along with the chromium source and there was like a kernel and kernel-next repository.. but this was like five years ago. I think the codename for the samsung chromebook pro is called caroline... let me quickly see if I can find a defconfig in the chromium source...
Back.. nothing here in the chromeos-4.4 branch. Nothing here either in the master branch. Maybe I'm looking in the wrong branches-- master is probably mainline kernel. Also the directories.. it took me five minutes to realize it wasn't going to be in arch/arm - force of habit I guess. I'll keep looking unless anyone knows. This "chromium-container-vm-x86" one seems to have dm_verity as an unused option. Ah, this is looking promising.
...and... here!
So it would seem that this would be built as part of the chromiumos build system, which seemed to be half gentoo five years ago building out of a chroot and was kind of a pain to set up... still, I'm guessing that since it's got that weird script to make the defconfig, what you could do is use google's chromiumos build script to make the kernel image (with whatever changes you want), then, assuming that it doesn't care if you replace the kernel, just throw it over the right Kernel A/B partition and see if it boots and starts up chromeos... it's weird cuz the kernel has to do double-duty for chromeos and android.. but I bet you can just replace it and it would work fine...
I had a cursory go at building a couple of kernel modules for my Flip C100 a while back - I didn't get too far though, lol. People do seem to have had success building their own kernels and running them with Chrome OS though, as with most things I suppose it's just how much time/effort you're willing to put in.
I think I used this and maybe this, from the crouton project to guide me.
From what I remember, I just got fed up of all the arcane errors/config choices. I remember that even though I'd imported my current device config from modprobe configs, there were then such an incredibly long string of hoops/config choices to have to go through one by one, to then be confronted with various errors (different every time ISTR) that I think I just thought "screw this". I think there were some other issue with the Ubuntu version I was using at the time as well. I know that sort of stuff's kind of par for the course with kernel compilation, but I was mainly only doing it so I could edit xpad in order to get my joypad working, in the end I found a different solution.
It shouldn't be too much hassle though, in theory I guess.... Oh, also, in order to get a freshly built kernel booting up with the CrOS rootfs, in addition to the gpt flags, I think you might have to sign it, too? (just with the devkeys & vbutil_kernel tool provided on the rootfs), some info here, and here.
From what I remember, the build system would do whatever key signing was necessary.... although I do now remember you're right there was some manual step when I was building the kernel, but I can't remember if that's because of MY changes or that was just part of the build process.
I I just dug out the old VM (Xubuntu) I was using to build and, well, let's just say I'll be doing a LOT of ubuntu updates before I can even realistically look at this. I do kinda recall setting up the environment was a huge pain so I'm going to see if I can just update the 5 year old source, target the pro and just build the kernel image and see what pops out the other end. At least I won't have to deal with the cross compiler, though I think it should hopefully take care of that itself.
Interesting to see that those crouton projects have emerged (no pun intended) so I'll check them out too while ubuntu updates itself
Thanks for the github links.. I'm going to go read that wiki.
Update: Looked at it-- funny they just stripped out the chromeos-specific parts they needed rather than emerge everything which is smart. My only question is now that Android is involved, there's that script I linked to earlier that seems to say "if you want Android support you'll need these bits too"-- wonder if the same config scripts apply, and if there are any other device tree considerations as well...
I may play a bit and see how smoothly it goes.. Unfortunately I don't have unlimited time either :/
Also, please do let me know if you put the scripts on github and I can send you pull requests if I come up with anything.
Update: Finally updated like 3 major versions of ubuntu... the "depot_tools" repo had its last commit in 2013, so I updated that. Wow, this is so much clearer than previous docs... it looks like something called gclient is used now, which I configured with:
gclient config --spec 'solutions = [
{
"url": "https://chromium.googlesource.com/chromium/src.git",
"managed": False,
"name": "src",
"deps_file": ".DEPS.git",
"custom_deps": {},
},
]
'
that let me do gclient sync --nohooks --no-history ...which i think is updating the ancient source. I probably should have just started over, but anyway... we'll see what happens.
Update again: After updating with this new gclinet tool, it appears that the old repo sync method is still required as described here. That hasn't changed after all, so now I'm going to go through this old method, which will probably completely overwhelm my storage as it's downloading with history.. but anyway, in case anyone is trying this-- looks like the whole chroot/repo sync thing may still be how it's done... the /src directory described above may only be for building just the browser, not the whole OS...
...and here it is. I will have zero room to actually build anything tho, but hey.
* [new branch] release-R58-9334.B-caroline-chromeos-3.18 -> cros/release-R58-9334.B-caroline-chromeos-3.18
Note to self: use cros_sdk --enter to actually get in the chroot. Then:
~/trunk/src/scripts $ ./setup_board --board=caroline
to set up the build for caroline. Then to build:
./build_packages --board=caroline --nowithdebug
Useful links:
* Building ChromiumOS
* [URL="http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq"]eBuild FAQ
[/URL]
"Blobs" are the files specific to each device that we need in order to compile custom ROMS that work on our device. The process of finding them is tedious and slow... I have been picking away at them for months when I have time. There are over 600 files so far! But there are also references to files that are not being found. They are either missing, or they are not located where they are expected to be located. This is where I need help.
So, if you want to help, go HERE:
https://github.com/mightysween/android_vendor_motorola_payton
and look through the proprietary-files.txt file for anywhere that it says "warning".... and then search inside of the firmware (working on 8.0+ now, not 7.1 please) and try to track down the file that it says is missing [obviously, you will need a system dump, or to search on a rooted device]. If you find it, please post below like this:
LINE NUMBER OF THE WARNING (from github)
PATH TO THE MISSING FILE (relative to /system... in other words, don't inlude your own local path)
Once this file is complete, we can use it to automatically pull the correct vendor files into our build environments... having a working recovery, active kernel developement and completed vendor blobs should open us up to more development efforts.
Also, if anyone has done any testing and knows of other proproetary files that are needed, please post them here so I can include them.
My time at the computer to work on this is really limited, so I have only identified a dozen or so daemons that definitely call for proprietary libs... I am sure there are more
I would love to pitch in on this but have zero experience with anything related to development. Do you think I could still be of help? Sounds like a basic enough task that it wouldn't be too difficult. Let me check and see that I understand the process.
Went to github and looked at proprietary-files.txt. The first warning I found was in line 49: "blob file libpn553_fw.so missing or broken". Then searched for that file in my device's system folder using ES File Explorer with Root Explorer enabled.
So is this what you're looking for?
49
/system/vendor/firmware/libpn553_fw.so
---------- Post added at 14:31 ---------- Previous post was at 14:07 ----------
I'd like to contribute in some way but if this is best not left to a complete noob then I totally understand
mightysween said:
Also, if anyone has done any testing and knows of other proproetary files that are needed, please post them here so I can include them.
My time at the computer to work on this is really limited, so I have only identified a dozen or so daemons that definitely call for proprietary libs... I am sure there are more
Click to expand...
Click to collapse
Do you have a link to a system dump?
TheBassDude said:
I would love to pitch in on this but have zero experience with anything related to development. Do you think I could still be of help? Sounds like a basic enough task that it wouldn't be too difficult. Let me check and see that I understand the process.
Went to github and looked at proprietary-files.txt. The first warning I found was in line 49: "blob file libpn553_fw.so missing or broken". Then searched for that file in my device's system folder using ES File Explorer with Root Explorer enabled.
So is this what you're looking for?
49
/system/vendor/firmware/libpn553_fw.so
---------- Post added at 14:31 ---------- Previous post was at 14:07 ----------
I'd like to contribute in some way but if this is best not left to a complete noob then I totally understand
Click to expand...
Click to collapse
Thanks, that is all there is to it
Just time consuming (especially after the first 500)...lol
QWZR said:
Do you have a link to a system dump?
Click to expand...
Click to collapse
Nah, too big to conveniently upload... but if you are rooted, you can use the phone to search
mightysween said:
Nah, too big to conveniently upload... but if you are rooted, you can use the phone to search
Click to expand...
Click to collapse
Mine gets here next week
mightysween said:
Nah, too big to conveniently upload... but if you are rooted, you can use the phone to search
Click to expand...
Click to collapse
If you have root on the system you can find the files for, you should be able to find any given filename with:
find / -name "filename" -print
And it should output any filenames that match. I don't have time at the moment to dig into this any more, but would this resolve much of it?
ebrandsberg said:
If you have root on the system you can find the files for, you should be able to find any given filename with:
find / -name "filename" -print
And it should output any filenames that match. I don't have time at the moment to dig into this any more, but would this resolve much of it?
Click to expand...
Click to collapse
Any way that works is fine by me
I am on the road a lot and just don't have enough time to sit and work on it... so it is taking months. I bet a few people helping could finish it in a matter of hours.
I am hoping to have a few hours next week to work on it. But the sooner this is done, the sooner I can shift to trying to compile Lineage OS with working hardware.
BTW, Lineage *does* compile if I comment out all the stuff causing make errors... not much works, obviously.
The next step will be compiling with these blobs, then logging all the new errors and chasing down all the additional broken symlinks... and then adapting the kernel as needed.
Then, MAYBE we can get a base Lineage tree up and open up the X4 to building for other roms. I know someone started a skeleton tree for Carbon already on Github... they are likely just waiting for the completed device tree, too.
mightysween said:
Thanks, that is all there is to it
Just time consuming (especially after the first 500)...lol
Click to expand...
Click to collapse
ebrandsberg said:
If you have root on the system you can find the files for, you should be able to find any given filename with:
find / -name "filename" -print
And it should output any filenames that match. I don't have time at the moment to dig into this any more, but would this resolve much of it?
Click to expand...
Click to collapse
I don't own this device yet, but I was thinking of getting one. I figured this might help you all out (you'll need to be running linux):
First, let's get a list of all the files on the phone, to make searching faster.
Code:
adb shell
su
find / > /sdcard/allfiles.txt
exit
exit
adb pull /sdcard/allfiles.txt
Now you should have allfiles.txt on your machine. Also grab the proprietary-files.txt, and then run this:
Code:
grep -Po '(?<=(blob file )).*(?= missing or broken)' proprietary-files.txt | xargs -I @ grep "@" allfiles.txt
That should find the paths of all the missing files (except the ones marked "wildcard")
BLuFeNiX said:
I don't own this device yet, but I was thinking of getting one. I figured this might help you all out (you'll need to be running linux):
First, let's get a list of all the files on the phone, to make searching faster.
Code:
adb shell
su
find / > /sdcard/allfiles.txt
exit
exit
adb pull /sdcard/allfiles.txt
Now you should have allfiles.txt on your machine. Also grab the proprietary-files.txt, and then run this:
Code:
grep -Po '(?<=(blob file )).*(?= missing or broken)' proprietary-files.txt | xargs -I @ grep "@" allfiles.txt
That should find the paths of all the missing files (except the ones marked "wildcard")
Click to expand...
Click to collapse
Thanks, I had recently completed this, but your code worked fantastic for double checking, and actually helped me find one that I had missed :good:
Now, on to identifying any more daemons that need proprietary files... and then assembling the tree itself... PROGRESS!
PHASE 1 is complete!
https://github.com/mightysween/android_vendor_motorola_payton
I am 99% sure that this is only ~75% of what will be needed to actually build LOS15. But it is a good foundation to work off of now.
My plan is to start attempting to compile LOS and take error logs to chase down the remaning missing stuff. LOTS to be done still to get to that point...hoping for some other builders/devs to materialize here and help out
Hi! Just a question: it´s mandatory to use A/B partition scheme to build a custom ROM for this device or it will be possible to use a traditional partition scheme and free up some GBs of internal storage for use?
christianrj said:
Hi! Just a question: it´s mandatory to use A/B partition scheme to build a custom ROM for this device or it will be possible to use a traditional partition scheme and free up some GBs of internal storage for use?
Click to expand...
Click to collapse
It would seem that we will still be stuck with A/B, as the bootloader does the initial check of the active slot. Perhaps there may be some clever ways around this in the future...but nothing I will be tackling.
mightysween said:
It would seem that we will still be stuck with A/B, as the bootloader does the initial check of the active slot. Perhaps there may be some clever ways around this in the future...but nothing I will be tackling.
Click to expand...
Click to collapse
You would probably need a custom kernel to do it properly. The bootloader passes a kernel param (androidboot.ro.boot.slot_suffix) specifying which slot to use. In the absense of a kernel param, the value is read from the ro.boot.slot_suffix build property.
That being said, you might be able to just repartition your device to only have 1 slot, flash your ROM, and use
Code:
fastboot --set-active=_a
. If your ROM has disabled OTA updates from the OEM, you should be fine.
I'm going to get an X4 in the coming weeks. I'd like to help with this soon. I'm a seasoned developer by trade and can collab on GitHub. Hope to be able to start working with you soon. :good:
I don't know if any of you have seen this article, but it seems promising that it might not be too difficult to achieve for this device:
https://www.xda-developers.com/xiaomi-redmi-note-4-project-treble/
Hariiiii said:
I don't know if any of you have seen this article, but it seems promising that it might not be too difficult to achieve for this device:
https://www.xda-developers.com/xiaomi-redmi-note-4-project-treble/
Click to expand...
Click to collapse
@vache at the Moto G5 Plus forums has already managed it using the /oem partition which is otherwise unused for custom ROMs
Hariiiii said:
I don't know if any of you have seen this article, but it seems promising that it might not be too difficult to achieve for this device:
https://www.xda-developers.com/xiaomi-redmi-note-4-project-treble/
Click to expand...
Click to collapse
Cool... seems it may be possible. Will follow the progress on the Redmi and G5 devices
navenedrob said:
I'm going to get an X4 in the coming weeks. I'd like to help with this soon. I'm a seasoned developer by trade and can collab on GitHub. Hope to be able to start working with you soon. :good:
Click to expand...
Click to collapse
The more I am reading about enabling Treble, the more I think it is entirely possible.... and probably the best direction to focus our efforts.
Seems like we have partitions that could be used as /vendor. I am reading up on exactly how the Treble vendor partition is set up. Tricky, but not implausible.
EDIT: Actually, none of the partitions we could potentially re-purpose for /vendor are big enough. So, it may be harder on this device than on others. It may require repartitioning.
crDroid 6.2 ROM 15-01-2020
There's no guarantee nothing, don't use it if you don't know what you're doing!
SAVE your DATA before!
Make sure you have a custom recovery installed (TWRP is the preferred recovery. [I'm not using Fox recovery, I'm not going to give you advice.])
Boot into recovery
Wipe data, cache partitions to clean install. Wipe dalvik, cache to update previous crDroid.
(If your /data partition secured, maybe need format /data if you want to use this ROM.)
Flash Rom in TWRP (sideload or copy any storage)
Flash OpenGapps (Optional) [I'm not using GAPPS, I'm not going to give you advice.]
Flash Magisk Root (Optional) [I'm not using Magisk, I'm not going to give you advice.]
Reboot (If TWRP warn that there is no system, it doesn't matter, go reboot.)
First boot may take up to 1 minute.
DOWNLOAD SF
DOWNLOAD AD
All ROMs here: LINK
Known issues: don't know
*
Screenshots: LINK
OS source: LINK Many thanks to adi153!
ROM OS Version: 10.x Q
ROM Kernel: Linux 3.18.140 (not my work)
ROM info: Q10 Lineage-17.1, system_root partition, Android quota removed (easier to go back to earlier 7.x-9.x ROMs).
If you have previously used Android 9.x or 10.x ROM which has a quota set on the data partition, you can remove the quota in TWRP, and not need format the data partition (this method tested, working was for me, but no guarantee for by all means)
commands:
Code:
tune2fs -O ^quota /dev/block/bootdevice/by-name/userdata
tune2fs -Q ^usrquota,^grpquota /dev/block/bootdevice/by-name/userdata
If you then use a ROM that configures quota (fstab.qcom), you can start over, if do not want quota. Or cleaning from fstab: "quota".
Created 24-12-2019 6.0 version
Last Updated 15-01-2020 6.2 (build3)
I am not aware that it contains malicious code in the ROM, I have never put it in. This is a ported ROM, all its elements come from the Internet.
You're welcome.
New build 15.01.2020, & many changes to the system. I'd like to get feedback on whether VOLTE is working? Thanks.
SYS update V1 out: 14-01-2020
Something wrong with the system updates, I moved it to the test directory.
Nice
Wow, a new rom... Thanks szanalmas, will give feedback after testing it
@szanalmas
Edit: Already tested your rom, so stable and smooth...
But found some small bug (doesn't really matter anyway but you may need know):
-At first boot/crdroid setup wizard, email exchange request permission but when i grant it permission manager crash (but back normal after that)
-When i change the hardware button function to screenshot... The Setting app will crash and back to main menu
Just that, still looking for other
Big thanks again for this nice rom
(Sorry for my bad english :v)
@szanalmas thanks ...for stable ROM.
---------- Post added at 04:18 AM ---------- Previous post was at 04:00 AM ----------
From long time i was waiting for stable ROM. Thanks for your hard work.
@szanalmas thanks for make stable ROM :good:
while there are no bugs,
if there are bugs
I'll tell you later
thanks man i like crdroid
rom stable smooth did not find any bug after 2 hours use
Fadly357 said:
But found some small bug (doesn't really matter anyway but you may need know):
-At first boot/crdroid setup wizard, email exchange request permission but when i grant it permission manager crash (but back normal after that)
-When i change the hardware button function to screenshot... The Setting app will crash and back to main menu
Click to expand...
Click to collapse
Thanks for the feedback!
I didn't know about the first bug, probably because I have always denied email permissions in the wizard. I have bad habits!
I knew about the second bug, some of the function settings on the buttons don't work.
Unfortunately, these bugs are in the official ROM, but I think they will be fixed over time.
And of course, the SD card camera and gallery permission bugs have remained, but the solution is to use internal storage for the time being.
szanalmas said:
Thanks for the feedback!
I didn't know about the first bug, probably because I have always denied email permissions in the wizard. I have bad habits!
I knew about the second bug, some of the function settings on the buttons don't work.
Unfortunately, these bugs are in the official ROM, but I think they will be fixed over time.
And of course, the SD card camera and gallery permission bugs have remained, but the solution is to use internal storage for the time being.
Click to expand...
Click to collapse
Okay, will tell you as soon as possible if i found other
could you teach me rom build? i wanna learn and help
@szanalmas
About your ported TWRP, can you install magisk? When i use your TWRP to install magisk, the magisk installation failed, says it can mount vendor which is same as cust, right?
viethoang18 said:
could you teach me rom build? i wanna learn and help
Click to expand...
Click to collapse
Sorry I can't give you guidance. I'm not building ROM, I'm just porting. If you really want to build ROM, I recommend the ViperOS developers, this was the only Official build for this phone (7.1.2). Building a ROM requires 3 things, the kernel, vendor, and AOSP. Since phone manufacturers largely do not make their source code public, their construction is tremendously laborious and time consuming.
If you want to port, it is highly recommended that you know Linux, which is quite a bit of time and energy. Actually, you need to learn the basics of linux for Android, but at least to the point where you can already interpret log error messages.
I don't know if you use linux, if you don't and you want to start with it, install linux, configure it well, and compile a linux kernel for ugglite, which starts with ROM 10. If you want to go hard, thoroughly, and deeper, do it all without installing a linux graphical interface. I don't really know how much time it takes to easily manage Linux. How to port Android 10 on windows I don't know, but I think it's not easy.
And on top of that, Android has some specific changes that are different from the Linux system, so you also have to get to know Android so.
And now we're just about to boot on Linux based Android, on the DalvikVM running applications is another world with lots of Java code.
For all this, there is no guide to doing this or that, you need to apply knowledge in a complex way.
I only do this on a hobby level.
Fadly357 said:
@szanalmas
About your ported TWRP, can you install magisk? When i use your TWRP to install magisk, the magisk installation failed, says it can mount vendor which is same as cust, right?
Click to expand...
Click to collapse
I once used the magisk in TWRP but not this ROM. It worked for some.
But I didn't write in my post on my TWRP either now.
(I don't use magisk now.)
Use Canary: LINK
Or whatever.
szanalmas said:
Sorry I can't give you guidance. I'm not building ROM, I'm just porting. If you really want to build ROM, I recommend the ViperOS developers, this was the only Official build for this phone (7.1.2). Building a ROM requires 3 things, the kernel, vendor, and AOSP. Since phone manufacturers largely do not make their source code public, their construction is tremendously laborious and time consuming.
If you want to port, it is highly recommended that you know Linux, which is quite a bit of time and energy. Actually, you need to learn the basics of linux for Android, but at least to the point where you can already interpret log error messages.
I don't know if you use linux, if you don't and you want to start with it, install linux, configure it well, and compile a linux kernel for ugglite, which starts with ROM 10. If you want to go hard, thoroughly, and deeper, do it all without installing a linux graphical interface. I don't really know how much time it takes to easily manage Linux. How to port Android 10 on windows I don't know, but I think it's not easy.
And on top of that, Android has some specific changes that are different from the Linux system, so you also have to get to know Android so.
And now we're just about to boot on Linux based Android, on the DalvikVM running applications is another world with lots of Java code.
For all this, there is no guide to doing this or that, you need to apply knowledge in a complex way.
I only do this on a hobby level.
Click to expand...
Click to collapse
can i use Unbutu wls on windows ?
@szanalmas I flashed this ROM.
ULTRA SMOOTH... NO SERIOUS BUG, SOMETIMES AUTO BRIGHTNESS RESPONSE SLOWLY. Suddenly high brightness automatically. Another issue with attached sd card asking for format.
"Issue with sandisk SD Card"
Its for daily use is ok.
bug, when enabling ambient display d2tw stopped not wroking after disable ambient dt2w work again
Thank you very much feedbacks and thanks to everyone! :good:
Call volume on speaker is very high by default
@szanalmas Call volume on speaker is very high by default. Please set lower level by default. I hope in new build it willbe resolve.
Thanks...
ahmedhelmy71 said:
bug, when enabling ambient display d2tw stopped not wroking after disable ambient dt2w work again
Click to expand...
Click to collapse
This is what LINK is all about, and I still hold that the double-tap feature cannot be used for two things at once. What's interesting is that I can't find the ambient display double-tap menu option, and there's a separate one in Havoc ambient settings.
This is also an Official bug unfortunately.
*
cpglbitm said:
@szanalmas I flashed this ROM.
ULTRA SMOOTH... NO SERIOUS BUG, SOMETIMES AUTO BRIGHTNESS RESPONSE SLOWLY. Suddenly high brightness automatically. Another issue with attached sd card asking for format.
"Issue with sandisk SD Card"
Its for daily use is ok.
Click to expand...
Click to collapse
The SD card problem is very-very interesting.
What filesystem is in sd card?
Could you send us a logcat digest right after the phone is started?
Code:
adb logcat | grep vold > sdcardproblem.txt
viethoang18 said:
can i use Unbutu wls on windows ?
Click to expand...
Click to collapse
I don't know. I haven't used Windows for years, sorry.