[Q] Various android-related queries - Android Q&A, Help & Troubleshooting

I have managed to compile (from source) and install CM7.2 on my HTC dream, but my questions below are related to Android:
1. Is there a way to find out which packages (.apk) were installed on my system and if so, how do I do that?
2. Is there a way to find out each package dependencies (I need to figure out this as I am bent on removing the vast amount of guff installed on the phone - I won't need 90% of this stuff)?
3. Similarly to 2 above - is there a way to look at dependencies of a package not yet installed on my system (i.e. the .apk file)?
4. How do I actually remove a package for good from the system?
5. Similarly to 3 above, how do I actually install a package from within the root system - I know I can do this via adb, but is there a way to do this inside the, say, command line terminal?
6. Is there a way to alter (understand remove) certain program permissions which I could see "granted" to a particular program/package? I know there are various ways to look at these, but I wish to remove permissions I am not happy being granted to that particular program/package.
And one last a bit more advanced query: I would like to build a single package from the source tree and then install the resulting .apk file on my system.
Basically, I will try to upgrade a package with a new revision and add a few patches to the package source of my own before compiling it and building it again.
I usually build the whole lot (all packages + the rootfs image itself) with "mke bacon", but if I want to alter the source and build a single package how do I do that?
I am not very familiar with the Android make system, so I don't want to go heads-first into something and make a real mess of it.
Thanks a lot for any assistance given.

Related

[KITCHEN] Android Kitchen, v0.224 [Linux / Mac / Windows]

dsixda's Android Kitchen
Compatible with Windows (Cygwin) / Linux / Mac OS X
Introduction
This is a tool for those who want to start learning how to make custom ROMs, or who just want to save some time with their ROM customization.
My goal is to make your life easier, and, at the same time, help you learn about the Android OS.
The kitchen will not automatically turn you into a developer. You are not programming anything or building a ROM from the ground up. The kitchen merely presents a user-friendly interface to hide all the rough details. However, this may be the push that gets you into development in the future.
A little bit of prior UNIX command-line knowledge would be useful to get started with the kitchen, but the help guides should be enough for a newbie. Knowledge of command lines is always important if you ever want to get involved in Android or development.
Code:
===================================================================
Android Kitchen - by dsixda (xda-developers.com)
===================================================================
Main Menu
1. Set up working folder from ROM
2. Add root permissions
3. Add BusyBox
4. Disable boot screen sounds
5. Add wireless tethering
6. Zipalign all *.apk files to optimize RAM usage
7. Change wipe status of ROM
8. Change name of ROM
9. Check update-script for errors
10. Show working folder information
Advanced Options
11 - Deodex files in your ROM
12 - Add task killer tweak for speed (stock ROM only)
13 - Add /data/app functionality
14 - Add Nano text editor + sysro/sysrw
15 - Add Bash (command shell)
16 - Add Apps2SD
17 - Add /etc/init.d scripts support (busybox run-parts)
18 - Add custom boot animation functionality
19 - Porting tools (experimental)
20 - Tools for boot image (unpack/re-pack/etc.)
21 - Unpack data.img
22 - Sign APK or ZIP file(s)
23 - Convert update-script or updater-script
24 - Miscellaneous optins / Plugin scripts
99. Build ROM from working folder
00. About/Update kitchen
0. Exit
THIS PROJECT IS RETIRED.
This project is retired as of 2013, as I have become overwhelmed with the number of devices to support, the demand, bad health, and the constant requests for help, especially with a new addition to the family and busy life. Unfortunately I am still suffering from a torn scapholunate ligament in my hand that I incurred in late 2010 as a direct consequence of the extra time I spent on the kitchen on my laptop. Thus I cannot spend time on these kinds of activities on a regular basis.
If you need help with your device, please ask in the appropriate device forum. I just want to request people to stop asking me about the kitchen in my posts in other xda-developers threads or Facebook groups that are not related to the kitchen; it is not fair to me or other users in those threads. I have not worked on the kitchen since spring 2013, and have moved on.
This all doesn't necessarily mean the kitchen won't work anymore in the future. Please refer to the information in this post for how to perhaps get newer devices to work with the kitchen. I really hope this kitchen helps you out. If you want to, send me a tweet or hit 'Thanks' at the end of this post (or whatever else) to let me know it worked out for you.
Thanks for your support!
Click to expand...
Click to collapse
Supported devices
NOTE: If your device is not mentioned here, try to configure the kitchen to add support for it. See Post #3 of this thread (the FAQ) on how to add new devices to the kitchen.
Code:
---------------------------------------------------
MediaTek MT65xx-based devices
- [URL="http://forum.xda-developers.com/showthread.php?t=1863153"]Discussion thread here[/URL]
- MT657X devices: See [URL="http://forum.xda-developers.com/showpost.php?p=36212601&postcount=54"]this post[/URL]
for details
- MT6589 devices: See [URL="http://forum.xda-developers.com/showpost.php?p=40600395&postcount=144"]this post[/URL]
- IMPORTANT: You may need to define your device under the kitchen's
/tools/edify_defs folder, or it might not boot! Read the instructions in FAQ
section: 'How to Add New Devices'
---------------------------------------------------
Alphabetical list of rest of devices:
Acer Liquid
Dell Streak 7
HTC Amaze 4G
HTC Aria / Liberty
HTC Desire
HTC Desire HD / Inspire 4G
HTC Desire S
HTC Desire Z / Vision / T-Mobile G2
HTC Dream / G1
HTC Droid DNA
HTC Droid Eris
HTC Evo 3D
HTC Evo 4G
HTC Evo 4G LTE
HTC Evo View 4G (untested)
HTC Evo Shift 4G
HTC Flyer (untested)
HTC HD2
- Use NAND ROM method ([URL="http://forum.xda-developers.com/showthread.php?t=996447"]Please follow this thread for details[/URL])
HTC Hero / G2 Touch
HTC Incredible
HTC Incredible 2
HTC Incredible S
HTC Legend
HTC Magic / myTouch 3G
HTC myTouch 3G Slide
HTC myTouch 4G / Glacier
HTC Nexus One
HTC One (m7 variant)
HTC One S
HTC One X
HTC One X+ (AT&T and International versions)
HTC One XL
HTC One V (including CDMA version)
HTC Rezound
HTC Sensation
HTC Tattoo / Click
HTC Thunderbolt
HTC Wildfire / Buzz
HTC Wildfire S
Huawei - Newer devices (2013+):
- Custom ROMs *not* supported, but to extract files from firmware,
[URL="http://forum.xda-developers.com/showthread.php?p=45317807"]please follow this thread[/URL].
Huawei Ideos X6
- [URL="http://forum.xda-developers.com/showthread.php?t=1299765"]Please follow this thread for details[/URL]
Huawei U8100/U8110/U8120/U8150/U8160/U8180/U8650
Huawei U8220 / T-Mobile Pulse
LG Ally
LG GT540 Optimus
LG Motion 4G
- [URL="http://androidforums.com/motion-4g-all-things-root/688235-tutorial-dsixdas-android-kitchen-deodxing-cooking-roms.html"]Please follow this thread for details[/URL]
LG Nexus 4 (mako)
LG Optimus 2X (P990)
LG Optimus Black
- [URL="http://forum.xda-developers.com/showthread.php?t=1542148"]Please follow this thread for details[/URL]
LG Optimus G2X (P999)
LG P500
- [URL="http://forum.xda-developers.com/showthread.php?t=901417"]Please follow this thread for details[/URL]
LG Shine Plus
LG Vortex
Micromax A60
Motorola Atrix (unconfirmed)
Motorola CLIQ / CLIQ XT
Motorola Droid
Motorola Droid Bionic
- Please follow [URL="http://rootzwiki.com/topic/11372-how-to-build-a-simple-rom-with-stock-moto-base/"]this thread[/URL] for details
Motorola Milestone (unconfirmed)
- You may need to remove the boot.img before building
Prestigio MultiPhone 4500 DUO
Prestigio MultiPhone PAP4500TDUO
Samsung Galaxy Ace 2 - GT-I8160(L/P)
Samsung Galaxy Mini
Samsung Galaxy Nexus (untested, 'maguro' and 'toro' versions only)
Samsung Galaxy Note
- GT-N7000 - please follow [URL="http://forum.xda-developers.com/showthread.php?t=1940752"]this thread[/URL] for details
- SGH-I717 - Please follow [URL="http://forum.xda-developers.com/showthread.php?t=1390903"]this thread[/URL] for details
Samsung Galaxy Note 2
- Supported for:
-- Sprint variants - SPH-L900 - [URL="http://forum.xda-developers.com/showthread.php?t=2013309"]Please follow this guide[/URL]
-- T-Mobile variants - SGH-T889(V) - [URL="http://forum.xda-developers.com/showthread.php?t=1972596"]Please follow this guide[/URL]
-- Verizon variants - SCH-I605
(unconfirmed - [URL="http://forum.xda-developers.com/showthread.php?t=1939300"]see this equivalent guide[/URL])
-- International variants - GT-N7100/N7105(T)/N7108
(unconfirmed - [URL="http://forum.xda-developers.com/showthread.php?t=1939300"]see this equivalent guide[/URL])
-- AT&T/Rogers/Bell/Telus variants - SGH-I317(M)
(unconfirmed - [URL="http://forum.xda-developers.com/showthread.php?t=1939300"]see this equivalent guide[/URL])
-- US Cellular variants - SCH-R950
(unconfirmed - [URL="http://forum.xda-developers.com/showthread.php?t=1939300"]see this equivalent guide[/URL])
Samsung Galaxy R GT-I9103
Samsung Galaxy S (GT-I9000 and most variants)
- Please follow [URL="http://forum.xda-developers.com/showthread.php?t=1257297"]this thread[/URL] for details
Samsung Galaxy S Plus (GT-I9001)
- Please follow [URL="http://forum.xda-developers.com/showthread.php?t=1399468"]this thread[/URL] for details
Samsung Galaxy S2
- Supported for:
-- GT-I9100 and Exynos CPU variants - Please follow [URL="http://forum.xda-developers.com/showthread.php?t=1227549"]this thread[/URL] for details
-- Qualcomm/LTE variants
(AT&T Skyrocket, Rogers, Telus, T-Mobile, Bell HD LTE SGH-I757M,
Telstra GT-I9210T)
- Please follow [URL="http://forum.xda-developers.com/showthread.php?t=1390903"]this thread[/URL] for details
Samsung Galaxy S3
- Supported for:
-- T-Mobile/Mobilicity/Wind variants: SGH-T999(V) - [URL="http://forum.xda-developers.com/showthread.php?t=1939420"]Click here for a guide[/URL]
-- AT&T/Rogers/Bell/Telus variants: SGH-I747(M) - [URL="http://forum.xda-developers.com/showthread.php?t=1939833"]Click here for a guide[/URL]
-- Verizon variants: SCH-I535, SCH-R530U - [URL="http://forum.xda-developers.com/showthread.php?t=1943578"]Click here for a guide[/URL]
-- Sprint variants: SPH-L710, SCH-L710 - [URL="http://forum.xda-developers.com/showthread.php?t=1946249"]Click here for a guide[/URL]
-- International variants: GT-I9300(T) - [URL="http://forum.xda-developers.com/showthread.php?p=32854889#post32854889"]Click here for a guide[/URL]
-- International LTE variants: GT-I9305(T) - [URL="http://forum.xda-developers.com/showthread.php?t=1971519"]Click here for a guide[/URL]
-- Korean variants: SHV-E210K/L/S and SHW-M440S (unconfirmed)
Samsung Galaxy S4
- NOTE: Kitchen only supports creating ROMs from stock firmware
or importing ROMs made only with kitchen!
- Supported for:
-- AT&T variant (SGH-I337)
-- Bell/Telus/Rogers variant (SGH-I337M)
-- T-Mobile variant (SGH-M919)
-- Wind/Mobilicity variants (SGH-M919V) - untested
-- International non-LTE variant (GT-I9500) - untested
-- International LTE variant (GT-I9505) - untested
-- Other American variants (SCH-R970, SPH-L720, SCH-I545) - untested
Samsung Galaxy W (GT-I8150)
- Please follow [URL="http://forum.xda-developers.com/showthread.php?t=1447422"]this thread[/URL] for details
Samsung Nexus S / Nexus S 4G
Sony Ericsson Xperia 2010 devices (X10 / X10 Mini / X10 Mini Pro)
- Can only build ROM without boot.img ([URL="http://forum.xda-developers.com/showthread.php?t=888227"]please follow this thread for details[/URL])
Sony Xperia 2011-12 devices, specifically:
- TX, P, U, Sola
- Active, Arc, Arc S, Mini, Mini Pro, Neo, Neo V, Neo L,
Play, Ray (follow steps below):
- Can only build ROM without boot.img
- If using stock FTF for kitchen:
1) Unzip FTF file, extract the system.sin
2) Dump system image from system.sin w/ Flashtool
(Advanced-> SIN Editor)
3) Rename dumped file to system.img
- OR If using Nandroid backups: Rename system.yaffs2.img to system.img
- Use this system.img in kitchen's original_update folder
- WARNING - If using a ROM made from system.sin (not Nandroid), it
is recommended to flash from the temporary (fastboot) Clockwork
Recovery, rather than the regular Clockwork Recovery, otherwise
device may not boot (possibly because custom recovery files in
system folder are not added to ROM? e.g. recovery.tar).
ZTE Blade / Orange San Francisco
Help
- ALL INSTRUCTIONS, FREQUENTLY ASKED QUESTIONS, AND HELP - Posts #3 and #4
- Release Notes - Post #2
- Download optional plugins - Post #5
- Acknowledgements - Post #5
- General questions about Linux/Mac/Cygwin - Use Google
Download Kitchen
Please be aware that this project is semi-retired due to my bad health, family and life in general. I cannot keep up with updates all the time. Please read the important info above, all your answers should be found there. Download link is below. Have fun and I hope you support my work!
DOWNLOAD HERE
Support my work
DONATE VIA PAYPAL
Optionally send me a donation if you found my work useful (will go towards medical expenses, toys for my kids, etc.).
This is just a voluntary token of appreciation and not meant to be pre-payment for something that you want me to do.
FOLLOW ON TWITTER
Follow news about the kitchen on Twitter
.
NOTE: Please do not copy the entire first post, release notes, and FAQ pages into your personal thread. (Yes, people actually do this!) Apply common sense and use the link from here.
Release Notes
Version 0.224 (June 16, 2013):
Added support for Galaxy S4 variants (AT&T/Rogers/Bell/Telus/T-Mobile) (tested), GT-I9500/I9505 and more (untested)
Added support for HTC One (m7)
Fixed an issue where BusyBox entries in updater-script may not be detected, causing kitchen to potentially add another BusyBox entry
Updated default symlinks list for updater-script
When backing up app and framework folders during de-odexing, ensure their subdirectories also included
Version 0.223 (March 12, 2013):
Fix: Changed method of flashing boot.img in AT&T Galaxy S3 (package_extract_file with no tmp folder)
Fix: Don't check for tomb.img.ext4 unless Galaxy S2 ROM used
In Amend/Edify conversion menu, submit a default choice if user presses Enter, depending on whether updater-script or update-script (or nothing) present
In Amend/Edify conversion menu, show whether user has updater/update-script
If applicable, show mount point for boot.img after converting to updater-script
Show kitchen version when showing working folder info
Version 0.222 (March 7, 2013):
Added support for Qualcomm-based Galaxy S2 Jelly Bean ROMs, including extraction of tomb.img.ext4
When de-odexing Galaxy S2 Jelly Bean ROMs, keep track of APKs moved from /preload folder, and move them back when done (don't move other files)
When changing API value for de-odexing, remove the yes/no prompt and proceed straight to entering value (0=cancel)
Version 0.221 (February 16, 2013):
Fix missing wi-fi symlink issue in MTK65xx ROMs that use an EXT4-formatted system.img for the base ROM
Version 0.220 (February 2, 2013):
Automatically handle how /preload folder's APK/ODEX files are moved before de-odexing Jelly Bean ROMs for Exynos-based Galaxy S2 and Note.
Version 0.219 (January 23, 2013):
Updated smali/baksmali to 1.4.2 (for de-odexing)
Updated Zipalign to 21.0.1
Added support for HTC One V CDMA, HTC One X+ (AT&T and International), HTC Droid DNA
Updated updater-script definitions for HTC One XL and One X
PLEASE DO NOT DUPLICATE THIS POST UNDER YOUR OWN THREAD!
Release notes for all previous versions starting at Version 0.1 are found in the attachment below
.
Installation instructions
Frequently Asked Questions - Page 1
PLEASE DO NOT DUPLICATE THIS POST UNDER YOUR OWN THREAD
Please note that your ROM will not flash correctly on your device if the device is not supported by the kitchen! Please see post #1 of this thread for the current list of supported devices. If you do not see yours listed, then follow the instructions in the section below, entitled "How to add new devices".
What operating systems are supported, and how do I set them up for the kitchen?
Choose one of the installation methods based on your computer's current operating system:
1) Windows (2000, XP, Vista, 7, 8)
You have three options in Windows, so choose one (I use #3, the Wubi Linux method, as the kitchen runs fastest there):
(WINDOWS OPTION 1) Install Cygwin, which is a Unix environment for Windows. Keep in mind, however, that the kitchen runs much slower on Cygwin than on Linux or Mac OS X, and Cygwin (because it is a Windows utility) sometimes has issues detecting symbolic links in ROMs and upper/lower case differences between files. I've done as much as I can to resolve some Cygwin issues in the kitchen, so most of the time it works great, but it's not always perfect. For the kitchen, you can install a custom Cygwin that has all the required packages to run my scripts:
Download and install Java JRE for Windows from this link.
Go to http://www.cygwin.com to download the setup.exe. DON'T install it yet.
See the attachment called 'cygwin_install.txt' at the end of this post to install Cygwin and the required packages for the kitchen. It also contains instructions for making Java work within Cygwin. NOTE: You cannot run the kitchen without the packages specified in this help file!
NOTE: If you already have an old installation of Cygwin on your PC, you might be missing some packages that are required for the kitchen to work. Open the 'cygwin_install.txt' attachment to see which packages you may need to install.
(WINDOWS OPTION 2) If you want Linux instead of Cygwin, and you want it to be installed safely (no partitions or bootup modifications), then you'll need to download a "virtual machine" in Windows.
Using virtual machine software means you don't need to go through the trouble of creating a brand new partition or wiping out your hard drive just to install Linux. You can run it inside of Windows.
NOTE: You'll need a fast PC with lots of RAM!
Click here for video tutorial from theunlockr.com to assist you with the Ubuntu Linux install.
First, download and install the virtual machine software (e.g. the free VirtualBox, or pay for VMWare).
Next, we'll need to install Ubuntu Linux inside of it. Follow the instructions in the next section ("Ubuntu Linux") for setting it up for the kitchen.
(WINDOWS OPTION 3) If you want Linux but think Virtual Box is too much effort to install, or it runs too slow for you, then you can try the 'Wubi' installer from Windows. This method will install Ubuntu Linux inside a file in your Windows operating system and will boot from it.
Use this method only as a last resort, as it will modify your PC's boot loader and may also require some hunting for video drivers if you're not lucky. The benefit to this method is that it runs the kitchen super fast. The downside is that setting it up may require some technical expertise and Linux experience! If it's not working out for you, just go back to Windows and run the Wubi installer again to uninstall.
You can find lots more info about Wubi in YouTube and Google search. In the meantime, here is a summary of instructions:
First, download and install the Wubi installer. A good size to allocate for Ubuntu would be 20 GB (e.g. for Ubuntu 12.10).
When it finishes installing, the PC will reboot. Select Ubuntu from the boot selection menu.
NOTE: If the screen remains blank afterwards and never shows the login screen, then you have a video driver issue. You will need to reboot, and then at the Ubuntu boot options, press 'e' to edit the command line. To force the generic video drivers you will need to add something like this: nomodeset (Just Google it)
When you arrive at the desktop, configure your Wi-Fi connection by clicking on the seashell-shaped icon at the top right section of the screen.
Follow the instructions in the next section of this FAQ ("Ubuntu Linux") for installing Java. That should be all you need to do. I really hope this helped you out.
NOTE: If you had to do the video workaround earlier on, then you'll need to edit /etc/default/grub and change the appropriate lines so that it always boots up in this mode and so you won't need to edit it every time in the boot menu. i.e. Open up an xterm and then type sudo vi /etc/default/grub, modify the file, then type sudo update-grub. Again, Google is your friend.
TIP: You can find your PC's Windows file system under the /host folder.
Click to expand...
Click to collapse
2) Linux (Ubuntu recommended)
Download the Ubuntu Linux CD ISO image. The latest version is here at this link. You can either install it inside a virtual machine in Windows, or by itself on a separate partition on your PC. Other Linux distributions may work (e.g. Fedora, Mint), but have not been fully tested.
If you're using a virtual machine like VirtualBox to install Ubuntu, then create a New virtual machine; go to Settings, and in the Storage menu choose the Ubuntu .ISO file as the CD/DVD device. When you Start the virtual computer, it will boot from this "virtual" CD. Then you can install Ubuntu. I would recommend a virtual hard disk size of around 25GB and that you allocate about 1.5GB of your PC's RAM to Ubuntu.
If you instead want to install Linux on a brand new partition on your PC, I won't provide the details about installation -- you should be able to figure this out, or use Google. But I wouldn't recommend this method if you're new to Linux; it may not be safe and you run the risk of messing up your other partitions if you don't know what you're doing.
After Ubuntu is finished installing, you need to install the Sun Java JDK as well:
Open up an 'xterm' window (shortcut: CTRL + ALT + T)
If you're using a 64-bit version of Ubuntu, then type this in your xterm: sudo apt-get install ia32-libs
Open up the shortcut for the Ubuntu Software Center (the 'Ubuntu market'), click on the search option in the top right (where the binoculars are) and type: java
(If you don't have the Software Center, install it with 'sudo apt-get install software-center')
You should get a bunch of results, but you only need "OpenJDK Java Runtime", which should normally be the first result. Click on "Install"
After installation has completed, verify Java has been installed by typing in an xterm: java -version
NOTE: If you are unable to get these steps working (e.g. you have Ubuntu installed on a USB drive), then follow this old procedure.
If you used Virtual Box on your PC to install Ubuntu, then the following steps will finish up your installation:
Install the Guest Additions
NOTE: If you followed the guide and 'cd /media/cdrom' does not exist, then type instead: cd /media/VBOX* )
Next, if you want to copy ROMs and other files between Windows and your Linux Virtual Box, then do this:
Create a folder on your PC that you want to be accessed from Linux. e.g. C:\temp
From your Ubuntu session, click on Devices --> Shared Folders. Then click on the "+" sign to add a New Share.
Type the Folder Path (e.g. C:\temp) and give it a Folder Name (e.g. pc_temp), and check the Make Permanent box. Click OK to close the dialogs.
Open a terminal in Ubuntu and create a folder that will mirror the contents of your PC's shared folder. e.g. mkdir ~/shared
Then mount the reference to the PC folder to your new Ubuntu folder, e.g. sudo mount -t vboxsf pc_temp ~/shared
If successful, then whatever you copy to your PC's folder (e.g. C:\temp) will also be seen under the new folder (e.g. ~/shared) in Ubuntu.
If you want this Ubuntu folder to be automatically created every time you reboot into Ubuntu:
Type: sudo vi /etc/rc.local
In the rc.local file you will need to insert a line before the 'exit' statement; this line will contain the 'mount' command as shown above. But this time replace the tilde (~) with /home/your_user_id, e.g. sudo mount -t vboxsf pc_temp /home/your_user_id/shared
If you need help with vi or any other editor, google it. You need to use 'sudo' (as shown in first step) before you edit a system file like rc.local.
OPTIONAL: If you want your Android device to show up as a USB device under Linux automatically, you need to create a USB Filter in the VirtualBox Settings. Follow the guide here.
Click to expand...
Click to collapse
3) Mac OS X
You need OS X 10.4 (Tiger) or higher on an Intel-based Mac (PPC-based systems will have problems).
Ensure you have the Sun Java JDK. This normally comes installed already on your Mac. To test, just type in a terminal: java -version
Install gcc (C compiler) if you don't have it by default. Just type 'gcc' to verify you have it. Otherwise, follow these instructions to obtain it:
It is included in the Xcode Tools package on your installation DVD (more info found in Google) or in the Mac App Store, or go to the Apple developer site to sign up and download the Xcode package (it's big!)
Note: OS X Tiger 10.4 cannot use higher than Xcode 2.5. Use this link to search for older versions
Run the Xcode Tools installer to get gcc installed. In newer versions of Xcode you may need to go under its Preferences->Downloads option and install the Command Line Tools to get gcc.
Ensure you have the GNU version of wget. To verify you have the correct version, type wget --version. If this command works without error, and it mentions "GNU" in the output, then it should be good.
If that doesn't work, you might have to build the GNU version of 'wget':
Go to the GNU site to grab the latest tar.gz of wget (I found wget-1.12 worked best).
Go to the folder containing the extracted files, and type: ./configure; make; sudo make install
NOTE for OS X 10.8+: If "./configure" gives errors, then try instead: ./configure --with-ssl=openssl
Confirm that the system defaults to the GNU version of wget, by opening a new terminal and typing "wget --version" again. If you still get an error, type: sudo cp /usr/local/bin/wget /usr/bin/wget
Ensure you have the GNU version of sed, as the default Mac OS X version (FreeBSD) of sed is not compatible with the kitchen. To verify you have the correct version, type sed --version. If this command works without error, and it mentions "GNU" in the output, then it should be good.
If that doesn't work, you might have to build the GNU version of 'sed':
Go to the GNU site to grab the latest tar.gz of sed.
Go to the folder containing the extracted files, and type: ./configure; make; sudo make install
Confirm that the system defaults to the GNU version of sed, by opening a new terminal and typing "sed --version" again. If you still get an error, type: sudo cp /usr/local/bin/sed /usr/bin/sed
Ensure you have the GNU version of od, as the default Mac OS X version (FreeBSD) of od is not compatible with the kitchen. To verify you have the correct version, type od --version. If this command works without error, and it mentions "GNU" in the output, then it should be good.
If that doesn't work, you might have to build the GNU version of 'od':
Go to the GNU site to grab the latest tar.gz of coreutils.
Go to the folder containing the extracted files, and type: ./configure --disable-acl; make; sudo make install
Confirm that the system defaults to the GNU version of od, by opening a new terminal and typing "od --version" again. If you still get an error, type: sudo cp /usr/local/bin/od /usr/bin/od
Install the FUSE tools:
If you have a 64-bit Mac system (newer), then install OSXFUSE first, and select the MacFUSE Compatibility Layer when you install it. If you have a 32-bit Mac system, install MacFUSE instead.
After the above step is completed, install fuse-ext2
Test the installation by typing "fuse-ext2" at a command prompt. If you get a "Library not loaded" error then you have an incompatible version of MacFUSE (usually because your Mac may be 64-bit and you are using an older 32-bit version). Just install the correct version.
If you've come this far and managed to complete all the steps successfully, then give yourself a pat on the back!!
Click to expand...
Click to collapse
After following the setup for the operating system, how do I use the kitchen?
Summary:
Download kitchen
'cd' to folder containing kitchen
Start kitchen with: ./menu
Customize and build ROM
Detailed instructions (for newbies):
Download the kitchen from the first post of this thread.
Then, extract the kitchen's .zip file contents to your 'user' folder.
In Cygwin, this folder would be located under the 'home' folder of your install directory, e.g. C:\cygwin\home\<your_windows_id>.
In Linux / OS X this would be the folder where your terminal command prompt starts at, e.g. /home/<your_login_id>.
Then, in this folder, create a folder called "kitchen" and put all the kitchen files and folders under there.
For example, if 'johnsmith' is your login or user ID:
Code:
c:\cygwin\home\johnsmith\kitchen\ Should contain:
- menu
- original_update\
- tools\
- scripts\
(... etc.)
NOTE!! If your user folder name contains spaces (e.g. C:\cygwin\home\John Smith\kitchen), then the kitchen will not function properly. Instead, copy it one level up, under C:\cygwin\home\kitchen instead.
Easy so far, right?? Some people get the above steps wrong because they rush and then skip the instructions, and then get stuck in the next few steps. If you've followed the above instructions exactly how I've said so far, then you should be okay and can proceed with the rest.
I'm making the following as newb-friendly as possible, which is why it looks longer than it should:
Now, when you've figure that out, open up a command prompt (If you installed Cygwin, then click on the Cygwin shortcut on your desktop to start it - Yes, I know it's obvious, but some people don't know this).
Normally, by default, you will start at the 'user' directory (e.g. C:/cygwin/home/johnsmith)
From the command prompt, go to the folder containing the kitchen:
e.g. if your kitchen is under your user folder like c:\cygwin\home\johnsmith\kitchen, then you would type: cd kitchen.
e.g. If your kitchen is instead one level higher like c:\cygwin\home\kitchen then you would need to type. Type: cd ../kitchen
If you read the instructions then the above should go fine without any errors. However, if you didn't, then shame on you Read the following (skip this section if you're already in the correct kitchen folder):
e.g. If your kitchen is instead at an even lower level like c:\cygwin\home\johnsmith\blah\stuff\android then you would type: cd blah/stuff/android
In Cygwin, if you copied it under c:\some_other_folder instead, then you'd need to do: cd /cygdrive/c/some_other_folder
If you have no idea what folder you're in, type: pwd and then compare with the kitchen folder in your file explorer to confirm you're in the correct folder. Use the "cd" command to move to the correct folder, e.g. "cd <path_to_kitchen_folder>"
If you are still lost, well, this is probably not for you then... go back to iPhone (just kidding) I have already given you a crash course in Unix commands. Go back to the beginning and make sure you did everything right. Or just Google it.
To confirm you are in the correct folder, type the following to see the kitchen files and folders: ls (that's a lower case L and an S). You should see the file called 'menu', the folder called 'original_update' and more.
Once you've figured out the above (NO ERRORS), then proceed:
When you are in the correct folder, start up the kitchen by typing: ./menu
NOTE1: If you get a 'permission denied' error, then you must type chmod +x menu and run ./menu again.
NOTE2: If you get an error message about the file not being found, then it means you are not in the directory containing the kitchen!
NOTE3: If you get an error message about missing binaries like 'clear', read Part 2 of the FAQ for solutions.
Good? If the kitchen starts up, then you're ready to make a custom ROM! Finally.
Select Option 1 to set up your working folder (the folder where your ROM is going to be created). To find a base ROM to import into this kitchen, follow the instructions in the section below entitled "How do I import a ROM into the kitchen?"
Modify whatever you'd like in the kitchen
If you want the ROM to be able to run apps that require root permissions, select the "Root" option.
You can remove unneeded apps (*.apk) from the /system/app folder of your working folder.
If you want to add Market or non-stock apps (*.apk) to your ROM (which can be uninstalled or updated from your device later) then select the kitchen's menu option that adds "/data/app functionality". Afterwards you can copy these .apk files to the new /data/app folder of your working folder. If you put those extra apps under /system/app instead then you won't be able to update most of them through the Market.
Optional: Read this post for some more information about the fundamentals of creating your ROM with this kitchen.
When you are finished modifying your ROM, just choose Build ROM.
Your completed ROM can now be copied your SD card, ready for flashing from the recovery menu!
NOTE: It is always recommended to make a Nandroid backup from the recovery menu before flashing a new ROM!! The recovery menu allows you to recover from a non-bootable ROM.
How to add new devices that are not listed in the Supported Devices in Page 1?
WARNING: If your device is not listed in post #1 of this thread, and it does NOT use a 'YAFFS'-based filesystem (e.g. usually only low-end devices use YAFFS), do not attempt to flash a ROM that you built with this kitchen. Instead, you must do the following if your device is NOT listed:
Create a file under the kitchen's /tools/edify_defs folder, with the name being the same as the value of ro.product.device (found in your device's /system/build.prop file).
If the stock ROM images for your device contain the recovery.img file, extract its files from the kitchen menu: Advanced --> Tools for boot image --> Extract from boot.img/recovery.img in any folder. Then, open up its ramdisk folder, and look for /system/etc/recovery.fstab or /etc/recovery.fstab or similar FSTAB file location. Open this file to find the mount points.
See the template file in the edify_defs folder to see how to set the mount points inside the file you created. Look at the other files in that folder for examples on how to do it.
NOTE: This method does not guarantee your device will work with your custom ROM, however. Some devices may require more steps than just the edify_defs file, but the procedure is outside the scope of this FAQ. Ask around in the XDA sub-forum for your device if you need further help.
How do I import a ROM into the kitchen to use as my base?
(The instructions below are for HTC devices in general. For other devices, please visit the appropriate thread.)
From a shipped ROM:
First, find the shipped ROM for your device, usually from htc.com or from searching xda-developers (check the Wiki or sticky posts under your device's sub-forum).
This link may help: Various devices
Please don't ask me for links, as I don't know everything or own all devices.
The shipped ROM can be found in three different formats. Identify the type you have downloaded:
If the shipped ROM is in a .ZIP format, then simply copy it to the kitchen's original_update folder.
OR if the shipped ROM consists of system.img and boot.img files, then copy those two files to the kitchen's original_update folder. If the ROM also includes a lib.img (found in some newer HTC ROMs), then copy that as well!
OR if the shipped ROM is in an .EXE format, then do the following:
In Windows, run the shipped ROM's .EXE file till it gets to the first dialog. Stop there but don't close the window yet.
Go to Start->Run and type: %TEMP%
When the folder opens, search for Rom.zip (use the "magnifying glass" Search button)
Copy Rom.zip to your kitchen's original_update folder
OR from a cooked/custom ROM:
Copy the update.zip (or equivalent ZIP file) to your kitchen's original_update folder
OR from a Nandroid backup (under /sdcard/nandroid) [NOT RECOMMENDED FOR NON-STOCK ROM BACKUPS]:
Copy the system.img and boot.img files from the backup folder to your kitchen's original_update folder
Please see Page 2 of FAQ (Other Questions) - in next post!
.
Frequently Asked Questions - Page 2
PLEASE DO NOT DUPLICATE THIS POST UNDER YOUR OWN THREAD
QUESTION: Does the kitchen support ROMs for Device X??
See post #1. If it is not listed there then I have not done anything for it, and I have no idea about it. Keep in mind that this is primarily a kitchen for HTC devices. Most of the ROMs for non-HTC devices that are supported in the kitchen are there because they are easy to support, as their file structure is not much different from that in HTC ROMs. However, certain devices use a completely different ROM file structure, so they are currently not supported in the kitchen. I am also limited by the fact that I only own one or two Android devices at a time, which affects the extent of my testing. Finally, please don't expect me to do every Android known device known to man, as I am a busy guy with mouths to feed, like a lot of you.
QUESTION: Whenever I double-click on the 'menu' file in Linux or Mac OS X, the screen immediately closes or I get an error like "File not found."
No, do not click on the file. You were instructed to type "./menu" from the command prompt. Follow the instructions as they have been given. Please refrain from asking me this question again and again, or from requesting me to fix it - double-clicking is not how shell scripts are meant to be run!!
QUESTION: Whenever I type ./menu to start the kitchen it says "Permission denied."
Your file attributes are somehow missing the 'execute' flag. Type the command chmod 777 menu (or chmod +x menu) and try ./menu again.
QUESTION: In Cygwin whenever I type ./menu it says the 'clear' command (and/or other binaries like 'chmod') is not found.
Read this for possible solutions; however, these instructions only apply if you used the old (2010-2012) method of installing Cygwin for the kitchen.
QUESTION: What versions of the Java JDK are supported with this kitchen?
I have successfully built ROMs using Java 5 JDK and also later versions.
QUESTION: In the Advanced Menu's boot.img tools, why is there only an option to unpack a boot.img but not to re-pack it?
There is an option, you just need to unpack it first! Read this.
QUESTION: When I flash a ROM I get an error with a Status code. What does it mean?
Why don't you read the full error message first so that you understand why it's failing. Next, google the error. Anyways, this is what the status codes should mean:
Status 0 might be two things: 1) You used an update-script (Amend format, which is very old) when you should be using an updater-script (Edify format), or the other way around; OR 2) Your updater-script is using the "MTD" partition type when mounting a partition rather than another type such as EMMC (and thus, you need the device defined under the kitchen's /tools/edify_defs folder).
Status 6 might be two things: 1) You edited your updater-script with a non-Unix-compatible text editor. Don't use Notepad or MS-Word!! You must use something like gVim or Notepad++. OR, 2) There is a syntax error in your updater-script.
Status 7 means your mount points in the updater-script are wrong and/or your update-binary is not the correct type and doesn't support the syntax used for the mount points. Also, ensure your boot.img is using the correct instruction in the updater-script for flashing it.
QUESTION: I flashed a ROM and when it boots, it gets stuck on the splash screen (boot loop) or goes back to recovery menu.
If you are stuck on the splash screen, the first thing to try is to wipe the cache and dalvik-cache from the recovery menu. A full wipe may also be required, although I would not recommend it until you try the suggestions below.
Debug the issue with "logcat" (you need the Android SDK to use it):
Take out the battery so that the phone is turned off.
Then, go to the Android SDK, change to its 'tools' folder, and type "adb logcat". It will tell you that it is waiting for a device to be detected.
the phone into your computer's USB port, then turn it back on and check the logcat output. When the phone gets back to the same problem, check the logcat output for any error messages (e.g. missing files). This should tell you what the true problem is, which can hopefully be fixed.
If you want to direct the logcat output to a file, type instead "adb logcat > c:\logcat.txt".
If you want to share the output, paste it to a site like pastebin.com. If it's not a problem with the kitchen then post it in another thread in the Chef forum, rather than in this thread.
Another thing to do is to grab the "recovery.log" file immediately after you flash the bad ROM (BEFORE the first reboot!!). This shows a log of the activity during the current recovery menu session (i.e. during the flash). This log may also show errors that were not caught when you were flashing the ROM.
In Amon_RA Recovery, you can easily access this file by accessing the menu option "Other->Move recovery.log to SD", which moves it to /sdcard/recovery.log.
Otherwise, you can usually find it under /tmp/recovery.log or /cache/recovery.log or /cache/recovery/last_log with ADB. Try to copy it to a location where you can view it. e.g. Type from your computer: "adb shell", followed by "cat /tmp/recovery.log > /sdcard/recovery.log". Alternatively, from your computer you can do: "adb pull /tmp/recovery.log", which will copy it to your computer.
Open up recovery.log with a text editor, but don't use Notepad, because it will put everything on one line instead of multiple lines.
Check recovery.log for any errors that occurred during the flashing process.
Remember, you must grab the recovery log output immediately after flashing and before you reboot. If you had rebooted afterwards, then the flashing's log information would have been cleared and you will need to flash again to get the log output.
QUESTION: After I flashed a ROM, it doesn't boot but I get 'File not found' and/or 'No such file or directory' (usually in reference to /system/bin/sh) error messages in logcat.
The /system partition was not flashed properly due to an issue on your device. This usually could mean one of the following:
You ported the ROM incorrectly. If you open up the recovery log (see the instructions above) you may see the reason, such as the device running out of space or errors copying to the system partition. Sometimes this is because the ROM is too large to fit into the phone's relatively small system partition in the internal flash. In this case, remove unnecessary apps from the system folder until you manage to fit the ROM into your device.
You ran a script in your updater-script/update-script but it had errors, thus halting the flashing process and leaving you with an incomplete flash.
You added Apps2SD to a device that does not support it. Did you ignore the warnings in the Apps2SD screen of the kitchen?
An inspection of your recovery log should help you determine the exact cause.
QUESTION: I get errors in the recovery menu when I flash a ROM.
This may mean your update-script/updater-script has errors or there is an issue with how the kitchen created your ROM. Read the rest of the FAQ for potential solutions, or you may need to inspect the recovery.log to debug the issue (see above).
QUESTION: When I flash my ROM, some of my changes don't appear, e.g. Apps copied to my working folder's /data/app.
Check the recovery.log to debug the issue (see above).
QUESTION: Can you help me port a ROM? Or can you tell me if Device X's ROM can be ported to Device Y?
No, I am not an expert on porting so I cannot help you; however, there is a Porting option in the kitchen. Keep in mind though that it is not the magic solution for all devices and will not work all the time. It uses a very generic set of rules for porting, which can be seen if you open up the appropriate script files. The recovery log and logcat tool should help you debug issues with porting (see instructions above).
QUESTION: What is an update-script or updater-script file?
This is a file found under the META-INF/com/google/android folder, and specifies the operations required for flashing your ROM. It performs various file operations, such as creating file shortcuts (also known as symlinks or symbolic links), adding permissions to files, running scripts and copying files and folders. After flashing your ROM this file is not executed again.
The updateR-script is more advanced than the update-script and supports more devices. When you see someone refer to "Edify" format they are talking about the updateR-script; whereas "Amend" format refers to update-script.
The updateR-script also requires an update-binary file included with it. The update-binary contains all the binaries for the commands that the updater-script uses (e.g. set_perm, symlink, format, mount, etc.). The update-script does not need an update-binary.
Unlike the update-script, the updater-script is supported in newer versions of ClockworkMod Recovery.
QUESTION: Why do I need to convert the ROM's updater-script to an update-script when using the kitchen?
First of all, the kitchen supports updater-scripts. BUT, the problem is that the updater-script in different devices (and by different authors) may use various formatting/alignment styles, mount points, partition types and may also employ different commands for the same functionality, and thus there would be an awful lot of variations to check for every time a kitchen script is using it. Hence at the beginning, the kitchen will convert the updater-script into a universal format (e.g. I chose the update-script format) so that all the scripts of the kitchen will work on the ROM without encountering these issues. When the ROM is built, the kitchen converts it back to an updater-script with the correct syntax, and the partition details are fully restored.
If we didn't convert the updater-script then it would take A LOT OF work to overhaul the dozens of scripts to accept updater-scripts, which would really NOT make a difference in the end anyway, and would likely slow down the kitchen due to extra checks made in the updater-script. So please do not request this again and again, there is no gain in doing it. Believe me, I have spent many months and stayed up late many, many nights getting this update-script/updater-script compatibility issue working with the kitchen with all ROMs and numerous HTC and non-HTC devices.
When you build the ROM you have the option of converting it back to an updater-script, or the kitchen will convert it automatically if it decides it's necessary. The conversion back to the original updater-script is near-perfect, as I have already spent months on the implementation to get it right.
If you want to instead convert your updater-script or update-script *before* you build, then use the option found under the Advanced section of the kitchen menu.
QUESTION: I have converted my update-script to an updater-script, but after flashing I still have the original ROM on the device.
That means your updater-script did not have the proper mount points defined for the system (and/or data) partition. Refer to this post for more info. EDIT: You can now add your own mount-point definition file to the kitchen's "tools/edify_defs/" folder for when it creates the updater-script for your device.
QUESTION: My device only supports ROMs with the updater-script/update-binary files but not the update-script
If you extract a ROM that contains an updater-script, then the kitchen will ask you if it should convert it to an update-script. You *must* use an update-script while customizing the ROM, as the kitchen is not capable of modifying updater-scripts. When you are ready to build the ROM, though, you will need to convert it back to an updater-script if the device requires it. Use the option in the Advanced menu to convert update-script to updater-script, or else the kitchen will ask you to convert it while building the ROM.
QUESTION: When flashing my ROM I get the error "mount expects 4 args got 3" or similar.
This refers to the fact your mount command takes 4 parameters (e.g. ext4, EMMC, /dev/block/.., /system) and your update-binary file only checks for 3 parameters. You'll have to change the update-binary file to a compatible one, found under the /tools/update_files folder. Just copy the appropriate file and rename to update-binary. e.g. If you're going to be using MTD partitions, copy 'mtd-update-binary' to /META-INF/com/google/android as "update-binary".
QUESTION: How do I get Ubuntu to see my device with ADB?
First, download the Android SDK and copy it to a folder like ~/AndroidSDK/
Then, use the following commands:
Code:
cd ~/AndroidSDK/tools
./adb kill-server
sudo ./adb start-server
./adb devices
If you want to try Linux commands on your device, you can use the "./adb shell" command, e.g. ./adb shell reboot
QUESTION: I get the following error when flashing a ROM: E:Board does not support mtd utils.E:Failure atline 77: write_raw_image PACKAGE:boot.img BOOT:
Please see this post for the solution. In some recovery menus the boot.img cannot be flashed straight from the ROM's ZIP, so it needs to be copied first to a temporary area on your device and then flashed from there.
QUESTION: How do I add or port a kernel to my kitchen's working folder?
Follow the instructions here.
QUESTION: I get busybox errors during flashing; e.g. "Can't chown/mod /system/xbin/busybox (No such file or directory)" or "E:Can't symlink busybox ..."
Apparently you need to upgrade your SPL, and it has nothing to do with the kitchen:
http://forum.xda-developers.com/showpost.php?p=5268241&postcount=12
http://androidcommunity.com/forums/276808-post16.html
http://forum.xda-developers.com/showpost.php?p=4247486&postcount=5638
QUESTION: While flashing my ROM, I get an error about 'assert getprop ("ro.product.device")'.
Read about a solution here. You will likely need to modify your build.prop and update-script files in the kitchen and rebuild the ROM.
QUESTION: I created a ROM with root permissions, but whenever I access an app with the superuser prompt, it hangs or force-closes.
Under Settings/Applications, ensure that USB Debugging is enabled. You probably disabled it after flashing your ROM.
QUESTION: When I flash my ROM in the recovery menu, I get an error like "E:Can't open (bad)".
You may need to change your custom recovery menu. For example, see here.
QUESTION: How do I add a theme to my ROM?
I don't know, as I just write the scripts and am not a ROM theming/modding expert. Please ask in the forum but not this thread, as I cannot help you with your question. Sorry.
QUESTION: Can you add APK decompilers and other APK modding tools? Or how about PNG optimizers?
See this answer.
QUESTION: Can you give me an explanation of de-odexing?
De-odexing will take the *.odex files in your ROM and convert them into classes.dex files, which will then be zipped into their corresponding APK or JAR files. For a technical overview, read this. A short summary of why it is used is in this post.
QUESTION: Can you add an option in the kitchen to odex a de-odexed ROM?
No. I don't know how to do it with a kitchen and probably don't have the time at the moment.
There is a way to do it, but not from your computer. The odex script must be run on your device - within the Android command shell - after the de-odexed ROM has been flashed (I don't have the script, just Google it). (Here's a thread about it but the link to the script is dead.)
QUESTION: Why do some applications in the data/app folder force-close and others don't?
Probably they have native libraries which are not installed after you flash your ROM. Use the Application Verifier in to check such apps, and to make the required update.zip to flash after you have installed the ROM (see the Plugins section in this thread, after the FAQ).
QUESTION: When we build the ROM, why can't we create a new system.img instead of a ZIP file?
Read this post.
QUESTION: What is Apps2SD and what version does the kitchen use?
There are multiple 'types' of Apps2SD -- one is the implementation found in Android 2.2+ that gives you the option of moving your apps to the SD card. Normally however, this does not move all of the app components to the SD card, and not all apps support this feature.
The other Apps2SD is sometimes referred to as "Apps2Ext" and requires an extra step by the user beforehand to format a new EXT-based partition on your SD card for the apps (normally an SD card is in FAT32 format). Unlike the 'Froyo Apps2SD', the Apps2Ext feature moves everything to the SD card, even apps that normally do not support the storage card option. The Apps2Ext version is found in the kitchen as DarkTremor's Apps2SD (by XDA user tkirton) and supports older devices that have a very limited amount of internal storage.
QUESTION: I am using Ubuntu Linux on a 64-bit Windows PC, and whenever I run 'zipalign' I get an error about "No such file or directory".
You need to install the Ubuntu package "ia32-libs".
QUESTION: Can you include an option to overwrite the ROM's existing Apps2SD with the one in the kitchen?
Answered here.
QUESTION: Can I copy this FAQ for my own thread?
No, that's plagiarism. You are a lazy bum and I will hate you.
.
OPTIONAL: Download User-Contributed Plugins (used in Advanced Menu of Kitchen)
Android Builder - by gnarlyc
Downloads the Android open source code for use with the kitchen
Application Verifier for Data Partition - by StenaviN
Fixes issue where certain apps under /data/app folder of ROM cause force-close
HTC Plug-in pack - by stupidjerkheadface
Update Hosts - by -Mr. X-
Generates an ad-free 'hosts' file
Acknowledgements
Thanks to all the people who use the kitchen and also to those who voluntarily donated.
Reading and searching will always help you in this forum. I learned everything from several places, but these are the best sources:
Lox_Dev's cooking guide for HTC Hero: http://forum.xda-developers.com/showthread.php?t=551711
androidcustomrom's cooking guide for HTC Magic: http://forum.xda-developers.com/showthread.php?t=566235
androcheck's task killer guide to speed up your device: http://forum.xda-developers.com/showthread.php?t=622666
The 'No Idea' Blog - guide to making your own rooted Android ROM: http://lukasz.szmit.eu/2009/12/making-your-own-rooted-android-rom.html
JesusFreke's utilities for deodexing - http://code.google.com/p/smali/
tkirton's Darktremor Apps2SD - http://forum.xda-developers.com/showthread.php?t=670087
ChainsDD's Superuser package - http://forum.xda-developers.com/showthread.php?t=682828
And also thanks to all the Android developers and cooks who supplied the binaries for this kitchen. Last but not least, thanks to the custom recovery image developers, without whom the flashing of these ROMs would not be possible (Koush, Amon_RA, etc.). They all gave me the inspiration to create a kitchen!
Good work. I'll have a play around with this later!
Finally! a Linux kitchen! (who uses Windows? )
downloading .. thanks a lot man
great work!!!!! have been waiting for smthing like that for ages!
Thanks great work
vow! great to see some 1 respected from the windows mobile scene. I used to use ur onyx roms they were simply the best. Keep up the good work.
Thanks for Sharing...
Thanks Daniel.
Seems great work...
Code:
update.zip created, ready for signing
Creating folder OUTPUT_ZIP ...
Building signed_021510_162742.zip ...
Exception in thread "main" java.lang.NoClassDefFoundError: testsign
Caused by: java.lang.ClassNotFoundException: testsign
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Could not find the main class: testsign. Program will exit.
mv: cannot stat `signed_021510_162742.zip': No such file or directory
whats wrong?
@cTnko:
For some reason the tools/testsign.jar file was not automatically copied to your androidsdk/tools/sign folder. Just copy it manually and run the build.again. Hmm it worked for me though.
Did anyone else have this problem?
dsixda said:
@cTnko:
For some reason the tools/testsign.jar file was not automatically copied to your androidsdk/tools/sign folder. Just copy it manually and run the build.again. Hmm it worked for me though.
Did anyone else have this problem?
Click to expand...
Click to collapse
thank u that helped , dunno if it makes any difference but i run ubuntu 9.10 (fully updated) and i installed java via apt-get not via .deb packages
oh and just to let u know, 2.73.405.66 has higher CL (CL#83173) then the latest orange ROM files
Yeah Ubuntu 9.10 was fine for me, but after upgrading to 10.04 it uninstalled the sun java and made them obsolete. Thanks for the tip about the shipped Rom, I may include that one next time!
cTnko said:
thank u that helped , dunno if it makes any difference but i run ubuntu 9.10 (fully updated) and i installed java via apt-get not via .deb packages
oh and just to let u know, 2.73.405.66 has higher CL (CL#83173) then the latest orange ROM files
Click to expand...
Click to collapse
Just out of curiosity
Code:
2. Add root permissions
3. Add task killer tweak for speed (stock boot.img only)
does that mean when i apply/add root via 2 step, i cant use/add 3 step ? (because 2 step does some changes to the boot.img if i am not mistaken)
cTnko said:
Just out of curiosity
Code:
2. Add root permissions
3. Add task killer tweak for speed (stock boot.img only)
does that mean when i apply/add root via 2 step, i cant use/add 3 step ? (because 2 step does some changes to the boot.img if i am not mistaken)
Click to expand...
Click to collapse
You can do those steps in any order. In both steps, the script extracts boot.img from the Working folder (not the img_files folder), does the appropriate fix, and then rebuilds the new boot.img into your Working folder.
So you can do Step 3, and then Step 2 next if you want.. either way is fine.
thx for the info, i successfully cooked my 1st rom (from 2.73.405.66 release keys) all went well, i flashed the upy to date.zip, started using the rom, but when i try to use app that requires root, "app" with SU request pops, but seems to froze, i can only jump to home screen via Home button or go to sleep mode, any ideas what could went wrong ? (all manual modifications that i did was small "text" change in ro.build.description=.... ( i added my nickname on string ending)
cTnko said:
thx for the info, i successfully cooked my 1st rom (from 2.73.405.66 release keys) all went well, i flashed the upy to date.zip, started using the rom, but when i try to use app that requires root, "app" with SU request pops, but seems to froze, i can only jump to home screen via Home button or go to sleep mode, any ideas what could went wrong ? (all manual modifications that i did was small "text" change in ro.build.description=.... ( i added my nickname on string ending)
Click to expand...
Click to collapse
What app did you try with root? Have you tried running the Wi-fi tether or Titanium Backup?
dsixda said:
What app did you try with root? Have you tried running the Wi-fi tether or Titanium Backup?
Click to expand...
Click to collapse
I tried AutoKiller and ShootMe, gonna reboot my phone once again and give wifitether a shot

[Q] Cooking ROMs... I still don't get it

Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
oxiroxt said:
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
Click to expand...
Click to collapse
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
synesthete said:
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
Click to expand...
Click to collapse
OMG Finally some light! THANK YOU, THANK YOU, THANK YOU for all the info. I didn't get much right now, I'll need to read through your post a few times before I get it all, haha. I'll be sure to check the links too. Thank you!

SU for Android on ChromeOS

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]

How to root Wiko Lenny 5

Hello dear community, how can I root Wiko Lenny 5?
I would be very grateful for any idea. Thank you in advance!
No TWRP recovery
deadlyassin said:
Hello dear community, how can I root Wiko Lenny 5?
I would be very grateful for any idea. Thank you in advance!
Click to expand...
Click to collapse
Hi, there is no TWRP recovery at moment for this model, only unlock bootloader. Look here github com/phhusson treble_experimentations wiki Wiko-Lenny5
ROM for Lenny5
Would you mind uploading your firmware for testing? or sending a link to it...
My model: W_K400
I need to install the Recovery TWRP? Or Custom Rom? Or LineageOS? Or Root?
All nothing? Well, i am waiting. Thanks for your answer!
Wiko Lenny 5
Hey Peeps
I did some research on the Lenny 5 as i got this phone a few weeks ago.
There is at the moment, and to my knowledge, no Lenny 5 stock firmware available. I contacted Wiko Germany, asking if there is any place i missed and they answered me in the sense of:
"at the moment there is no stock firmware available online, refer to de[dot]wikomobile[dot]com/maj.php?telephone=2270 where a stock firmware should be uploaded shortly."
Still they didn't upload the file yet, so there only patience will help, if anything at all.
Another possible way i wanted to raise attention to is the site www[dot]wikogeek[dot]com/ where under www[dot]wikogeek[dot]com/index.php?telephone=LENNY5 there is a source seemingly for the phone system, although i don't know, what partitions of the phone system, if not all, are contained in the source code. Following the included Instructions, and doing some further research, i managed to compile some sort of Image which might be the way to get working partition images for the phone. I couldn't examine the image contents using a few different image explorers, so i cannot even tell how to work with the image if its of use at all.
I thought, maybe some of the more experienced users of this board could maybe work with this information to get something like TWRP to work even without having the stock firmware images. As this is my only working phone and my experience is little, i will not do any changes to the phone partitions as long as im not sure the result is a) working, as expected (no recovery required), or b) completely recoverable (at least to factory state), but maybe others are more courageous and want to try.
Hope this helps getting this topic to the latest state. Sorry for the non-URLs, i made the account specifically to contribute to this topic and my post count is to low to post complete urls.
ivelischt said:
Hey Peeps
I did some research on the Lenny 5 as i got this phone a few weeks ago.
There is at the moment, and to my knowledge, no Lenny 5 stock firmware available. I contacted Wiko Germany, asking if there is any place i missed and they answered me in the sense of:
"at the moment there is no stock firmware available online, refer to de[dot]wikomobile[dot]com/maj.php?telephone=2270 where a stock firmware should be uploaded shortly."
Still they didn't upload the file yet, so there only patience will help, if anything at all.
Another possible way i wanted to raise attention to is the site www[dot]wikogeek[dot]com/ where under www[dot]wikogeek[dot]com/index.php?telephone=LENNY5 there is a source seemingly for the phone system, although i don't know, what partitions of the phone system, if not all, are contained in the source code. Following the included Instructions, and doing some further research, i managed to compile some sort of Image which might be the way to get working partition images for the phone. I couldn't examine the image contents using a few different image explorers, so i cannot even tell how to work with the image if its of use at all.
I thought, maybe some of the more experienced users of this board could maybe work with this information to get something like TWRP to work even without having the stock firmware images. As this is my only working phone and my experience is little, i will not do any changes to the phone partitions as long as im not sure the result is a) working, as expected (no recovery required), or b) completely recoverable (at least to factory state), but maybe others are more courageous and want to try.
Hope this helps getting this topic to the latest state. Sorry for the non-URLs, i made the account specifically to contribute to this topic and my post count is to low to post complete urls.
Click to expand...
Click to collapse
Ok so Wiko Released the Firmware! Its a Windows software that downloads and flashes the ROM, and it makes a folder with stuff in it. Maybe experienced people can look into it and build TWRP?!! I would really love twrp but I don't have the experience :crying: . Hope developers see this
Matt 123456789 said:
Ok so Wiko Released the Firmware! Its a Windows software that downloads and flashes the ROM, and it makes a folder with stuff in it. Maybe experienced people can look into it and build TWRP?!! I would really love twrp but I don't have the experience :crying: . Hope developers see this
Click to expand...
Click to collapse
Would you mind adding a link to the firmware you've found?
edit: got it
Are you able to develop a TWRP?
Matt 123456789 said:
Are you able to develop a TWRP?
Click to expand...
Click to collapse
Nope, sorry. I just didn't get at first what firmware you refered to (the link i posted in the first place).
As i stated above, i don't know for sure, if the wikogeek-source really contains all of the files required to build anymore than (if even) the bootloader.
More experienced people would need to take a look into it.
Best regards
Hey again there, folks
Im not a excessive internet user and i may be off the site for months in series. i cannot guarantee any form of support, but if i happen to stumble across this thread and see questions that i can answer, i will do my best to do so. i hope i can encourage others to engage in the treble community in making this solution public. treble is not my work and i have nothing to do with it. maybe there is also a way to get twrp-treble versions, but i don't know what are the technical limits of that. what i want to say: i will not be responsable for your tries to hack your phone. if i can help i will, but i'm no pro in all of this at all!!!
This guide is quite long, but take care to not make mistakes, as it is reduced to what you really *NEED* to make this root method work. ALWAYS REMEMBER TO READ THE FULL GUIDE AND COMPLETELY PREPARING YOUR WORKSTATION BEFORE DOING ANY OF THE STEPS BELOW!!!
After some idling i decided to take another look into Lenny 5 rooting and stumbled across a way to do it pretty straightforward, but first of all:
*THIS GUIDE ASSUMES BASIC KNOWLEDGE ABOUT COMPUTERS AND FLASHING SMARTPHONES. IT ALSO ASSUMES THAT YOU KNOW WHAT ADB, FASTBOOT, ROM, IMAGE, VIRTUAL MACHINE, WORKING WITH WINDOWS AND UNIX PATHS AND OPERATING SYSTEMS, ETC. MEAN AND ARE FAMILIAR WITH THEIR USAGE. I WILL NOT PUBLISH ANY FORM OF PREPARED IMAGES NOR ANYTHING TO SPEED UP THIS PROCESS, AS IT MAKES YOU AWARE OF THE RISKS IN IT. I UNDERSTAND THIS AS SOME SORT OF COMMUNITY EFFORT, WHERE I JUST PRESENT ONE WAY OF GETTING WHERE YOU WANT TO GO. IF YOU DON'T THINK YOU CAN APPLY TO ALL OF THE REQUIREMENTS IN THIS GUIDE, YOU SHOULD CONSIDER TAKING DISTANCE FROM USING THIS GUIDE FOR YOUR ROOTING BEHALF.
DISCLAIMER: By using this method to Root your Lenny 5 you will lose all WARRANTY, DATA ON THE PHONE, YOU WILL NOT BE ABLE TO RETURN TO STOCK FIRMWARE as Wiko still did not share their SFW installer and i did not dig deeper into Source compilation. And LAST BUT VERY IMPORTANT: I DO NOT TAKE ANY RESPONSIBILITY FOR ANY DAMAGE ON YOUR PHONE. WHATEVER YOU DO IS AT YOUR OWN RISK!!! READ ALL OF THE TEXT AS THERE MIGHT BE CRUCIAL INFORMATION IN IT, WHICH I DIDN'T ESPECIALLY HIGHLIGHT. Allthough i will do my best.
DO NOT ATTEMPT ANY FLASHING UNTIL YOU GOT YOUR WORKING FIRMWARE IMAGE AT STEP 3 (3. Flashing the new Image to the Device). EXPERIENCED USERS MAY WANT TO FLASH A UNTOUCHED TREBLE IMAGE, WHICH IS ALSO POSSIBLE. YOU SHOULD ONLY EVER REFLASH YOUR DEVICE WHEN YOU ARE ABSOULTELY SURE ABOUT WHAT YOU DO AND THE (POSSIBLE) CONSEQUENCES OF WHAT YOU DO, INCLUDING, SOFT-/HARDBRICK, PERMANENT DAMAGE, AND OTHER NASTY STUFF. YOU TAKE FULL RESPONSABILITY FOR ANY OF THE STEPS YOU DO, ESPECIALLY BEYOND STEP 3!!!
I REPEAT: YOUR LENNY5 DOES NOT NEED TO BE CONNECTED OR EVEN TOUCHED TO YOUR COMPUTER AT ALL UNTIL STEP 3 (3. Flashing the new Image to the Device)!!!*
!!!READ THE BUGS LIST AND HELP OTHERS BY REPORTING OTHER BUGS YOU'VE FOUND IN THIS THREAD. IT IS IMPORTANT THAT YOU KNOW WHAT YOU ARE DOING HERE, BEFORE COMPLETELY MESSING UP WITH YOUR PHONES STORAGE!!! SO YOU BETTER READ THE WHOLE THREAD BEFORE TRYING ANYTHING
There is no Root-only method i know, SO BE AWARE, you are completely rearranging your Lenny 5 Firmware, which is the reason for complete data loss. Wiko DENIES ALL RESPONSABILITY when you unlock your bootloader, according to "phhusson", which is the reason you will lose all warranty.
Known bugs until now:
- On dual SIM handys, if you tell the handy to let you choose the sim card for each call, it will hang after choosing the Sim. The call will not happen. This is a Treble issue. To work around this, select the SIM you want to use in the preferences prior to making the call.
- It seems that after installing a newer Version of the AOSP image provided by phhusson, it is impossible to downgrade to an earlier version of the ROM. This might also be a bug in my device from tampering around with it. But it causes me to be unable to flash any other version than the newest one. If i do so, my device is stuck in a bootloop and i need to reset and reflash it via adb and fastboot. Maybe others can confirm/disregard this behaviour.
- This guide does not solve updating your phone, maybe i can deliver a solution to that at a later point. Until then, you will be urged to reflash your system each time an update is deployed.
- The configuration in this guide is gapps-less, although you might choose a treble-image, that's got them installed. I did not yet manage to install the opengapps-package seperately, as theres yet no solution to custom recovery (that i'm aware of) and i did not (yet) find out how to include it via the kitchen.
-many apps will require you to have at least basic gapps installed. you could compile treble aosp with the amount of google apps you need or use the gapps-img instead.
I will try to give an exact sequence of what to do to Root your Lenny 5 device, but some experimentation afterwards might be needed to get your best experience. Note that, depending on version and "bloating" of your new Firmware, you may experience more or less strong performance breakdowns. Be careful not to overload it, your Lenny 5's hardware is... lets say... not the best out there
Table of Contents:
0. Before starting
1. Preparing your Workstation
1.1.1 Get your copy of lubuntu 18+ (19 is recommended, the version of lubuntu i used in the whole process was 19.04)
1.1.2 Install Oracle Virtual Box
1.1.3 Install lubuntu 18+
1.1.4 Install openjdk-8+ (8 is recommended, i use that version, too)
1.1.5 Install python
1.2.1 Install samba
1.2.2 Configure samba
1.2.3 Connect to sambashare
1.3.1 A few words about handling file permissions in Linux
1.4.1 Get your copy of SuperR's Kitchen (what we do can be done in the Free version)
1.4.2 Install SuperR's Kitchen
2. Preparing your SuperR installation for your Custom AOSP Rom
2.1 Find out which Treble image you need
2.2 Copy and Extract your Treble image
2.3 Editing the contents (Rooting, etc.) of the Treble image
2.4 Repacking the Treble image
3. Flashing the new Image to the Device
4. Final words
0. Before starting
PLEASE CAREFULLY READ THESE STEPS BEFORE STARTING THE PROCESS!! There's a few things to say before starting to do this. I will use this section to note that.
ad 1.:
- If you are using (L)ubuntu 18+ or the corresponding Debian distributions, and already have OpenJDK-8(+)(-JRE) installed, you should be able to move straight to SuperR's kitchen installation. If the kitchen complains about missing OpenJDK, try installing OpenJDK-8(+)-JDK as well.
ad 1.1.1:
- I recommend placing a "Workfolder" somewhere on your host system, so you have all the corresponding data in one place. This helps accelerate the process a lot. In the rest of the document, i will always assume, that you have a workfolder and use it for all the files.
ad 1.1.3:
- i use 25GB for my virtual disk as i only unpack compiled ROMS (as for this guide). if you plan to use the VM for compiling sources, you should be well above 75 to 100GB as the source trees are HUGE.
ad 1.2.1:
- We will also create a workfolder on the virtual system, but this one we will take care of in the main tutorial steps.
- To make samba work, we need to make sure that VirtualBox connects to your Network as required. To do so, on the VirtualBox top menubar, Click on Devices -> Network -> Network Settings...
In the Drop-Down "Attached to:" choose "Bridged Adapter". Make sure that the "Name" Drop-Down shows the name of your physical LAN-Adapter. This way your Virtual Machine will obtain an IP from your local network router instead of NATing with your Host Machine as router. Click Okay. You can check the Network Mode change by using
Code:
ip a
in the terminal. If you want to make sure it changed the mode, restart your virtual machine and reopen the terminal by using CTRL+ALT+T again.
ad 2.1. the wiki-guide on Lenny 5 says "tested on v18". i had v18 installed on my system, but at some point it denied function. i don't know if this is a downgrade-issue or something else, but if you want to stick with it and are able to install it, feel free. but be aware that it does not contain the most recent security patches. i instead stick to AOSP8.1_v32 at the time of writing this guide.
ad 3. i assume that you have already installed adb. otherwise you can get it here in the forums or the specific wiko version from here. (WikoGeek Website) Just click on the download link.
it is important that you learn, that ~/android/... means the same as \\<yourvirtualdeviceip\androshare, if you closely follow this guide, especially the network and samba configuration.
1. Preparing your workstation
To prepare your workstation you must get a Debianesque Linux Environment running, as Windows (and Mac) User, the easiest way to get to this, is to install a Virtual Machine. For the sake of freelyness (is this even a word? ) we'll stick with Oracle's VirtualBox. This seems to be a lot of work, but it took me less than 2 hours to be completely ready to tamper with my image files. So lets begin.
Users on the correct systems ((L)ubuntu/Debian with Java 8 and python installed) can skip to 1.2.1
1.1.1 Get your copy of lubuntu 18+
Go to https://lubuntu.net/ and download lubuntu 18 if your pc hardware is 32-bit only, or lubuntu 19 for 64-bit hardware. You can do this by clicking the corresponding blue buttons on the main page or, if this doesn't apply anymore, find them in the Download section under the "previous lubuntu releases". Download the Image file and store it in your Workfolder
1.1.2 Install Oracle VirtualBox
From now on, all the steps mentioned will be either on the host-machine or the virtual machine i will clearly mark this out to avoid misunderstandings. Users already on correct systems will have to work-around these conceptions a little bit, but all in all the process should be the same for every workstation.
To install Virtual Box on the host-machine, get the installer for your host-system-architecture from https://www.virtualbox.org/wiki/Downloads. Follow the On-Screen-Instructions for the Installer to Setup VirtualBox for you. (I had it installed already, so i don't know the exact order of it. But maybe some of the users testing this out could come up with a quick "tutorial" for this step.) Most of the settings should be standard values.
After finishing the installation (and restarting?) you should now be able to Open the VirtualBox Manager via Desktop or Start Menu (whatever your host-OS offers, we will be sticking to Windows as host).
1.1.3 Install lubuntu 18+
In VirtualBox on your host-machine, create a "New" machine by clicking the button on the top left of the manager. As the name, choose how you want to memorize your virtual machine for later usage.
Use "Linux" as Type and "Ubuntu (32-bit/64-bit, choose appropriately)" as Version.
Your memory doesn't necessarily need to be gigantic. Still, i reserved 4GB of RAM for mine, and would recommend at least 2GB.
Check the radio button to "Create a virtual hard disk now" and click on "Create"
In the next dialog choose the Location for your VHD to be stored. The storage location should have around 25 GB of free space (read on section 0. for additional notes about storage space).
Choose your VHD size, i used 25GB to have some reserve, just in case. Click on Create. Choose your newly created virtual machine and select start from the top shortcut bar.
VirtualBox will come up with a new window and in it a dialog, asking for a installation medium for your new virtual machine. Click on the button to "Choose a virtual optical disk file..." and choose your previously stored Lubuntu disk image to mount as start-up disk. Click on Start, wait, then choose your Language. I recommend using english, so its easier to follow the tutorial, but this is up to you.
After that, you will be allowed to "Start Lubuntu" which we choose our virtual machine to do. The startup should be quite fast, from my experience. As soon as you get presented with your new (yet non-persistent) virtual desktop click on the icon to "Install Lubuntu xx.xx"
Soon the Lubuntu installer will come up, asking for the Language to be used. We'll keep American English (again, your choice) for now and click Next.
Choose your timezone and Region and click next. Choose your corresponding keyboard Layout, make sure it's the right one and click Next. In the next dialog step choose "Erase disk", leave the rest be and click Next.
On the next page, i recommend keeping it simple, as this is just a virtual machine, which ever only runs when you decide to extract and repack images. Enter "your" name, choose a login name, give the virtual machine a simple, locally-unique network name and choose a password for elevated rights operations. Remember, keep it simple, it will ease your work. I recommend to "Log in automatically without asking for the password" but i leave it to you to decide that. Click Next.
In the summary, check if you are okay with the Settings you entered, then click on Install.
Confirm the warning dialog with Install now.
Now it's all about Linux magic happening to create for you a persistent operating system on your virtual hard disk.
As the Installer asks you to Restart, do so by clicking on Done. Let the virtual machine reboot. When asked to do so, remove the installation medium (VirtualBox automatically does this for you, the options for this are under the main menu "Devices -> Optical Drives") and press ENTER.
After starting up, (and entering your password, if you didn't check the autologin checkbox), you are presented with your Desktop. On your keyboard press CTRL + SHIFT + T to open a terminal.
On a normal machine you should always keep your firewall on and setup. you can easily setup ufw for samba, but as we just crank around at a virtual machine (ideally behind a NAT-Router), it will be easier to just turn off the firewall alltogether by using
Code:
sudo ufw disable
in the terminal window (when asked for a password, enter your virtual machine user's password and press ENTER. at UNIX-like terminals it is normal that the password you enter will not be shown. don't worry, it's typing, just hiding. it will tell you after pressing ENTER, if its the right one or not.)
1.1.4 Install openjdk-8+
To install JDK on Lubuntu we use the built-in software installer. The following commands will update the system and install openjdk-8-jre
Code:
sudo apt update
you will be asked to enter your account password, enter password and confirm with ENTER
Code:
sudo apt dist-upgrade
confirm by typing "Y" into your keyboard and press ENTER.
This process will take a while, depending on your hardware and internet connection.
Code:
sudo apt install openjdk-8-jre
when asked, if you accept the changes to be made, type "Y" again and press ENTER.
this chain updates the virtual system packages and installs openjdk-8.
To check whether OpenJDK 8 JRE is installed, use the command
Code:
java --version
the output should be something like:
Code:
openjdk version "[B]1.8.0_222[/B]"
the bold part is the important, as it tells you that you have version 1.8.x, which is OpenJDK 8
Code:
OpenJDK Runtime Environment (build [B]1.8.0_222[/B]...
shows that the JRE version on your virtual machine is the same as the major openjdk version which is good.
1.1.5 Install python
To install python, use
Code:
sudo apt install python
this will install the required packages and configure them.
1.2.1 Install samba
To move files between your virtual machine and your host machine, the easiest way to do so is to use samba. It is easy to configure and fulfills our needs. To install samba enter
Code:
sudo apt install samba
into the terminal on your virtual machine and press ENTER. If asked, confirm changes with Y and ENTER.
1.2.2 Configure samba
We will configure samba in a way, so we don't need to "sudo" all of the time to use superr's kitchen, but instead use it as our autologin user. For this we will enter the following in our terminal (make sure that you didn't elevate ["sudo -i"] your terminal session, otherwise use exit, to return to unelevated session)
Code:
mkdir ~/android
chown -R [B]<yourusername>[/B]:[B]<yourusername>[/B] ~/android
cd ~/android
(the term "~/android" basically is a synonyme for "/home/<yourusername>/android; the ~ marks the path as inside your users /home/... directory)
this creates a folder called android in your virtual machine users home directory and changes the bash-path into it.
enter
Code:
sudo nano /etc/samba/smb.conf
to the terminal and press enter. this will open a console text editor with the samba configuration file. use PgDn or the Down-Arrow-Key to reach the end of the file and then append the following "code"
for <yourusername> use the username you selected during your virtual machine installation. its visible in the terminal before the ":" sign in the format
Code:
[B]username[/B]@[U]virtual[/U]machinename: ~$
Code:
[androshare]
comment = Android Share
path = /home/[B]<yourusername>[/B]/android
browseable = yes
read only = no
public = yes
create mask = 0644
directory mask = 0755
force user = [B]<yourusername>[/B]
save the changes by pressing CTRL + O on the keyboard and confirm with the ENTER key.
you can use the bash-command
Code:
testparm
and push ENTER to see your role configuration, and if you have made any mistakes in entering the configuration data.
to restart samba and make the share available enter
Code:
sudo service smbd restart
into the terminal and press ENTER.
sometimes the kitchen needs elevation for some tasks and will then write files that belong to the user "root". the easiest way to work around that is to sporadically use and memorize for later usage
Code:
sudo chown -R [B]<yourusername>[/B]:[B]<yourusername>[/B] ~/android
this will set file ownership to your user and thus allows you and shared samba-instances (as they are forced to run as your user) to regain read-write access to the respective files.
if you struggle with this, try asking in a new post (or maybe someone asked already?), maybe i or others can help you.
now you should be able to connect to your samba share.
1.2.3 Connect to sambashare
to connect to your newly created samba share, on your windows host machine use WIN + R or Startmenu -> Run... and enter \\<yourdeviceip>\androshare and press ENTER.
for other ways to connect to samba shares according to your host operating system, i must ask you to check google. this guide is long already, anyways. but its easily possible on any system (win,macos,linux,...)
to find your device ip, on the virtual machine enter the following into the terminal
Code:
ip a
you need to find the address obtained by your router. you normally find it under something like
Code:
1: lo:
...
inet 127.0.0.1/8 ...
2: enp0sX
...
inet [B]192.168.x.x[/B]
...
the bold part is important, while the upper address "127.0.0.1" is your local loopback address and not what we are looking for.
on your host machine enter the bold ip at <yourdeviceip> like this
Code:
\\[B]192.168.x.x[/B]\androshare
and press ENTER. this should open your Sambashare
1.3 A few words about handling file permissions in Linux
Sometimes SuperR's kitchen may create or modify files that are owned by root user, which prohibits you from changing these files without elevating via sudo. This is easily corrected by again using
Code:
chown -R [B]<yourusername>[/B]:[B]<yourusername>[/B] ~/android
if there are still files you can't access you can maybe fix it with
Code:
sudo chmod a+rwx ~/android/<fileyoucantmodify>
1.4.1 Get your copy of SuperR's Kitchen
SuperR's kitchen can be obtained at The Official SuperR's Kitchen Thread. Get the latest version. I use 1.2.1.1.
Download it to your host machine and put it into your host workfolder. from there, copy it to your \\virtualmachine\androshare directory.
1.4.2 Install SuperR's Kitchen
to install superr's kitchen, we need to unzip it. on the virtual host, type
Code:
cd ~/android
unzip [B]SuperRs-Kitchen_Linux-64_v1.2.1.1.zip[/B]
press ENTER and the archive should extract. if it did not extract, and instead throws an error about the package "unzip" beeing unknown to the system, use
Code:
sudo apt install unzip
to easily solve this problem, and repeat the upper step.
you can confirm that that unpacking was successfull by entering
Code:
ls -l ~/android/
into your terminal. the result should show at least a folder called "tools" and a file called "superr".
after confirming the correct extraction, use
Code:
rm [B]SuperRs-Kitchen_Linux-64_v1.2.1.1.zip[/B]
to delete the ZIP-File
replace the bold part with your SuperRs Kitchen ZIP-File Name.
Your ~/android directory should now contain 3 Elements, namely "README.md, superr" and a directory called "tools".
If everything went fine, you should now be able to start the kitchen by typing
Code:
./superr
into the terminal and pressing ENTER. if you are beeing told that you don't have permission to run this file as an executable, use
Code:
chmod ug+x ./superr
and repeat the above step. If everything worked, you should be asked to select your Language (english_srk.py). To choose it, type 1 on the keyboard.
The Kitchen will now ask you to download tools it needs to work properly. Allow it to do so by typing "Y" on the keyboard.
If everything went well, you should now be asked to enter your new Project name which identifies the folder, in which you will later store, modify and receive files. We will take care of that in the next step. This means, the Preparation process is over and you can now start using SuperR's Kitchen for your needs.
STEP 2 AND ON IN SECOND POST (CHARACTER LIMIT)
[CFW][W_K400][TREBLE] CFW and ROOT, MOSTLY-VANILLA
PART 2 OF THE POST, START WITH PART 1!!!!
2. Preparing your SuperR installation for your Custom AOSP Rom
In the Project Name we enter something identifying. Keep in mind that you may want to add multiple roms on this installation, so you should make it something rather unique. This process corresponds somewhat to Step 2.1, so you can read this one already to find out a good notation for your new project. I have already chosen my Treble image and will call mine
Code:
Enter new project name ...
lenny5_aosp8.1_vanilla_su_v32
2.1 Find out which Treble image you need
As you see in the last step, i selected a Version 8.1 "Oreo" image, where Vanilla tells you that theres no gapps at all and the suffix su means that it contains a rooted system. But later more about this. Also i chose v32 from the treble_experimentations releases.
To find your treble image, you need to have some information. First of all, read the information on this link. (phhusson's github wiki for Wiko Lenny 5)
Some informations here are important. First of all the flashing sequence, which will get important to us in a later step
Code:
Enable adb and oem unlock in developer options
adb reboot bootloader
fastboot flashing unlock
fastboot oem unlock
fastboot flash system your_gsi_path
fastboot reboot
as well as his testing notice
Code:
Flashed using Phh-Treble v18 - arm
as you can read in the Before starting section, there is a bug i could not resolve concerning installing older version ROMS, which could spontaneously start to apply to your device. i cannot "downgrade" my device, because it bootloops.
to select your image of choice, go to this site. (phhusson's treble image release site). to find v18, you will need to scroll down and go a few pages back in history.
some things to consider:
- lenny5 doesn't seem to be able to run AOSP9, so i'd recommend you stick with AOSP8.1
- there are lineageos compilations which might be interesting for some people. (i cannot tell if the root process for lineageos massively differs, as i don't use that one)
we will stick with AOSP8.1 in this guide.
first of all, you must decide if you want to stick with the go apps, install the stock gapps or go vanilla (no gapps at all). i will stick with vanilla. (note that some versions do not have the go version, others do)
then you will want to ask yourself if you want to root your phone, which we assume here to be yes.
as vanilla, like in our case, is not available with preinstalled su, we will stick with the nosu version. (which is a bit of a "hoax", as in fact this version already is rooted, you just have no way of controlling it, yet. we will take care of that in a later step.)
for our wiko lenny 5 we must choose the arm-aonly architecture. also i choose to stick with v32, the newest version per guide release date.
in my decision case, this leaves us with the following ROM:
https://github.com/phhusson/treble_experimentations/releases/tag/v32
Code:
system-arm-aonly-vanilla-nosu.img.xz
we will stick with that. if you want to use another rom, you must modify your choice. the overall process stays more or less the same. CONSIDER: It's proves easier to install some missing APK's etc. to your gapps-less system than removing unwanted gapps from your gapps-prebloated system.
click on the link and download the image file.
CONSIDER: Some of the images are in raw flashable format (the older ones), and have the extension *.img . For newer versions, the images are packed and CANNOT BE DIRECTLY FLASHED. these files are namely the ones with the extension *.img.xz
if your file has an extension that differs from *.img i strongly recommend you to use 7zip to extract the contained *.img file. 7-zip handles them all, which makes it the perfect standalone (de-)archiver on your computer. and no, i'm not getting paid by them for the advertising, it's just great and opensource.
now, if you didn't already, enter the name identifying your rom into the kitchen and confirm with ENTER.
to allow smb to write to your new project folder, reuse the command
Code:
sudo chown -R ~/android
by quitting superr (using the q key) or opening a second terminal (the easier way, in the original CTRL + ALT + T terminal on lubuntu, just doubleclick the top Tab-Bar off any other tabs and a new terminal tab will open) in which you execute this command.
now store the image file to your host workfolder and from there, copy it to your virtual workfolder's project folder (~/android/superr_<yourprojectname>/).
rename your system-arm-aonly-....img to just system.img for the kitchen to recognize it.
2.2 Extract your Treble image
To extract your Image file, on your virtual machines terminal, superr's kitchen should be running in the Main Menu.
if by any means you have stopped it, open a terminal with CTRL + ALT + T and enter
Code:
cd ~/android
./superr
press enter to execute and superr should launch. when asked for a project to load, choose the project you just created by pressing the correspondant cipher on the keyboard.
in the kitchen main menu, push cipher 4 on your keyboard to extract your obtained IMG-File. if asked, select your system.img by pressing the correspondant key and confirm the extraction with the "Y" key. wait for the process to finish. if asked, enter your virtual machine's user password. the kitchen sometimes needs to elevate some of it's processes during the extraction.
for the name of the zip, when asked, just enter "system_new". this is not so important, just dont simply call it "system", as this might confuse you under some circumstances and in the worst case overwrite your stock system.img.
for the perm type, select set_metadata by typing the "1" key on your keyboard, and you should be back in the main menu.
now your system image is unpacked into your virtual machine workfolder (~/android/<yourprojectfoldername>/system/)
2.3 Editing the contents (Rooting, etc.) of the Treble image
The editing in this guide's usecase is quite simple. We will want the following features and packages preinstalled:
- Root, of course
- including Root Management App
- BusyBox
- FDroid
- ...
you can add to this list to your hearts delight. The above will be my initial setup.
First we need to get the Root files.
These are found here
from this thread, get phh's-superuser.zip (the topmost file)
aswell as the phh's SuperUser apk file (top-second)
if you are having issues with the superuser implementation, try the bottommost element called phh's-superuser-aonly.zip instead of phh's-superuser.zip. this should normaly not be required.
copy both, the .zip and the .apk to your host workfolder.
now unpack the .zip to your host workfolder, which should create a folder "system" with 3 subfolders "bin,etc,xbin" in it.
copy this "system" folder to your virtual workfolder and into your project, so it integrates with the existing "system" folder on the virtual machine. if it asks you to overwrite, just allow it.
your virtual workfolder's project folder should now contain the following 3 files:
Code:
system/bin/phh-su
system/etc/init/su.rc
system/xbin/su
amongst the other system files.
Now download FDroid from here (the F-Droid site was temporarily down at the time of writing this guide)
Download the FDroid APK and store it in your host machine's workfolder.
After that, download the BusyBox APK from here
https://www.appsapk.com/busybox-app/
or a source you thrust more. There is a official busybox source, but i did not check which binary i must use for the Lenny 5, so i stick with the simplest method.
Download the BusyBox APK and store it in your host machine's workfolder.
Now copy the FDroid, BusyBox, and previously downloaded phh_s_SuperUser APK's from the host's workfolder to your virtual machine's project folder ~/android/<yourprojectfolder>/system/app/ (or \\<<yourvirtualmachineip\androshare\<yourprojectfolder>\system\app, respectively) to include them in your new ROM.
Thats basically all of the magic done. Your ~/android/<yourprojectfolder> should now contain the following 6 Elements
Code:
system/bin/phh-su
system/etc/init/su.rc
system/xbin/su
app/FDroid.apk
app/BusyBox.apk
app/phh_s_SuperUser_vX.X.X.X.apk
amongst the other elements from the Treble ROM.
move the APK app/FDroid.apk to a new Folder like this: app/FDroid/FDroid.apk
move the APK app/BusyBox.apk to a new Folder like this: app/BusyBox/BusyBox.apk
move the APK app/phh_s_SuperUser_vX.X.X.X.apk to a new Folder like this: app/phh/phh_s_SuperUser_vX.X.X.X.apk
as everything is sorted into folders, right?!
now we're done with modifying our treble image. lets repack it.
2.4 Repacking the Treble image
on your virtual machine terminal, with the kitchen open, go to the main menu if required and select "ROM Tools Menu" with the "8" key. You can check the "Root Menu" by pressing the "3" Key.
The Root/Unroot ROM should read (CURRENT: xbin/su) with Busybox and su.d "Disabled", which is okay, as BusyBox is not recognized, but there. If you want to utilize su.d, you must know yourself, how to do that properly. i don't know if it works as it should when done in the kitchen.
go back to the "ROM Tools Menu" with the "4" key and go to the "Build Menu" with the "7" key. Choose the option to "Build EXT4 img" by the key "2" and after the quick process finishes, in the menu "Which EXT4 img would you like to build?" select "system" by pressing the corresponding key, then select "sparse" by pressing the "2" key. for the file size, select the option to "Assume file size from project folder" by pressing the correspondent key and confirm the warning about this being BETA. Then wait for the process to finish.
The kitchen should say "system_new.img has been created in <yourprojectname>".
Now copy the newly created system_new.img from your virtual machine project directory to your host machine workfolder and we're done with editing and repacking the Image.
STEP 3 AND ON IN THIRD POST (CHARACTER LIMIT)
About TWRP and other stuff...
PART 3 OF THE GUIDE, START WITH PART 1!!!
3. Flashing the new Image to the Device
AT THIS POINT YOU SHOULD HAVE ALL YOUR DATA BACKUPED AND MAKE REALLY SURE FOR A LAST TIME, THAT YOU ACCEPT TO VOID YOUR WARRANTY AND TAKE ABSOLUTELY EVERY RISK TO YOURSELF FOR ANY CONSEQUENCES THAT COULD ARISE OF WHAT HAPPENS WITH YOUR DEVICE AT ANY TIME AFTER FOLLOWING THIS GUIDE.
The flashing process is simple. Enable Debug mode in your Phones Settings (Enable Developer Mode by taping the Build-Number several times Google: "Android Enable Developer Mode" - i really hope you know that after coming so far through this guide!!!.
When Developer Mode is activated, Go to Settings->Development Menu and activate the USB Debug Slider.
You must unlock the bootloader, at this point you must have generic adb or wiko specific adb installed, you can download it from here or get more information in section 0. "Before starting". The installation process is straightforward, possibly a restart of your host machine is required to get it running.
After installing ADB, you open the command line of your host machine and switch to your host machine workfolder by entering
Code:
cd <yourworkfolderpath>
and executing with ENTER.
use
Code:
dir
to make sure, that you are indeed in your workfolder.
when your phone is in usb debug mode, you can then reboot it into bootloader by entering
Code:
adb reboot bootloader
into your host machine command line. NOW THE DANGEROUS PART BEGINS, SO BE AWARE!!! WHEN UNLOCKING THE BOOTLOADER, YOUR LENNY5 WILL COMPLETELY WIPE ALL OF YOUR DATA AND RESET TO FACTORY SETUP!!!
by using the following commands in your command line you will unlock your bootloader, wipe your data and cache partitions including ALL PERSONAL DATA and flash your newly created ROM to the device.
Code:
fastboot flashing unlock
fastboot oem unlock
unlocks the boot loader. reenabling the debug mode (because of the factory reset) and/or rebooting the device may be required to reconnect to adb.
after that and making sure that you want to take the risk of flashing your new image, enter
Code:
fastboot flash system <yourhostworkfolderpath>\system_new.img
fastboot -w
fastboot reboot
the first command flashes your new image file, the second wipes your data and cache additionally, to make sure theres no residues there, which could mess with the first startup. after that we reboot the phone with the third command. after some loading, and a warning about the bootloader beeing unlocked, you should be greeted by AOSP's standard launcher with superuser, fdroid and busybox preinstalled.
4. Final words
After all it prove to be a quite long process, if you don't have any kitchen presetup. If the kitchen is ready, it's a thing of downloading, modifying and reflashing the device. but be careful. there's always a risk of bricking your device.
I will try to keep this guide up and running but memorize my Thread starting words.
If you think my RED BLOCKS are excessive - i'm sorry, but i care for your LENNY, too.
If you read this and are able to comply with all the steps in the guide, you are ready to flash your phone!
It's a wall of text, and i don't know if it's straight forward for all users, but it's the only way i could come up with, to root the LENNY5 phone, so it's worth it all the while, right?
I hope it helps some of you to get their Phones Unlocked and Unleashed.
Best regards
ivelischt
---------- Post added at 09:39 PM ---------- Previous post was at 09:37 PM ----------
if you find errors and mistakes in the guide, you are welcome to notice me and all the others by leaving a post in this thread.
Please ignore my posting titles, as they do not fit anymore, since i had to split from 2 to 3 posts to fit all of the text.
Okay some more words from my side concerning TWRP etc.
1. as far as i can tell, with the wikogeeks source you can indeed compile TWRP, but i'm not deep enough into it to try it.
2. with the procedure in the description above i now have a fully rooted phone
3. i am able to dump (mostly) any partition on my device (boot, recovery, system). so i have boot.img, recovery.img tested working. of course i was unable to dump my old system as it was not rooted. but i can dump my new system.img and it is also tested working, i reflashed all of the images to find it out.
4. if someone here in the forums thinks, that, with this information, you are able to port TWRP, i think we all would be glad,
because
5. i tampered around with various twrp roms. with the Jerry 3 ROM, which is out in the Net (DuckDuckGo-Search: w_k300 twrp), i thought i'd come to a point, as these are "sister-devices". in fact i had twrp running after loading the split-files (zKernel, etc...) from stock recovery to twrp recovery using the kitchen. but the screen isn't working. i need to "swipe for modifications", but i can't. as far as i can tell, it's just the touchscreen irresponsive. maybe this is something quickly fixed, maybe not.
so, i don't know if it's legal for me to share these sources here in the board but if anyone wants to test around on these write a on pm. just ask me and i will do what i can.
on my system, at the moment i have:
- stock boot.img
- stock recovery.img
- aosp8.1 system.img i use on my lenny
- semi-functional Jerry3-TWRP-Port, with the display unfunctional
let me know if you can do something with this stuff.
best regards
Matt 123456789 said:
Ok so Wiko Released the Firmware! Its a Windows software that downloads and flashes the ROM, and it makes a folder with stuff in it. Maybe experienced people can look into it and build TWRP?!! I would really love twrp but I don't have the experience :crying: . Hope developers see this
Click to expand...
Click to collapse
Hey Matt! Sorry, i completely misunderstood what you were talking about. Thats my fault
To clarify, there IS an actual Update package, just not under the various xx.wikomobile.com subdomains, but via world.wikomobile.com, using the IMEI number, you can infact get an Update.zip. I saw that really just now... The most recent update hides at https://support.wikomobile.com/maj/Lenny5_OPE_V34.zip
I don't know if this helps porting TWRP, as i'm actually experimenting with compiling it from source, for lenny 5 specifically. but to no success until this point. but whilst experimenting around, you can at the very least use it to flash to stock if required.
The update.zip contains the following:
- SPFlashTool
- MT6580 Scatterer-File
- boot-sign.img
- cache-sign.img
- lk-sign.img
- misc2-sign.img
- odmdtbo-sign.img
- recovery-sign.img
- secro-sign.img
- system.img
- tee-sign.img
- userdata-sign.img
- vendor-sign.img
- preloader_k400.bin
- as well as tons of other files
i think the stock system image is raw. to flash it you must either use the SPFlashTool or convert it to sparse format by other means...
best regards
edit: it seems, that lenny5 runs well with AOSP9, at least i upgraded my device today and it runs.
also, if you decide to install treble images by the guide above, using gapps, you will have to register your device here. (Android Device Registration)
their guide on getting the android_id may be a bit strange, i needed to progress as follows:
Code:
adb root
adb shell
inside shell type:
Code:
su <-- work as root
cd /data/data/com.google.android.gsf/databases/
sqlite3 gservices.db
this will start sqlite3 command line.
inside the sqlite3 command line enter
Code:
select * from main where name = "android_id"; <-- don't forget the semicolon!
after pressing enter, the output should be something like
Code:
android_id|[B]1234567890123456789[/B] <-- this code will be different on your device.
on the Android Device Registration page, you enter the bold part of the output and press Register. enter
Code:
.exit <-- to leave sqlite
exit <-- to leave su mode
exit <-- to leave shell
it will take a few minutes until your google services start to work properly without flooding your notifications.
you should now be able to use your gapps.
ivelischt said:
Please ignore my posting titles, as they do not fit anymore, since i had to split from 2 to 3 posts to fit all of the text.
Okay some more words from my side concerning TWRP etc.
1. as far as i can tell, with the wikogeeks source you can indeed compile TWRP, but i'm not deep enough into it to try it.
2. with the procedure in the description above i now have a fully rooted phone
3. i am able to dump (mostly) any partition on my device (boot, recovery, system). so i have boot.img, recovery.img tested working. of course i was unable to dump my old system as it was not rooted. but i can dump my new system.img and it is also tested working, i reflashed all of the images to find it out.
4. if someone here in the forums thinks, that, with this information, you are able to port TWRP, i think we all would be glad,
because
5. i tampered around with various twrp roms. with the Jerry 3 ROM, which is out in the Net (DuckDuckGo-Search: w_k300 twrp), i thought i'd come to a point, as these are "sister-devices". in fact i had twrp running after loading the split-files (zKernel, etc...) from stock recovery to twrp recovery using the kitchen. but the screen isn't working. i need to "swipe for modifications", but i can't. as far as i can tell, it's just the touchscreen irresponsive. maybe this is something quickly fixed, maybe not.
so, i don't know if it's legal for me to share these sources here in the board but if anyone wants to test around on these write a on pm. just ask me and i will do what i can.
on my system, at the moment i have:
- stock boot.img
- stock recovery.img
- aosp8.1 system.img i use on my lenny
- semi-functional Jerry3-TWRP-Port, with the display unfunctional
let me know if you can do something with this stuff.
best regards
Click to expand...
Click to collapse
Same with the display here, can't get it to work. I read that display touch malfunction is about kernel diferences, but I don't know how to modify it.
Hanthonious said:
Same with the display here, can't get it to work. I read that display touch malfunction is about kernel diferences, but I don't know how to modify it.
Click to expand...
Click to collapse
well, i then tried all the possible configurations of the following:
TWRP versions:
- self-compiled TWRP
- TWRP for some random FullHD-MTK6580 with more or less same specs as lenny 5
- K300 TWRP
kernel versions:
- twrp k300 kernel
- stock k400 kernel
- self-compiled k400 kernel
which makes quite some possible combinations. as far as i can recall, the most sucessful was the untouched k300 twrp with its k300 kernel, which managed to boot up but with the touchscreen not working.
i then tried the k300 twrp with stock and self-compiled k400 kernel, but both failed. i even tampered with the kernel adress to fit it to k400 and tried out multiple "tricks" i stumbled upon when searching the internet. but the phone always just hangs a few seconds, then boots into "normal" mode or stock recovery.
i cannot fully rule out whether its caused by me implementing the kernel in a wrong way (for me this is the most probable reason ) or if it's because SuperR's kitchen (thanks go out!) has some kind of mess while reintegrating the changed kernel, as i did all of these combine-and-retry kind of rom porting experiments with his product. maybe i am just using the tool in a wrong way.
i also compiled a stock kernel from wikogeek sources, then used that to compile twrp sources into a recovery.img, including the self-built kernel, which both, after some tinkering, built without any issue, but then also, this image just hangs for a few seconds and shows the same behavior as stated above.
whatever it is, i cannot identify it. this has two main reasons:
- first and most important: what i know is through learning-by-doing, which means, i have no degree in coding or anything. from my perspective, i feel a bit proud already, being able to compile aosp or lineage from source, even with a lot of help by those creating these mostly ready-for-use sources. :victory: learning-by-doing implicates my second point: time investment.
- i cannot afford to spend most of my time with digging into android development. and also often, i just don't have any delight in it and do other things.
also, my main purpose was to get a rooted system (with a custom rom on it), which i managed, so most of the time i spend on android stuff at the moment, is to update my build and distribute the updated images in time when security patches arrive.
short said: if twrp for k400 comes, it would be nice, but it's none of my main objectives at the moment to get this to work.
best regards

[AOSP]What is the most elegant way of striping AOSP of its pre-installed packages?

I am trying to gradually stripe AOSP out of its default apps. But I wonder if the method I am going to apply is correct and is the most effective.
After looking through ways of doing that I have come to the following method: (example app - "package_name")
1. Pick particular app and find out its "LOCAL_PACKAGE_NAME"
2. Use "envsetup.sh" provided command "mgrep package_name"
3. Look at the output to determine where package_name is mentioned
4. Remove lines of code containing package_name from makefiles
Click to expand...
Click to collapse
I have also stumbled upon this solution:
Instead of modifying bunch of .mk files in AOSP in many folders, you can add a new module, a stub, and disable modules in its Android.mk using LOCAL_OVERRIDES_PACKAGES. If a module still appear in target, you'll probably need to add to LOCAL_OVERRIDES_PACKAGES another modules which added undesired packages via LOCAL_REQUIRED_MODULES.
Click to expand...
Click to collapse
But sadly I am not aware yet how one builds a new "module, a stub" so I can't apply this method as of now.
Are there any steps I can take to make sure a particular app is removed from my build completely without harming anything. What do you think is the most elegant solution to this specific task if there is one? What(literature/docs/website)would be useful for me to get familiar with making "scratch-surface" changes to AOSP code like the abovementioned case?
Thanks in advance for your responses!
P.S If any extra information is needed I am ready to specify
If that matters what I am trying to remove at the moment: Calculator; Calendar; Camera; Clock; Contacts; Files; Gallery; Messaging; Music; Phone; Search; WebView

Categories

Resources