I don't see anyone else posting here about it, so I just wanted to provide you guys with something to start out with.
First things first: Full Untouched ROM | Brokenly Debloated ROM
The Full Untouched ROM is exactly as it says, the ROM is extracted directly from the source and the permissions were set using the result of `ls -kR` and `ls -lnR` on an installed version of the ROM (see below for scripts). The Brokenly Debloated ROM does not have a functional Gallery (tbh, I probably just debloated too hard, and now I'm not sure which one was the essential one, something something camera3d.remote.nearby.Nearby??, but I don't use the Gallery, nor the Camera, so I removed them with TWRP's file manager), and I removed basically all the features that don't interfere with Wifi Calling (including Inprivate, Fingerprint, most of the Noto fonts removed (which support international fonts), removed all but 1 type of sound in each file, removed boot sound, removed even the Calculator) and then removed some of the things I don't like about stock. See below guides for more information. If you also happen to share my tastes and like it when there is almost nothing installed on your phone, then you should definitely try out the Broken Debloated ROM (it's actually very stable minus the Gallery), but if you want things like the Gallery or a Calculator or international fonts, find a different ROM, or take the Full one and debloat it.
Ok now, the good (and different) things about Marshmallow, and the things that I'm sure all you developers will like. (Note, this is for the Full ROM and should work with any Stock ROM, the Debloated version already has these applied).
Removing Knox info from Settings
Edit `/system/buildprop`, replace `ro.config.knox=v30` with `ro.config.knox=0`.
Yep, that's all, no patching, no fancy apktool baksmali magic requiring deodex.
Removing the S-Finder/QuickConnect Bar
Just delete `/system/etc/permissions/com.sec.feature.findo.xml`
Again, no patching.
Call Recording (this one isn't really new, it was more or less the same even in the past, but I included it anyways)
Add `<CscFeature_VoiceCall_ConfigRecording>RecordingAllowed</CscFeature_VoiceCall_ConfigRecording>` to `/system/csc/others.xml` anywhere between the `<FeatureSet> ... </FeatureSet>` tags.
I don't plan on searching for more, this is pretty comprehensive for my desires as it is, but if I happen to find them, I'll update this post.
Scripts
Note: this section is most likely unnecessary, since the updater-script already contains all of the below.
Links.hs opens "user.txt" and generates all the symlinks you need and outputs it to stdout.
Combine.hs opens "user.txt" and "sec.txt" and combines them so that the security contexts and permissions are in the same stream of text and outputs it to stdout.
Permissions.hs opens "allfiles.txt" and generates all the set_metadata requried arguments and outputs it to stdout.
If you want just the updater-script, it's also attached, all of the text from lines 24-123 were autogenerated by concatenating the outputs of Links.hs and Permissions.hs.
Also, as you can see, root is not included, but to be completely honest, the only thing I used to use root for was blocking ads. So I also including the Adblocker recovery-flashable zip I'm using (hosts file from here, updated as of 2016-05-24). It works even when SELinux is set to enforcing by properly updating the metadata (which it is in the ROMs posted in this thread).
thanks for syms
rmanne said:
I don't see anyone else posting here about it, so I just wanted to provide you guys with something to start out with.
First things first: Full Untouched ROM | Brokenly Debloated ROM
The Full Untouched ROM is exactly as it says, the ROM is extracted directly from the source and the permissions were set using the result of `ls -kR` and `ls -lnR` on an installed version of the ROM (see below for scripts). The Brokenly Debloated ROM does not have a functional Gallery (tbh, I probably just debloated too hard, and now I'm not sure which one was the essential one, something something camera3d.remote.nearby.Nearby??, but I don't use the Gallery, nor the Camera, so I removed them with TWRP's file manager), and I removed basically all the features that don't interfere with Wifi Calling (including Inprivate, Fingerprint, most of the Noto fonts removed (which support international fonts), removed all but 1 type of sound in each file, removed boot sound, removed even the Calculator) and then removed some of the things I don't like about stock. See below guides for more information. If you also happen to share my tastes and like it when there is almost nothing installed on your phone, then you should definitely try out the Broken Debloated ROM (it's actually very stable minus the Gallery), but if you want things like the Gallery or a Calculator or international fonts, find a different ROM, or take the Full one and debloat it.
Ok now, the good (and different) things about Marshmallow, and the things that I'm sure all you developers will like. (Note, this is for the Full ROM and should work with any Stock ROM, the Debloated version already has these applied).
Removing Knox info from Settings
Edit `/system/buildprop`, replace `ro.config.knox=v30` with `ro.config.knox=0`.
Yep, that's all, no patching, no fancy apktool baksmali magic requiring deodex.
Removing the S-Finder/QuickConnect Bar
Just delete `/system/etc/permissions/com.sec.feature.findo.xml`
Again, no patching.
Call Recording (this one isn't really new, it was more or less the same even in the past, but I included it anyways)
Add `<CscFeature_VoiceCall_ConfigRecording>RecordingAllowed</CscFeature_VoiceCall_ConfigRecording>` to `/system/csc/others.xml` anywhere between the `<FeatureSet> ... </FeatureSet>` tags.
I don't plan on searching for more, this is pretty comprehensive for my desires as it is, but if I happen to find them, I'll update this post.
Scripts
Note: this section is most likely unnecessary, since the updater-script already contains all of the below.
Links.hs opens "user.txt" and generates all the symlinks you need and outputs it to stdout.
Combine.hs opens "user.txt" and "sec.txt" and combines them so that the security contexts and permissions are in the same stream of text and outputs it to stdout.
Permissions.hs opens "allfiles.txt" and generates all the set_metadata requried arguments and outputs it to stdout.
If you want just the updater-script, it's also attached, all of the text from lines 24-123 were autogenerated by concatenating the outputs of Links.hs and Permissions.hs.
Also, as you can see, root is not included, but to be completely honest, the only thing I used to use root for was blocking ads. So I also including the Adblocker recovery-flashable zip I'm using (hosts file from here, updated as of 2016-05-24). It works even when SELinux is set to enforcing by properly updating the metadata (which it is in the ROMs posted in this thread).
Click to expand...
Click to collapse
Hi rmanne. Thanks for the debloated ROM. It runs very smoothly.
About the broken gallery, unfortunately I still need it. I looked into the exception thrown by the gallery, and looks like it is because some AllShare classes are missing in the classpath. However, I can't find out which file you removed contains these classes (none of the apks from /system/app/AllShare* works). Do you happen to know? Thanks!
rmanne said:
I don't see anyone else posting here about it, so I just wanted to provide you guys with something to start out with.
First things first: Full Untouched ROM | Brokenly Debloated ROM
The Full Untouched ROM is exactly as it says, the ROM is extracted directly from the source and the permissions were set using the result of `ls -kR` and `ls -lnR` on an installed version of the ROM (see below for scripts). The Brokenly Debloated ROM does not have a functional Gallery (tbh, I probably just debloated too hard, and now I'm not sure which one was the essential one, something something camera3d.remote.nearby.Nearby??, but I don't use the Gallery, nor the Camera, so I removed them with TWRP's file manager), and I removed basically all the features that don't interfere with Wifi Calling (including Inprivate, Fingerprint, most of the Noto fonts removed (which support international fonts), removed all but 1 type of sound in each file, removed boot sound, removed even the Calculator) and then removed some of the things I don't like about stock. See below guides for more information. If you also happen to share my tastes and like it when there is almost nothing installed on your phone, then you should definitely try out the Broken Debloated ROM (it's actually very stable minus the Gallery), but if you want things like the Gallery or a Calculator or international fonts, find a different ROM, or take the Full one and debloat it.
Ok now, the good (and different) things about Marshmallow, and the things that I'm sure all you developers will like. (Note, this is for the Full ROM and should work with any Stock ROM, the Debloated version already has these applied).
Removing Knox info from Settings
Edit `/system/buildprop`, replace `ro.config.knox=v30` with `ro.config.knox=0`.
Yep, that's all, no patching, no fancy apktool baksmali magic requiring deodex.
Removing the S-Finder/QuickConnect Bar
Just delete `/system/etc/permissions/com.sec.feature.findo.xml`
Again, no patching.
Call Recording (this one isn't really new, it was more or less the same even in the past, but I included it anyways)
Add `<CscFeature_VoiceCall_ConfigRecording>RecordingAllowed</CscFeature_VoiceCall_ConfigRecording>` to `/system/csc/others.xml` anywhere between the `<FeatureSet> ... </FeatureSet>` tags.
I don't plan on searching for more, this is pretty comprehensive for my desires as it is, but if I happen to find them, I'll update this post.
Scripts
Note: this section is most likely unnecessary, since the updater-script already contains all of the below.
Links.hs opens "user.txt" and generates all the symlinks you need and outputs it to stdout.
Combine.hs opens "user.txt" and "sec.txt" and combines them so that the security contexts and permissions are in the same stream of text and outputs it to stdout.
Permissions.hs opens "allfiles.txt" and generates all the set_metadata requried arguments and outputs it to stdout.
If you want just the updater-script, it's also attached, all of the text from lines 24-123 were autogenerated by concatenating the outputs of Links.hs and Permissions.hs.
Also, as you can see, root is not included, but to be completely honest, the only thing I used to use root for was blocking ads. So I also including the Adblocker recovery-flashable zip I'm using (hosts file from here, updated as of 2016-05-24). It works even when SELinux is set to enforcing by properly updating the metadata (which it is in the ROMs posted in this thread).
Click to expand...
Click to collapse
I'm coming from Android 6.0.1 via CyanogenMod 13.0. Do I need to also flash a modem and/or other key parts before this ROM will work?
Thanks!
Yes
Sent from my SM-G900T
I have a G900T3 (a strange beast) and am running a T3 bl and modem, with a rooted 5.1.1 G900T rom. I can't use a bl or modem for G900T; the phone refused to flash them.
I downloaded the MM firmware for the T3, but what next?
I can use Odin to flash all these packages, but in what order?
Will I need to flash TWRP again?
Will I lose root?
Can I re-root?
Sent from my SM-G900T using XDA-Developers mobile app
Can I flash this on my metro pcs phone SM-900T1? I will love to run marshmallows again.. I broke my s7 and this S5 is my back up.. Thank for any feed back...
Sent from my SM-G900T1 using XDA Free mobile app
Chris_Wilder said:
Can I flash this on my metro pcs phone SM-900T1? I will love to run marshmallows again.. I broke my s7 and this S5 is my back up.. Thank for any feed back...
Sent from my SM-G900T1 using XDA Free mobile app
Click to expand...
Click to collapse
You might want to try the official firmware instead.
http://www.sammobile.com/firmwares/database/SM-G900T1/
I were any way to add more languages in this firmware?
Related
7-16: Some news. Well, I have some borked hardware and have begun to feel like, to new users, this thread might be more frustrating than helpful.
Therefore, if you are new to the thread/process, I would like to recommend that you try the Auto-Patcher instead. It ports all the functions of this thread (it is what I use to make the packages in the repo) with the assurance that the output won't be incompatible with your ROM.
Please see the release/support thread for the Auto-Patcher for downloads/help.
I am more than proud to have introduced so many of you to Botbrew and native Android package management. Inportb has put together a rock-solid platform that only improves with time. It was a distinct pleasure to watch it evolve, and I hope you all keep an eye on its progress.
I consider it to be the most powerful app available. There are literally limitless possibilities, software porting being among the least of them. I can't wait to compile my first ROM on a tablet- it will be Botbrew that makes it possible. The possibility of our mobile devices replacing laptops are only possible through things like this, and right now, Botbrew is the only game in town. I expect it to remain the standard.
Thanks, all. If you would like an existing package updated, you can always request it in the thread. I can no longer maintain in advance, but I will be happy to offer support on demand.
If you are new, please try the Auto-Patcher instead! Link above!
Offered Packages (only for Nook Color!)
mateorod-v6
Package that enable the v6 supercharger
mateorod-pdroid
Package that installs the framework for PDroid
mateorod-pdroid-v6
(wait for it...)Package that enables BOTH the v6 supercharger and PDroid
If you don't know what the v6, PDroid, or even Botbrew does exactly, please see the information section farther down this post.
Install Directions
Download and install Botbrew, free from Google Play. Botbrew will bootstrap in opkg or dpkg-apt along with several other packages necessary to its operation.
Install package repository-mateorod and press the refresh packages button at top right.
Install the mateorod-whatever package of your choice.
This will be the only system app package you will need to install. Any dependencies will automatically be resolved by its installation. That includes the v6 script.
Reboot.
If your mateorod package includes the v6 supercharger
After reboot open a terminal and enter the following:
Code:
su -c v6
The v6 script will run immediately and you can configure it from there. If you have any lingering questions about the configuration, please see the artifact that is post #3.
If this is your first time upgrading the V6 since update 8, (the one mrg666 used to recommend) don't re-supercharge from your sdcard or you will encounter mount issues! Just configure from scratch.
If your mateorod package includes Pdroid
Install PDroid from Google Play and configure
That's it!
**Should you ever wish to reverse these system changes, Botbrew completely takes care of that for you, restoring backups of every file modified by the process! Simply select the mateorod-whatever package and press Autoremove.
**Upon flashing a new nightly, just launch Botbrew. A repairable packages screen will automatically launch. Select those packages and reinstall them, then reboot. The Botbrew repo will keep up with the CM repo, so as long as you are upgrading to the latest nightly, you will be fine simply reinstalling!
Information
Botbrew
Botbrew is a package manager developed by the totally patient and kind inportb. I make the pitch for its capabilities, as well as my rationale for using it to distribute this software at the top of the 2nd post's ALL-NEW Q&A.
To learn more about Botbrew, visit its homepage OR the thread here on XDA.
v6 Supercharger
The v6 supercharger is a popular script that changes the way your android device's memory management is handled. It was developed by zeppelinrox and lent to Botbrew for the Nook Color by special dispensation. Read more and thank zeppelinrox here.
PDroid
PDroid is a security app available for free on Google Play. It has just about a million applications, the foremost of which is allowing you to block permissions to apps (system and user) from having permissions you are uncomfortable giving. Apps that are given permission to access your contacts, for instance, can now be blocked from that privilege at your discretion.
Pdroid also allows you to set static or random values for sensitive info should an app require them. So apps like Swype and others that require IMEI numbers or phone numbers can now be used like on regular devices. See svyat's original thread and thank him here.
This is the only method to use these programs outside of smali editing your own apps! Usually this is an either/or, but not with these packages!
Try the Auto-Patcher instead!
ohsnap...plug time!
Humility...
XDA News Portal article on v6 package (frontpaged!)
XDA News Portal article on Botbrew (x2)
XDA News Portal article on the PDroid packages(...x3!)
Gratitude...
inportb, for holding my hand through every step of this process, and for Botbrew itself.
Zeppelinrox for lending us the v6 supercharger script
svyat for developing PDroid
PoorCollegeGuy for his continuing support to the project.
racks11479- y'all know racks. But he's got his hands in Botbrew, as well.
pastime1971, my collaborator on the PDroid auto-patcher and the port of PDroid to ICS.
bet you didn't know it took so many people to supercharge a nook, now did ya?
Brand New Q&A!
Q: So why Botbrew and package management and not flashable zips?
A: Ahhh...the million dollar question, I suppose. After all, almost all system changes have been done with flashable zips everywhere else, right?Well, part of the experiment here is to get people comfortable with the idea of package management for their Android device. It is a method that people use with Linux (think Synaptic) and iPhones (Cydia) but is not yet in vogue with Android. But the advantage is not just theoretical, there is tangible and useful value that you will get to experience immediately.For instance, installing system apps for ICS makes the most sense when done through a package manager. With the CM repo being compiled on a nightly basis, the system apps themselves are a moving target. What I mean by that is that the services.jar I mod today may break an install tomorrow. If I distribute the file in a flashable zip that people apply over their install every time they upgrade, well, once the Cyanogen repo updates and the services.jar no longer plays nice with the rest of the install, everyone who flashes that zip on a regular basis is in for a nasty surprise that morning.With a package manager, the first person who realizes the services.jar is out of date (almost always me) just reports back to the thread. I quickly make a new file and update the Botbrew repo. Users don't have to monitor a thread, or personally make a new file, that only has to be done by one person.Now, as is available in this thread, think if there are two different mods to that same services.jar. One user just wants the original mod, while the next would like them both. Neither user has the time or energy to personally decompile and mod the source code for every nightly, but flashing will only install one or the other services.jar. The package management method allows the software distributors to foresee this, and allow for it. That is why you see packages like mateorod-pdroid-v6, something that is just not available for any other nightly install.One last benefit, and this one is a bit theoretical. As of right now, Botbrew only has a few people using it to supply software. But as awareness and the user base grows, more developers will see it as a means of reaching a wider audience. Right now, things like scripts and themes rely solely on word-of-mouth. Think of Botbrew as a potential store-front for all manner of software, everything that isn't a user app (because, of course, Google Play and others already do a fine job of that) could be found here, waiting for your perusal and discovery. That day isn't here yet, but by being willing to try a package manager, you are part of the growing user base that will attract devs. Getting users is the hard part, the devs will follow.Q: So what is Botbrew, exactly, if it just distributes software?
A: At its base, as inportb will tell you, Botbrew is simply a sophisticated installer, with the capacity to add software repos at will. When you install the repository-meteorod package, you are simply downloading my list of available software. You could add as many repos as you want from the Opkg configuration tab in the menu. However, Botbrew also uses unique maintainer scripts that allow software to be installed with a delicacy and precision not available elsewhere. Modding a live install is no everyday thing, and as Android devices get beefier and more powerful, some of the system-mods can be done live on the device, no pre-made software necessary. That will put the power of every script, theme and mod right in your hands, to apply, try and uninstall at will, without having to flash. There are enormous benefits to this.
Okay, the package management proselytizing is done...on to practical matters.
Such as...
Package date issues and build selection
Q: ZOMG! I just installed a package and now I have BOOTLOOPS! What do I do?
A: As they say, don't panic. Just reboot, and press the 'n' button as Cyanoboot loads. Use the menu to boot into recovery and reflash your ROM. The system app just went out-of-date and you were the lucky first user to discover it. Please come to the thread and report any such occurrence. I check each package on a nightly basis (because I love yooouououo) but I have missed a big repo change before and likely will again. I keep a close eye on the thread, and will update the Botbrew repo as soon as possible.Q: What do you mean, a package goes out-of-date?
A: As I said above, ICS is, as of right now, in an experimental and alpha state. What we flash every night isn't even an official release. I think in Cyanogen's perfect world, the amount of users on CM9 as a daily driver would be much less, but with it's popularity and rapidly educated user-base, that genie is out of the bottle. But when the source code used to create these system apps is changed enough, the apps made from the older code are no longer compatible with the newer builds. When that happens...ZOMG! and all that jazz.Q: Even though you just explained how it's basically risk free I am cautious by nature. How do I lessen the chances of bootloops?
A: Just flash in the morning. I check these packages almost every night on builds I set to be tested an hour or two before eyeballer and Samiam go live. By the time you wake up in the morning, there is a 95% chance the packages have already been vetted and replaced if necessary.Q: How often do the packages go out-of-date?
A: Maybe once every three weeks, although I recently had one go out of date after two days (ouch, right?). If you install the packages only over the latest nightly, you'll likely never notice.Q: So how do I know if the build I am using is covered by the Botbrew repo?
A: The absolute best way is to flash a nightly on the day it is released, go into Botbrew and install your packages then. That way you'll always be covered. Those packages will last as long as your nightly is installed. When you feel you are ready to update, just grab the latest nightly and do the same thing again.Q: I am real partial to the build from (for example) March 3rd. What if I want to use Botbrew packages on a certain older nightly?
A: At the bottom of this Q&A there is a list of downloadable packages and the build dates they go with. The links download the package which is installable from any browser or file manager, as long as Botbrew is installed.
Q: What do I need to do after updating to a new nightly?
A: It's real easy. Just launch Botbrew. A screen should automatically appear that supplies you with the list of packages that have been damaged (read: overwritten) by the flash. Select those packages and press reinstall. Then reboot and you're done.Q: Does it work on both eyeballer and Samiam303's builds?
A: The answer is yes, with a catch. Eyeballer clobbers his builds every night, which means he is using no prebuilts from earlier builds and everything in his build is fresh made from that night's source. Samiam currently does not. That means that if you are using Samiam's builds, I recommend you read your build.prop in /system and find the ro.build.date. The date that is there is the last time Sam clobbered, and you will need to use a package that corresponds with that date. You can download the package and save it to your sdcard, and whenever you update, simply check the build date. If he clobbers, pick the corresponding package and go from there. The list of older packages are at the bottom of this post.Q: OpenGL? Do I need different packages if I do/do not have that enabled?
A: Nope. The packages work with or without OpenGL functionality.Q: What about the (totally kick-butt) incremental updates that Team Win is distributing through GooManager?
A: The diff-cm.zips actually break the mechanism Botbrew uses to determine if a flash has been performed (symlinks). For now, we just hope user education will carry us until we come up with a more permanent solution. You WILL have to repair the packages after a flash. Just go into Botbrew and select the germane packages and reboot.
Installation problems and errors
Q: I just ran "su -c v6" and the terminal returned only a "$"! What gives?
A: That is an unfortunate side-effect of the package installation (one I hope I recently fixed!). Launch Botbrew, go to the v6 package and press reinstall. The script will work in the terminal as before, no reboot necessary.Q: I pressed Auto-remove, but it failed! What went wrong?
A: It is an unfortunate bug in Opkg, the engine that powers Botbrew, where the autoremoval process sometimes fails. Just try it again until it works. I find that when it fails for me, the third try finishes the removal process completely.Q: I just tried to install a mateorod package, but the install failed because of "check_data_file_clashes" and "file is already provided by * android-framework*"?
A: Yep, that is a designed file conflict, added to the packages to protect the integrity of the backups and prevent users from accidentally losing functionality they really wanted. The error means you already have a mateorod-whatever package installed. Look for it in the installed packages screen, uninstall that package first, and then try to install your other mateorod package.Q: Can I get (your favorite mod, script, or theme) supported by a package from Botbrew?
A: We can certainly try. Botbrew is only limited to offering packages we can figure out how to make. Request it in the thread, and maybe we can find a way to package it up together.
Older Packages
These packages are available for those of you running an older nightly who do not wish to flash an update. If your build is past any of the dates below, you can install directly from Botbrew!
If Botbrew is installed, the packages below can be installed directly from any browser or file manager.
ONLY install one package at a time!
3/10-4/14
PDroid only
android-framework-pdroid_1.3.2-2_encore.opk
Pdroid+v6
android-framework-pdroid-v6_1.3.2-2_encore.opk
v6 only
android-framework-services-v6.opk_0.0.4-5
4/17-5/05
PDroid only
android-framework-pdroid_1.3.2-4
PDroid+v6
android-framework-pdroid-v6_1.3.2-4
v6 only
android-framework-services-v6_0.0.4-6
5/05-5/06 (Ouch, right?)
PDroid only
android-framework-pdroid_1.3.2-5
PDroid+v6
android-framework-pdroid-v6_1.3.2-5
v6 only
android-framework-services-v6_0.0.4-7
5/07-5/10 (Ouch again, amirite?)
PDroid only
android-framework-pdroid_1.3.2-6
PDroid+v6
android-framework-pdroid-v6_1.3.2-6
v6 only
android-framework-services-v6_0.0.4-8
5/11-5/14 (It is starting to feel personal)
PDroid only
android-framework-pdroid_1.3.2-7
PDroid+v6
android-framework-pdroid-v6_1.3.2-7
v6 only
android-framework-services-v6_0.0.4-9
5/15-5/18 (It is
PDroid only
android-framework-pdroid_1.3.2-8
PDroid+v6
android-framework-pdroid-v6_1.3.2-8
v6 only
android-framework-services-v6_0.0.4-10
5/19-5/26
PDroid only
android-framework-pdroid_1.3.2-9
PDroid+v6
android-framework-pdroid-v6_1.3.2-9
v6 only
android-framework-services-v6_0.0.4-12
5/26-5/27
PDroid only
android-framework-pdroid_1.3.2-10
PDroid+v6
android-framework-pdroid-v6_1.3.2-10
v6 only
android-framework-services-v6_0.0.4-13
5/27-5/30
PDroid only
android-framework-pdroid_1.3.2-11
PDroid+v6
android-framework-pdroid-v6_1.3.2-11
v6 only
android-framework-services-v6_0.0.4-14
5/31-6/03
PDroid only
android-framework-pdroid_1.3.2-12
PDroid+v6
android-framework-pdroid-v6_1.3.2-12
v6 only
android-framework-services-v6_0.0.4-15
6/03-6/07
PDroid only
android-framework-pdroid_1.3.2-13
PDroid+v6
android-framework-pdroid-v6_1.3.2-13
v6 only
android-framework-services-v6_0.0.4-16
6/08-6/10
PDroid only
android-framework-pdroid_1.3.2-14
PDroid+v6
android-framework-pdroid-v6_1.3.2-14
v6 only
android-framework-services-v6_0.0.4-17
Current nightlies and any Android 4.0.3 builds are always supported by the package in repository-mateorod
*Note: There is no version 11 for the android-framework-services-v6 package.
If you are running samiam's builds, the package you need will depend on how recently he clobbered! Check the build date in the build.prop and choose your package accordingly!
Quick V6 Configuration Guide
This is an artifact, almost. But if you have questions about the configuration process for the v6, this is what I used.
The V6 Supercharger menu asks users to confirm operations at several points, usually prompting you to press the Enter button, y for yes or n for no. Those are just confirmations of intent and those steps are skipped in the guide. They are common sense though, and should pose no problem.
The script and the method of modding the services file is the product of the hard work of zepplinrox. I just followed the directions to save people the effort. Any risks are yours and yours alone, as always.
1) Download and Launch Botbrew. Botbrew will bootstrap in some necessary packages
2) Install package repository-mateorod[/] and press the refresh packages button at top right.
3) Install package mateorod-v6
4) Reboot. You will see an "Android is upgrading" pop up over your boot animation.
5) Open a terminal and run the following:
Code:
su -c v6
6) The script will run. The program should automatically run the Driver Options. (If not, enter option 26 in the main script menu to continue following this guide).
Choose 1-3 for scrolling speed. (do yourself a favor and select 1, for the fastest)
7) Y for yes to integrate into init.rc
8) Enter y if you do not want the V6 script animation.
9) The script will enter its main menu which has 30 options. Select option 7.
OpenGL Users: Some slightly less aggressive settings have been reported as resulting in increased stability with OpenGL.
10) You will be prompted to Super clean and Reboot.
This is no longer necessary. The supercharger settings take place immediately. But you can do it if it makes you feel better.
11) Disable and reenable zRAM at 18% in settings/performance/memory management/zRAM in the device settings if you experience lag later. Since this requires reboots, I have changed this to as-needed. Update HacDan informs us our kernel does not have zRam compression. Verdict: Unneeded!
12) Rerun V6 script and read the info beneath the menu list. It should indicate that
-Launcher is Die-Hard, i.e. Supercharged
-ADJ fixes NOT NEEDED
-OOM Groupings Fixed
-Current AND prior minfrees = 8, 14, 75, 90, 95, 125 mbs
-Supercharger Service is installed, and
-Supercharger Level = 100% Supercharged.
If so, then you are correctly installed and running, and your values are sticking after reboot. That's it
mateorod....nice job here....I've been wanting to do the V6 thingy for weeks but everytime I read those original posts I got a little paranoid.
I run MIRAGE on an SD card and the information you provided here worked well.
I'm not sure V6 is helping a lot but its only been a day. I'm seeing no HUGE increase in speed and in some cases....maybe a little slower.....but time will tell.
I just hope it is easy to back off if I want.
Thanks again for your documentation.
Glad it worked for you. Unsupercharge is an option in the menu, should you want to undo the changes. This update makes backups of all of your original settings during the setup process, so they are quick to restore.
Thanks for trying the guide for me.
Have you tried root explorer to see if it works
Posted from Asus Transformer Prime
I have tried to repack the modded services.jar into the nightlies using Root Explorer with varying results. I haven't downloaded the last few updates, but navigating within zips has been buggy in ICS for me. When I tried to copy/paste, it appeared to work, but the file remained unreplaced.
I usually use the latest release candidate of Total Commander for file moving, as its dual window format is easy and it uses a progress bar for large operations. But it too is buggy using the nightlies.
FWIW: I have tried ES Explorer, Root Explorer, Total Commander, OI File Explorer 1.2, and Astro with only Astro working for me.
Having said that, replacing the file is easy on a home computer . I just try my best to find a way to do things entirely from the Nook as a personal idiosyncrasy.
Tried using astro to put the services.jar in, only getting bootloops (1 hour+ and counting, way too long). Tried putting it in before and then flashing the update.zip (2/25 ICS). Tried letting it boot for 2 hours, nada.
Anyone know what I'm doing wrong?
Only thing I can think of, is that you have something in your data that is working against this. My advice is to grab a clean nightly(one you haven't messed with) and put it on your sd. Boot into recovery clear cache and dalvik, update to that nightly, and see if you get through. If you can't than you might have to do a clean install.
But if you get through, than perhaps you should run titanium backup to be safe. Launch root explorer and swap the service.jar files. Reboot and clear caches. If you are able to reboot completely than continue on your directions, if not than perhaps your .jar file is corrupt.
I made a services.jar modded from eyeballer's 2/26 non-opengl build. Has cut down on the bugs so far. I will run it in my device tonight and if it looks unharmful, I will replace the top file tomorrow.
mateorod said:
I made a services.jar modded from eyeballer's 2/26 non-opengl build. Has cut down on the bugs so far. I will run it in my device tonight and if it looks unharmful, I will replace the top file tomorrow.
Click to expand...
Click to collapse
PM me if it works, than I can replace my files on Sam's thread.
Sent from my Nook Color, running Samiam303's ICS nightly V6 SuperCharged, using Tapatalk.
When I do step 11 in the second post (rerun V6) nothing happens I just get dropped back to /sdcard #.
Rick_V said:
When I do step 11 in the second post (rerun V6) nothing happens I just get dropped back to /sdcard #.
Click to expand...
Click to collapse
This happened to me, download Script Manager from market(it's free). Run your V6 script in that program.
An encore (nook) specific services.jar for the 2/27 builds will be up in about 20 mins.
Update: Now up on original post attachment list.
Okay so I made this ZIP, it should replace your service.jar with the newest one for V6(from mateorod's post), and the bootanimation to the official CM9 one (Video Link)(Tnpapadakos' files).
Grey
Could you be more specific about what is included in the zip you just posted here for anyone who isn't following the other thread? I read it fairly regularly, but I have no idea myself. There are a ton of tweaked packages running around right now, they can be hard to keep straight.
Thanks
mateorod said:
Grey
Could you be more specific about what is included in the zip you just posted here for anyone who isn't following the other thread? I read it fairly regularly, but I have no idea myself. There are a ton of tweaked packages running around right now, they can be hard to keep straight.
Thanks
Click to expand...
Click to collapse
yeah i have to agree, its precisely why i gave up on running ics on my nook, too many messy mixed messaged threads going on mixing mods. itd be great to just see an ics rom compiled with everything included to make lives of idiots like me easier.
mateorod said:
Gray
Could you be more specific about what is included in the zip you just posted here for anyone who isn't following the other thread? I read it fairly regularly, but I have no idea myself. There are a ton of tweaked packages running around right now, they can be hard to keep straight.
Thanks
Click to expand...
Click to collapse
I fixed it
Am I the only one who can't find V6 U9RC6.9 and doesn't see build.prop options?
grayfoxmg1 said:
Okay so I made this ZIP, it should replace your service.jar with the newest one for V6(from mateorod's post), and the bootanimation to the official CM9 one (Video Link)(Tnpapadakos' files).
Click to expand...
Click to collapse
Thanks for that zip! Just a heads up though, if you drop any boot animation in /data/local, you dont have to worry about it being overwritten when flashing a new nightly. The one in /data/local overrides the one in /system/media, and will not be replaced on install of a nightly.
On another note, for those that have the boot animation already, or just want to have the script and latest services.jar, I made a zip (actually based off of yours, grayfoxmg1, since I'm new to this) that will copy services.jar (EDIT: This is for the 0227 services.jar file. I will be uploading a zip with the 0302 one shortly.)(mateorod's latest Nook specific one) to /system/framework, and will put the V6 script (latest RC6.9, named "V6.sh") onto the root of your sdcard. If there any issues let me know, as I am new to making flashable zips.
Zip without boot animation (EDIT: This is for the 0227 services.jar file. I will be uploading a zip with the 0302 one shortly.) :
http://db.tt/fUIddDP4
Zip with boot animation placed in /data/local to make it (EDIT: This is for the 0227 services.jar file. I will be uploading a zip with the 0302 one shortly.) :
http://db.tt/MjJ5LEgK
(If this is the wrong place to put this, or for any reason you dont want it here, just let me know and I will remove it!)
numus said:
Am I the only one who can't find V6 U9RC6.9 and doesn't see build.prop options?
Click to expand...
Click to collapse
No, for some reason (I suppose he just uses init.rc tweaks now) there is no longer that option. Ran the script 3 times, and no build.prop options :/
Hello XDA-san
This is my first time working with cygwin and Android Kitchen and I wanted to make sure I didn't miss anything that will royally brick my s4. I have attached screenshots of my journey for reference.
I started with the stock ROM from you know where, version 4.4.2 (i337MOYAFNC1) and proceeded to remove the KNOX bootloader (using instructions from SilviuMik). I skipped the last step where it is re-md5, to continue on to the kitchen..
Using the de-knoxed tar file, I created a working folder for the ROM in the kitchen. It started unpacking, everthing went well. When i was prompted to choose if I wanted to extract the CSC, I said no.. because the DiskInternals Linux reader was giving me an error saying along the lines of cant read disk..
From my working folder, I proceeded to root & busybox, all went well. I then deodexed both the system apps and framework, all went well.
lastly, I made a build from the working folder. Selected all default options while doing so (see pictures) , signed the freshly minted rom and voila.
If the repacking was successful there is not much to fear about.
(You may want to lookup if there is any dependents (in the rom) by using the removed knox bootloader (atleast remove the knox apks I guess)
the CSC is really nothing important:
A common short code (CSC) is a short telephone number, usually consisting of five digits, that is used to address SMS and MMS messages from a cellular telephone. Common short codes may also be called mobile short codes or short numbers. Each common short code is designed to be unique to each operator.
Click to expand...
Click to collapse
Just include the one from the stockrom. btw, I have successfully manually unpacked the CSC file a year ago or so with simg2img, it only contained crap (samsung only files for altering behavior in TW rom and bloatware), the hidden partition or preload partition may also contain unwanted crap btw
So go ahead and flash it, your phone will not get bricked by this in any way.
broodplank1337 said:
If the repacking was successful there is not much to fear about.
(You may want to lookup if there is any dependents (in the rom) by using the removed knox bootloader (atleast remove the knox apks I guess)
the CSC is really nothing important:
Just include the one from the stockrom. btw, I have successfully manually unpacked the CSC file a year ago or so with simg2img, it only contained crap (samsung only files for altering behavior in TW rom and bloatware), the hidden partition or preload partition may also contain unwanted crap btw
So go ahead and flash it, your phone will not get bricked by this in any way.
Click to expand...
Click to collapse
Hi broodplank1337, thhank you for your reply
So would it be better to go into my newly minted zip file and hunt down the knox apks / dependencies? Or should I flash the ROM then use root browser to get rid of them?
I found this list "
Delete the files in the following files in this order.
/system/app/KNOXAgent.apk
/system/app/KNOXAgent.odex
/system/app/KLMSAgent.apk
/system/app/KLMSAgent.odex
/system/app/KnoxAttestationAgent.apk
/system/app/KnoxAttestationAgent.odex
/system/app/KNOXStore.apk
/system/app/KNOXStore.odex
/system/app/ContainerAgent.apk
/system/app/ContainerAgent.odex
/system/lib/libknoxdrawglfunction.so
/system/app/ContainerEventsRelayManager.apk
/system/app/ContainerEventsRelayManager.odex
/system/app/KNOXStub.apk <--- delete if you have, some will not
Delete the following folders
/system/containers
/system/preloadedkiosk
/system/preloadedsso
/system/etc/secure_storage/com.sec.knox.store
/data/data/com.sec.knox.seandroid
/data/data/com.sec.knox.store
/data/data/com.sec.knox.containeragent
/data/data/com.samsung.android.walletmanager
The French Tickl3r said:
Hi broodplank1337, thhank you for your reply
So would it be better to go into my newly minted zip file and hunt down the knox apks / dependencies? Or should I flash the ROM then use root browser to get rid of them?
I found this list "
Delete the files in the following files in this order.
/system/app/KNOXAgent.apk
/system/app/KNOXAgent.odex
/system/app/KLMSAgent.apk
/system/app/KLMSAgent.odex
/system/app/KnoxAttestationAgent.apk
/system/app/KnoxAttestationAgent.odex
/system/app/KNOXStore.apk
/system/app/KNOXStore.odex
/system/app/ContainerAgent.apk
/system/app/ContainerAgent.odex
/system/lib/libknoxdrawglfunction.so
/system/app/ContainerEventsRelayManager.apk
/system/app/ContainerEventsRelayManager.odex
/system/app/KNOXStub.apk <--- delete if you have, some will not
Delete the following folders
/system/containers
/system/preloadedkiosk
/system/preloadedsso
/system/etc/secure_storage/com.sec.knox.store
/data/data/com.sec.knox.seandroid
/data/data/com.sec.knox.store
/data/data/com.sec.knox.containeragent
/data/data/com.samsung.android.walletmanager
Click to expand...
Click to collapse
Oh I thought you were building an odin rom? zip you say?
Anyways, just remove em from the system folder and test it's result. You can always test roms without damaging your device at any time, read: it's impossible for a ROM to brick a phone, the thing that can brick it is the kernel, but only if using a kernel from an other device or so.
so don't be afraid to test it, if it doesn't work just continue your work. if it works, good joob
broodplank1337 said:
Oh I thought you were building an odin rom? zip you say?
Anyways, just remove em from the system folder and test it's result. You can always test roms without damaging your device at any time, read: it's impossible for a ROM to brick a phone, the thing that can brick it is the kernel, but only if using a kernel from an other device or so.
so don't be afraid to test it, if it doesn't work just continue your work. if it works, good joob
Click to expand...
Click to collapse
One caveat to this, and this mostly applies to Verizon and AT&T users, but if you have upgraded to KitKat and kept root using SuperSu's survival mode and your planning to test a rom using Safestrap, you better make sure that the su binary is in xbin and bin (.ext/.su) and that the Superuser.apk is in /system/app. Also make sure that the permissions are set correctly for su (chmod 06755 chown 0.0) and have busybox in the rom as well, or at least have busybox install in the updater-script and make sure everything symlinks correctly.
The best thing to do when testing roms to avoid having to worry about losing root is to download Chainfire's SuperSu zip and flash it after you flash your rom you're testing (but before it reboots into the rom for the first time) the reason I even mention all of this is because currently we (Verizon and AT&T users) have no way to root a device thats taken a complete 4.4.2 OTA.
Surge1223 said:
One caveat to this, and this mostly applies to Verizon and AT&T users, but if you have upgraded to KitKat and kept root using SuperSu's survival mode and your planning to test a rom using Safestrap, you better make sure that the su binary is in xbin and bin (.ext/.su) and that the Superuser.apk is in /system/app. Also make sure that the permissions are set correctly for su (chmod 06755 chown 0.0) and have busybox in the rom as well, or at least have busybox install in the updater-script and make sure everything symlinks correctly.
The best thing to do when testing roms to avoid having to worry about losing root is to download Chainfire's SuperSu zip and flash it after you flash your rom you're testing (but before it reboots into the rom for the first time) the reason I even mention all of this is because currently we (Verizon and AT&T users) have no way to root a device thats taken a complete 4.4.2 OTA.
Click to expand...
Click to collapse
Seriously? wow, thanks for mentioning, I can't believe what a pricks Verizon and AT&T are. Same count for Samsung that handles knox regulation in the USA (while not in other countries). In the USA you get pretty much screwed by the carriers and manufacturers the hard way.
In The Netherlands (where I live) it's even illegal to sell smartphones that are not unlocked by default. and the only thing a carrier may do is adding a CSC (Consumer Software Customization) package. This should be in the USA as well!
In the USA companies get to private / independent it seems. they should be regulated by national government rules. instead of making their own. (this keeps the crap like the problem you described away)
But Samsung should be regulated as well, there is no chance that will happen (south-korea), and their phones will contain more and more backdoors / suspicious daemons / methods of screwing you and so on, because who checks it, no one. Oh yes only someone, the NSA that adds even more of this stuff, like a VPN Interceptor, which no one is waiting for as well.
Anyways, life (or actually companies) is (are) a *****. Only strict regulation could solve this, but who still believes in regulation after seeing what the NSA all did, they broke like every single rule and forced companies to merge their crap (most likely, or a huge payment, but no single company actually likes that)
- NSA 'was allowed' to break in all PC's because that where outside the USA. that just ridiculous but true
- NSA applied their 'jizz' to all super famous apps like Facebook.
Even though it sounds like I say USA is the culprit thats not true, The netherlands have BREIN, which is the anti piracy company.
This asshole tim kuik has,
a. destroyed the piratebay for the whole world (even though it's recuping soon)
b. have done a million requests on removing uploaded movies (on newsgroups)
I really went OT all the way at this reply xd but you get my point :good:
The product gets made, then infected by the creator, then gets forced to merge nsa crap. after that it goes to the carrier which installs even more crap.
there is not a single bit of freedom left
Thank you both for these tips. Being a rather unexperienced cook, I would have never thought of these important details mentioned above.
it really is a shame how tightly service provider have our collective balls in a grasp..
broodplank1337 said:
Seriously? wow, thanks for mentioning, I can't believe what a pricks Verizon and AT&T are. Same count for Samsung that handles knox regulation in the USA (while not in other countries). In the USA you get pretty much screwed by the carriers and manufacturers the hard way.
In The Netherlands (where I live) it's even illegal to sell smartphones that are not unlocked by default. and the only thing a carrier may do is adding a CSC (Consumer Software Customization) package. This should be in the USA as well!
In the USA companies get to private / independent it seems. they should be regulated by national government rules. instead of making their own. (this keeps the crap like the problem you described away)
But Samsung should be regulated as well, there is no chance that will happen (south-korea), and their phones will contain more and more backdoors / suspicious daemons / methods of screwing you and so on, because who checks it, no one. Oh yes only someone, the NSA that adds even more of this stuff, like a VPN Interceptor, which no one is waiting for as well.
Anyways, life (or actually companies) is (are) a *****. Only strict regulation could solve this, but who still believes in regulation after seeing what the NSA all did, they broke like every single rule and forced companies to merge their crap (most likely, or a huge payment, but no single company actually likes that)
- NSA 'was allowed' to break in all PC's because that where outside the USA. that just ridiculous but true
- NSA applied their 'jizz' to all super famous apps like Facebook.
Even though it sounds like I say USA is the culprit thats not true, The netherlands have BREIN, which is the anti piracy company.
This asshole tim kuik has,
a. destroyed the piratebay for the whole world (even though it's recuping soon)
b. have done a million requests on removing uploaded movies (on newsgroups)
I really went OT all the way at this reply xd but you get my point :good:
The product gets made, then infected by the creator, then gets forced to merge nsa crap. after that it goes to the carrier which installs even more crap.
there is not a single bit of freedom left
Click to expand...
Click to collapse
The NSA can screw a cow. USA is Freedom? Like hell. I live here and am starting to become ashamed of my country. I hate the government, more directly this president. Anyway, whats a VPN Interceptor? Sounds scary..
But about the OP, can you build an Odin tar with the older Bootloaders in and newer system images to remove knox warranty and allow users to upgrade without screwing themselves? Last i checked, you needed a way to sign the tar file to match with the current bootloader checking.
broodplank1337 said:
the CSC is really nothing important:
Click to expand...
Click to collapse
CSC is "Country/Carrier Specific Config", not "common short code"
While it's not so important, skipping it may produce many side effects in normal work.
The common way to deal with CSC is extract it and pre-integrate into system - that's what stock recovery is doing upon first boot after flash.
sorg said:
CSC is "Country/Carrier Specific Config", not "common short code"
While it's not so important, skipping it may produce many side effects in normal work.
The common way to deal with CSC is extract it and pre-integrate into system - that's what stock recovery is doing upon first boot after flash.
Click to expand...
Click to collapse
This doesn't always work. I used to try this with rooted dump/repacks for S4, N2 and E4GT and we got mixed results not including Samsung's cache.img. In Sprint's case this defaulted the carrier to XAS, an internal use only code that doesn't fully enable everything for Sprint. I don't recall if this was on images with a blank data.img only or "nodata" cases as well.
garwynn said:
This doesn't always work. I used to try this with rooted dump/repacks for S4, N2 and E4GT and we got mixed results not including Samsung's cache.img. In Sprint's case this defaulted the carrier to XAS, an internal use only code that doesn't fully enable everything for Sprint. I don't recall if this was on images with a blank data.img only or "nodata" cases as well.
Click to expand...
Click to collapse
I've did it on GT-I9100, GT-I9300, SHV-E210K, GT-N7100, SHV-E330S. It worked always. Sometimes CSC is multi-CSC where you have to choose correct version.
I didn't use operator-specific models. So probably some additional steps required. But anyway, CSC from cache partition is simply copied to system by recovery. To be more precise, you can check command file in cache.img - this is where "magic" happens
Hi devs, i first time cooked prerooted deodexed rom from stock 4.4.2 rom using cygwin and andriod kitchen. every thing went well. my only question is can i remove modem from output zip as i don't want to use that modem.
Got status 7 error installation aborted.
navdeepavi said:
Got status 7 error installation aborted.
Click to expand...
Click to collapse
go to advanced > show log in recovery
As a follow up to the status 7 error, I spent quite a while figuring out what caused it and how to solve it. I posted this on another thread but ill quote myself here.
The status 7 failed to mount /preload error and why it happens:
Lets take a minute to go over why this happens and what it means. First what is /preload anyways? Well lets take a look at how it gets mounted, consider mount points below:
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system");
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/hidden", "/preload");
We can infer from the point arguements that /preload is the mount point for the "hidden" partition. Well then what is this "hidden" partition then you ask? Well hidden contains some useless crap Samsung uses to verify integrity of the system partition when in recovery
So the idea is to wipe data/factory reset in recovery followed by making sure to flash hidden.img.ext4 prior to cache.img.ext4. I think my inclusion of cache.img.ext4 on accident in the first tar is the root of the cause so ive uploaded a new one that doesnt contain it so it wont fail at step 1.
So essentially you cant flash a a full-wipe or no-wipe Odin tar to go back. You have to use a custom made Odin tar. Also for people getting the status 7 error where /preload fails to mount after flashing cache the solution is to boot into stock recovery and factory data reset followed by flashing hidden.img.ext4 via Odin or Heimdall.
Click to expand...
Click to collapse
OK
So I managed to create a flashable
.zip of I337MVLUFNE1:
Rooted, Deodexed, Knox-Free,
Zipaligned, Debloated, KT Kernel!
Will post link here if you guys want!
Adizzzle said:
OK
So I managed to create a flashable
.zip of I337MVLUFNE1:
Rooted, Deodexed, Knox-Free,
Zipaligned, Debloated, KT
Will post link here if you guys want!
Click to expand...
Click to collapse
oh sweet, sure ill gladly test it out
ty!
go habs GO
The French Tickl3r said:
oh sweet, sure ill gladly test it out
ty!
go habs GO
Click to expand...
Click to collapse
http://www.androidfilehost.com/?fid=23501681358539374
It has a TMO KT kernel so you may need a
different kernel depending on your device.
It's debloated, but only lightly.
I have a heavily debloated version uploading.
Adizzzle said:
http://www.androidfilehost.com/?fid=23501681358539374
It has a TMO KT kernel so you may need a
different kernel depending on your device.
It's debloated, but only lightly.
I have a heavily debloated version uploading.
Click to expand...
Click to collapse
awesome ty
i have the i337m with telus, and if i remember correctly, I had to use the TMO kernel when I flashed the maple leaf ROM a while back
The French Tickl3r said:
awesome ty
i have the i337m with telus, and if i remember correctly, I had to use the TMO kernel when I flashed the maple leaf ROM a while back
Click to expand...
Click to collapse
Yeah it was made for a Telus I337M
The only thing missing is the APN.
Made with ArchiKitchen.
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]
Almost every custom ROM we see is deodexed .. claiming that it has better compability for theming . and also makes ROM faster
This is interesting because I saw some developers not recommending deodexing on Nougat and newer android versions, their reason is
On LP and MM, there is no significant difference between the two (odex/deodex) in terms of speed and functionality
On Nougat, there is a significant difference..
On MM and LP, ART compiles the apps ahead of time on first boot, therefore apps are theoretically odexed once the ROM has booted
On Nougat, Android boots without compiling the apps and instead compiles apps in the background during times of low load/idle. THIS SIGNIFICANTLY AFFECTS PERFORMANCE AND BATTERY LIFE*
Click to expand...
Click to collapse
I'd love to hear from experts about this
I'm hardly an expert, and I am aware that I'm responding to a 4 month old post, but this is what I understand regarding deodexing and the phones performance:
A deodexed rom is one where all the APK and JAR files in the /system partition have their respective classes.dex files inside them. An odexed rom has those files in separate files, outside the main APK/JAR. These separate files used to have the extension "*.odex" but now can have "*.oat" or "*.vdex" instead.
Modding an odexed app is annoying as, if you want to change any of the information in the classes, you have to decompile and recompile both files. Since ART came along, there are some framework files that you can't mod at all without having to mod others at the same time. So a deodexed rom makes things a lot easier. One file, one decompile, one recompile, done.
Android processes the classes in the system partition only when the device boots for the first time (or if the relevant cache has been wiped). A deodexed rom takes longer to boot at this stage as it's slower for Android to extract the DEX files and process them. Processing an 'Optimised DEX' file is faster and more efficient.
Once the device has booted though, you shouldn't notice any performance difference from what I understand. All the apps that are running when the device is on (framework-res.apk, SystemUI.apk, etc) have already been processed. The device can't start until they have.
The apps you choose to start, like a game or music player, won't be affected by the deodex/odex nature of the rom.
Again, this is only how I understand it. I'm not a developer and I don't mind being proven wrong. But I don't see how a device can boot without processing the system apps. It has to process the classes information to know what those apps do, and those apps do what they do as soon as the device boots.
As you might know, palm rejection on non stock roms has not worked for a long time. The symptoms are that when you try to draw with the s-pen in apps like squid or OneNote, often what you draw gets immediately erased.
I went back to CM13.0, where it supposedly did work, and checked what the difference is. I got lucky, and found the right files. It seems that palm rejection was removed from the file InputReader.cpp in frameworks_native/tree/p/services/inputflinger.
I'm sure there was a very good reason for that removal, probably because this is not the right place to do it. I tried to see what would happen if I put it back. I compiled XenonHD with the change, and now my s-pen works great! I tried squid, one note, gboard handwriting and others, and all works. I think this change can probably be easily incorporated into all AOSP/LOS roms.
The files are at https://github.com/ghostwheel/frameworks_native/tree/p/services/inputflinger , and you need InputReader.cpp and InputReader.h
As I said, there is probably a better way to enable palm rejection, but this works for now.
Update Actually, it seems the change was introduced between 14.1 and 15.0 . Look here: https://github.com/LineageOS/android_frameworks_native/blob/cm-14.1/services/inputflinger/InputReader.cpp. But I can't find the particular change that
caused this. Maybe it didn't have a great reason?
help me how to implement this to a rom
Might be interested in trying this (assuming I just replace/modify some files, right?) I'm assuming its harder than that.
Can you please make detailed tutorial? Both Havoc and LineageOs android 10.0 have this problem.
You just need to take InputReader.cpp, InputReader.h and also InputDispatcher.cpp from the github above to the code, in frameworks_native/services/inputflinger/. The problem is that usually you don't have control of that dir. If you take control, it is easy.
ghostwheel said:
You just need to take InputReader.cpp, InputReader.h and also InputDispatcher.cpp from the github above to the code, in frameworks_native/services/inputflinger/. The problem is that usually you don't have control of that dir. If you take control, it is easy.
Click to expand...
Click to collapse
Im suspecting you can use something like ES File Explorer (yes I still use an older version I have saved in TB) to just copy those files into the directory?
Dave
I used to use ES file explorer...
All these are source files that need to be compiled together with the android dist.
It might be possible to just copy the result, maybe services.jar inside framework??? Not sure. The right way is to download a distribution, copy the files into the right place, and compile. XenonHD has nice instructions of how to do all that. Though, XenonHD already has all that built in, for exactly that reason....
Thanks a lot, I am really new to all the terms you are using. All I know is to download zip file and flash it with TWRP recovery installer. I can also get the files fro github. What I dont know is: How to modify rom zip file and recompile it back to flashable zip?
Due to this issue, I am keeping my Note 4 in stock android 6.0 unfortunately, this will be life saver for me if you can help anyhow,
Thanks a lot.