Hi all,
If you are going to say we don't need Apps2SD on the N1, please leave the thread now . (Actually, read on) There are various reasons I can think of why we need Apps2SD on the N1, and one of the biggest is actually Games. I don't really play any games to begin with, but the last I checked, some games are as large as 19MB, possibly more. Isn't it kind of crappy that the N1, the superphone, can't hold more than 10 such games?
I started this thread with the intention of gathering more information, and hopefully some coders will do it (including myself, if I've the time). Package Manager (the thing in charge of installing, if I'm not wrong), is in the AOSP, under frameworks/base. In such a case, wouldn't it be possible for some programmer to mod it such that it will ask you whether to install to (SD/Phone) before each installation process?
The other issue is, looking at current implementation of A2SD, it seems all apps on Phone are moved to the SD card partition. If we can have an implementation that allows both to co-exist, in addition to the Package Manager mod, I'd say we'll have a pretty nice implementation.
Your thoughts/findings? I may be completely off, have yet to actually look at the AOSP source.
Update:
@ChrisSoyars has an early implementation of this in his SnackPack - http://forum.xda-developers.com/showthread.php?t=638301
I would also like to thank everyone else for their valuable input and support ! Keep them coming. Lastly, sorry I'm not doing much code-wise (not at all), school work's too much .
Would be nice!
....I've got the same problem. Some application are very big and so i have got only 10MB free space anymore...
ADB is god
See my attachment file
And...there is already a post about app2SD and this is not in the correct section...
lazinase said:
See my attachment file
And...there is already a post about app2SD and this is not in the correct section...
Click to expand...
Click to collapse
that doesnt work on roms like the desire by modaco. app2sd doesnt work, ive tried that method and it just hangs. true there is a thread already for app2sd, but its not going anywhere in terms of the newest desire release. i know its still early, but i only had like 50mb for apps and i have over 120 apps and i didnt feel like reinstalling. someone fix it please.
Apps to SD is of course necessary. The Nexus doesn't really have that much space for apps - about 190mb which is only the same as the Hero.
I have apps 2 SD working with CM 5.0.3 from the kitchen.
its also addable to a CM rom using the how to thread.
It WAS working ok with MoDaCo ROMS but for some reason has ceased to work and causes bootloops if you bake it in - shame...
I've no coding experience, but willing to test stuff out anytime.....
Dayz xx
i think what Wysie is trying to do is stimulate discussion about a different way to do A2SD.
He, and a lot of people believe (including myself) that running apps from the sd makes them slower, so what he wants is like WM where when you install an app it gives you an option to install it either onthe device or on the sd. So you can choose to install your most used and apps that require speed the most on your device...
And if this isnt thread development where the hell should he have posted it? It certainly is development if you ask me. he is thinking of ways to develop a better A2SD.
Seems like unionfs + some kind of app to manage which apps live where might work. This would require kernel support, however. You would set up /data/app and /data/app-private as union mounts of (say) /data/app-internal with /sdcard/app and /data/app-private-internal with /sdcard/app-private. You would then want a custom app management tool to move things to the appropriate places.
Nice initative Wysie.
My suggestions are as follows:
Use a different mount point, not inside any of the other file systems.
Like /apps2sd, this makes it alot easier to handle in the recovery realm (which is what I care about).
As for handling the specific apps installed in either /data/app or /apps2sd I suggest we have a look at something simple. Like symlinking individual apps.
Ext filesystem is mounted on /apps2sd on boot.
New installs of apps are done in /data/app like normally. /data/app is not symlinked to the apps2sd directory like it is today.
If a user want a app to be stored on apps2sd instead of in /data/app a management app can just move the .apk from /data/app to /apps2sd and set up a symlink it up into /data/app again.
Simple demonstration:
Initial state, two apps installed normally:
/data/app:
SomeApp.apk
SomeOtherApp.apk
/apps2sd
<empty>
Now the user moves SomeApp to apps2sd:
/data/app
SomeApp.apk -> /apps2sd/SomeApp.apk (symlink)
SomeOtherApp.apk
/apps2sd
SomeApp.apk
If this is possible, i.e. making sure that Android doesn't bork on symlinked apps (can't see why it would, but best to make sure). This is clean simple way handle it. It gives more control on what apps are stored where, better handling of ext stuff in recovery.
Also writing scripts/apps to facilitate this is trivial since it's so simple.
What do you think? Want input especially from ROM makers.
packetlss said:
As for handling the specific apps installed in either /data/app or /apps2sd I suggest we have a look at something simple. Like symlinking individual apps.
Click to expand...
Click to collapse
Okay, that's better than my idea, assuming it works. One disadvantage is that removing the SD card breaks all the links. You could conceivably swap cards with the unionfs approach, as long as you were not using any widgets or launcher icons which rely on APKs in the SD storage, and had a way to properly unmount the disk. Might not be worth the complexity, though.
I think the biggest issue is with regards to removal of SD card. You guys have made it way more complex than I thought, thanks for enlightening/sharing !
I thought it could be as simple as simply modifying the Apps2SD script to allow apps to exist on both the sdcard and the phone, and then modifying the Package Manager to prompt the user on where to install to. Keep those thoughts/opinions coming!
If it wasn't for my school work and lousy time management i'd definitely start doing something. For now, it's good enough if all the necessary knowledge is shared here, then some dev can actually start work and put it on github or something for the rest of the community to contribute!
i haven't looked deeply into android's files. but i've worked on hacking motorola phones to engineer a packet manager system. (EZX phones)
i believe the solution that we want isn't with the use of symlink or that sort. we should aim to find a clean, programmatic way of doing it - built to the heart of android.
any idea how android am manage the apps on the phone? is there an sqlite app db or something? how does it store the installed applications information?
arctu said:
i haven't looked deeply into android's files. but i've worked on hacking motorola phones to engineer a packet manager system. (EZX phones)
i believe the solution that we want isn't with the use of symlink or that sort. we should aim to find a clean, programmatic way of doing it - built to the heart of android.
any idea how android am manage the apps on the phone? is there an sqlite app db or something? how does it store the installed applications information?
Click to expand...
Click to collapse
Well, you have to remember that the solution should work on stuff that we do not have source access to, like people wanting to use on ported ROMs or a rooted stock ROM.
I tried to simlink apk's but for some reason it didn't work, simlink the app directory works.
I think the best way would be to add paths in the program that actually searches/launches the apps (my guess would be that's in framework.jar)
Currently it looks in /system/app, /data/app & /data/app-private there should not be any technical reason why it couldn't look in a forth directory. this way you can keep the imporant/most used apps in the flash and large/less used on the sdcard...
rj3005 said:
I think the best way would be to add paths in the program that actually searches/launches the apps (my guess would be that's in framework.jar)
Currently it looks in /system/app, /data/app & /data/app-private there should not be any technical reason why it couldn't look in a forth directory. this way you can keep the imporant/most used apps in the flash and large/less used on the sdcard...
Click to expand...
Click to collapse
packetlss said:
Well, you have to remember that the solution should work on stuff that we do not have source access to, like people wanting to use on ported ROMs or a rooted stock ROM.
Click to expand...
Click to collapse
Again, this is the problem. A general technique suitable for XDA-type applications must require only root or changes to GPL code. You can't touch the framework, which can (and does) have proprietary branches.
packetlss said:
Well, you have to remember that the solution should work on stuff that we do not have source access to, like people wanting to use on ported ROMs or a rooted stock ROM.
Click to expand...
Click to collapse
i would say that we have no choice but to implement it without considering those groups. however, i do suggest that we should make the implementation compatible, just that, on modded frameworks like cyan, it works to the fullest.
olearyp said:
unionfs
Click to expand...
Click to collapse
Everything old is new again. Oh well.
olearyp said:
Everything old is new again. Oh well.
Click to expand...
Click to collapse
Unionfs is not available for android devices without kernel sources.
Concerning ported rom, I am not sure the package installer get modified by vendors. So it may be possible to implement the changes done to aosp code using baksmali.
So my two cents are:
- modify AOSP sources to have android lookup at /sd/app for apps
- modify package installer to have it asks where to install apps
Sure the removing of sdcard problem is still there. I don't know how we can ever handle a straight manual remove of it. It implies big modifications to AOSP sources to have the system aware of missing applications that have existing home shortcuts or widgets, so it "hides" them until app is back...
Anyway we can start implementing the functionality and look after for that sdcard removal problem.
I've been thinking of doing this for a while, has any progress been made?
I like the idea of modifying pm to prompt for the install location, I was thinking of just writing an app to manage that (but probably would be a good idea to have both).
If progress has been made, great, if not, I may start a fork of CM5's vendor tree for this.
Lox_Dev said:
Unionfs is not available for android devices without kernel sources.
Click to expand...
Click to collapse
Kernel sources are the one thing you most assuredly do have on all devices, at least if they're sold where copyright law can be enforced. No one needs to risk a lawsuit by intentionally violating GPL.
olearyp said:
Kernel sources are the one thing you most assuredly do have on all devices, at least if they're sold where copyright law can be enforced. No one needs to risk a lawsuit by intentionally violating GPL.
Click to expand...
Click to collapse
Well.. it is not the case in real life.... For eg, acer Liquid kernel sources they acer provided is unusable.
Just a clue for aosp source modification:
services/java/com/android/server/PackageManagerService.java:frameworks/base/ Log.d(TAG, "Scanning app dir " + dir
Related
I have read a few posts in this section, but it is totally impossible for someone like me (new to smartphones, flashing and the rest) to understand anything. Would you please explain some of the terminologies used here? Some of them are: kernel, 3g, port, system.ext2, BT... and thousands more.
Thank you very much!
you don't really "need" to understand any of that.
all you need to do is to learn how to download files, learn how to extract the downloaded file, learn how to copy them to an sd card, and learn how to run a program inside windows mobile.
if you can do all that, you should be set!!!
just follow steps 1-6 (ignore step 1b - the part about system.ext2) - http://forum.xda-developers.com/showthread.php?t=951962
Well noted AkumaX. Thank you very much!
XDAndroid is a project to port Android onto older HTC phones.
There are two main parts of XDAndroid, which combine to form a complete port:
Kernel/drivers: You can find packages to run Android on old HTC phones from a variety of sources, but whatever package you use, all rely upon the kernels/drivers created by the XDAndroid team to enable the basic hardware.
Android system: The Android system forms all of the parts of the phone's interface that you can directly interact with. Once the kernel/drivers have setup the hardware, you can add on an Android system port of your choice to form a complete build. Many system ports are available, both in terms of different versions (2.1 Eclair, 2.2 Froyo, 2.3 Gingerbread, etc.) and different starting points in the case of ports written by those outside of XDAndroid.
XDAndroid releases an "official" system port you can use, which is directly ported over by the XDAndroid team from the Android Open Source Project, and is very close to stock. Many of the alternative builds you come across are modifications of the XDAndroid system, containing customizations that deviate farther from stock Android, while others have different starting points altogether, and are ports of the ROMs found on official shipping devices that have already been customized (but still use the same basic kernel/drivers found here).
Android is a framework that runs on top of Linux. In order to get Android running on our devices, first we must get Linux running on the hardware with all drivers implemented, and then, we hook Android into these drivers. Thus, broadly viewed, the XDAndroid project is divided into two parts: the kernel/drivers and the Android port.
When you look at the files in your Android directory, you'll probably see something like the following:
zImage: The Linux kernel and drivers.
modules-###: Additional drivers for the kernel. Your system will load without this, but things like wifi may not work, or you may encounter instability.
initrd.gz: Used in the Linux boot process.
system.ext2: Most of the Android framework.
rootfs.img: Additional parts of the Android framework that are customized for our devices.
data.img: This file contains what would be your internal memory on a real Android device. Whenever you install a program it goes in to here. A new empty one will be automatically created if you don't have one.
haret.exe: Reboots you from Windows into XDAndroid.
startup.txt: Commands passed to XDAndroid on bootup that are customized by the user.
ts-calibration: Contains calibration information for the touch screen. If you don't have this file, you will be prompted to calibrate your screen on startup.
AndroidApps: A folder where if you copy any apks into it, they will be automatically installed on bootup.
manekineko said:
XDAndroid is a project to port Android onto older HTC phones.
-------.
Click to expand...
Click to collapse
Good explanation manekineko!...I believe this is what op was looking for.
there is light at the end of the tunnel, it wont take much longer if the devs keep up this good work, until there can be made stable and good builds with good battery life etc. when the time is there i will create an complete noob friendly installation guide (with pics and maybe even an vid).
I'm currently trying to figure out which one to install!
manekineko said:
XDAndroid is a project to port Android onto older HTC phones.
There are two main parts of XDAndroid, which combine to form a complete port:
Kernel/drivers: You can find packages to run Android on old HTC phones from a variety of sources, but whatever package you use, all rely upon the kernels/drivers created by the XDAndroid team to enable the basic hardware.
Android system: The Android system forms all of the parts of the phone's interface that you can directly interact with. Once the kernel/drivers have setup the hardware, you can add on an Android system port of your choice to form a complete build. Many system ports are available, both in terms of different versions (2.1 Eclair, 2.2 Froyo, 2.3 Gingerbread, etc.) and different starting points in the case of ports written by those outside of XDAndroid.
XDAndroid releases an "official" system port you can use, which is directly ported over by the XDAndroid team from the Android Open Source Project, and is very close to stock. Many of the alternative builds you come across are modifications of the XDAndroid system, containing customizations that deviate farther from stock Android, while others have different starting points altogether, and are ports of the ROMs found on official shipping devices that have already been customized (but still use the same basic kernel/drivers found here).
Android is a framework that runs on top of Linux. In order to get Android running on our devices, first we must get Linux running on the hardware with all drivers implemented, and then, we hook Android into these drivers. Thus, broadly viewed, the XDAndroid project is divided into two parts: the kernel/drivers and the Android port.
When you look at the files in your Android directory, you'll probably see something like the following:
zImage: The Linux kernel and drivers.
modules-###: Additional drivers for the kernel. Your system will load without this, but things like wifi may not work, or you may encounter instability.
initrd.gz: Used in the Linux boot process.
system.ext2: Most of the Android framework.
rootfs.img: Additional parts of the Android framework that are customized for our devices.
data.img: This file contains what would be your internal memory on a real Android device. Whenever you install a program it goes in to here. A new empty one will be automatically created if you don't have one.
haret.exe: Reboots you from Windows into XDAndroid.
startup.txt: Commands passed to XDAndroid on bootup that are customized by the user.
ts-calibration: Contains calibration information for the touch screen. If you don't have this file, you will be prompted to calibrate your screen on startup.
AndroidApps: A folder where if you copy any apks into it, they will be automatically installed on bootup.
Click to expand...
Click to collapse
Thank you so much for your explanations, manekineko. I believe that I am now ready to cruise through all the threads of this section without fear.
shatred said:
there is light at the end of the tunnel, it wont take much longer if the devs keep up this good work, until there can be made stable and good builds with good battery life etc. when the time is there i will create an complete noob friendly installation guide (with pics and maybe even an vid).
Click to expand...
Click to collapse
shatred, I am eagerly waiting for two things: (i) for the developers to release the perfect Android builds (my sincere encouragements to them by the way!!!) and (ii) for your installation guide.
gueyenono said:
I'm currently trying to figure out which one to install!
Click to expand...
Click to collapse
tell me your phone type, so an rhod-100? 200? 300? etc.
and tell me what you prefer more, an good battery life and an stable running system without camera support OR less stable system, bad battery life but with camera support.
Tell me and i will help you
shatred said:
tell me your phone type, so an rhod-100? 200? 300? etc.
and tell me what you prefer more, an good battery life and an stable running system without camera support OR less stable system, bad battery life but with camera support.
Tell me and i will help you
Click to expand...
Click to collapse
Uhm... You no longer have to choose. WisTilt2 pulled the latest commits from GIT into his test kernel.
arrrghhh said:
Uhm... You no longer have to choose. WisTilt2 pulled the latest commits from GIT into his test kernel.
Click to expand...
Click to collapse
yeah but if you activate the camera libs the phone wont go into deep sleep mode right? or is that fixed already?
shatred said:
yeah but if you activate the camera libs the phone wont go into deep sleep mode right? or is that fixed already?
Click to expand...
Click to collapse
Seems I was wrong about that. It was the other way around, if the libs are disabled the phone won't sleep.
However, with FRX05 there's no need for the libs. FRX05 + GIT kernel or WisTilt2's newest kernel is all you need for cam.
arrrghhh said:
Seems I was wrong about that. It was the other way around, if the libs are disabled the phone won't sleep.
However, with FRX05 there's no need for the libs. FRX05 + GIT kernel or WisTilt2's newest kernel is all you need for cam.
Click to expand...
Click to collapse
hmm yeah about that, i tried frx05 with wistilt2 latest kernels but it doesnt work for me, i think its an problem with my user conf... can you perhaps send me your user conf from frx05?
shatred said:
hmm yeah about that, i tried frx05 with wistilt2 latest kernels but it doesnt work for me, i think its an problem with my user conf... can you perhaps send me your user conf from frx05?
Click to expand...
Click to collapse
Same for FRX04... It's in my bundle.
If you remove all of the ln -s and bind mounts, should work just fine...
Very Important Information For Beginners
/Introduction to Android for SD Cards
Okay, firstly I made this thread because pretty much every new person to this section of the forums is completely lost and unsure what things are or what to even do. We are also sick and tired of threads saying 'how do I get stared' or 'which is the most stable' etc.
----------------------
Download your files from here:
You will be accessing these websites quite often so it might pay to bookmark them
Kernel downloads, almost always download the top one, they are updated often (needs extracting): http://glemsom.users.anapnea.net/android2/htc-msm-linux/
Rootfs downloads, download the top one, they aren't updated as often as the kernels above but still quite regularly (also needs extracting): http://files.xdandroid.com/rootfs/
Initrd downloads, rarely updated (don't extract, just rename to initrd.gz) http://files.xdandroid.com/initramfs/ People almost never need to download one of these separately.
----------------------------------
Basic need-to-knows:
Kernel: Your modules/zImage. Your zImage always needs be in the root (first folder) of your android folder on your SD and ALWAYS named zImage, your modules should also be in the root of your android folder named modules-LOTSofNUMBERSandLETTERS.tar.gz never rename your modules. It should always be in .tar.gz EG: modules-2.6.27.46-01276-g6a6a1c1-dirty.tar.gz
Rootfs: Must be in the root of your android folder named rootfs.img
Initrd: Needs to be in the root of your android folder named initrd.gz
Data.img: Generated on the first boot of android and placed in root of android folder. Is a virtual memory file that acts as the phones internal memory for android. Holds all your settings etc. May have to be recreated some times (just by deleting it)
Haret.exe: the file executed by your Windows ROM to kick Windows out of memory and boot android.
system.ext2: Main android file, must be in the root of your android folder. Holds all of your build.
startup.txt: File that instructs android how to start up. Needs to be in the root of your SD. (I will cover this further down)
ts-calibration: A file in the android folder that holds calibration information of the touch screen.
Various Folders: You will see/have/need other various folders created in the root of your SD and in the root of the android folder, such as conf, cache, data, media etc. You usually don't want to delete these.
Root: The root folder of any partition is the "highest" folder in the hierarchy. The root folder contains all other folders and can also contain files. For example, the root folder of the main partition on your computer is probably C:\. The root folder of your DVD or CD drive might be D:\.
Also Known As: "the root"
RIL: Radio interface layer: basically controls your radio (GSM/CDMA network)
------------------------------------------------
startup.txt
VERY IMPORTANT, your startup.txt must be customized to your device. (mine is a rhod110). You can find your model number under your battery. This file belongs in the folder with your android.
My startup.txt looks like this
Code:
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set cmdline "lcd.density=240 msmvkeyb_toggle=off gsensor_axis=2,1,3 pm.sleep_mode=1 rel_path=FRX07 physkeyboard=rhod100_uk acpuclock.oc_freq_khz=710000"
boot
Now I believe you should be able to copy and use this as yours with a few slight modifications. Change rel_path= to wherever your android is stored on your sd, for example when I go to my sd inside the folder frx07 (the root of my android folder) all my android files are there. If your folder was called andboot it would be rel_path=andboot. (without that full stop) Now change your physkeyboard= to your model of your phone, mine is rhod110 but the rhod100_uk keymap is EXACTLY THE SAME AS THE RHOD110 so that's why I use rhod100_uk instead of rhod110 (rhod110 isn't recognised by frx07), this is important to make sure your keys are assigned properly.
------------------------------------------------
Models of rhod:
From what I know that exists. If you find one not listed, make sure you tell me so I can update the list
rhod110 uses rhod100_uk and it works as it should
These can be used for physkeyboard= in startup.txt (needs updating, some may no longet be supported because F22 hasn't commited old changes)
rhod100_de
rhod100_es
rhod100_fr
rhod100_it
rhod100_nl
rhod100_nordic
rhod100_uk
rhod210
rhod300 (tilt2)
rhod400
rhod500
Getting set up:
Go to http://forum.xda-developers.com/showthread.php?t=1171052 and download the FULL BUNDLE
Other builds exist such as gingerbread but this guide only covers froyo frx07.
Replace/add the Kernel from the downloaded build with the latest one (remember this is the zImage and modules-NUMBERS.tar.gz). Updating is as simple as this, do it often - there is no data loss. See links mentioned above for links. Making sure that the (if there were) old kernel files are all deleted and the new ones are called zImage and modules-NEWdifferentNUMBERS.tar.gz
Replace/add the rootfs.img with the latest one from the link above it should be named rootfs.img.
Remember that the rootfs and kernel are updated quite often and that you should check and update every few days.
Make sure your startup.txt is correct and make sure everything is where it should be in a folder on your computer, then copy the folder to the root of your sd card.
Navigate to this folder using the file explorer in your Windows ROM (YOUR PHONE) and run the Haret.exe
It will then have some writing running down a black screen before booting android (it's just preparation to booting) read it if you want
Android will start and you should leave it about 2-5 minutes before touching anything, it has things running in the background and it will be slow, still setting itself up. Navigate to settings and set up your phone. If anything goes too badly wrong you can always delete data.img and start again! Data.img is the internal memory of the phone, remember? Well, until we get android working on the real internal memory...
---------------------------
Structure:
My SD card. (with android on it)
I'm running:
kernel: 20110819_183957 http://glemsom.users.anapnea.net/android2/htc-msm-linux/
build: Froyo FRX07http://forum.xda-developers.com/showthread.php?t=1171052
rootfs: rootfs-20110816-7e04198.zip from http://files.xdandroid.com/rootfs/
Code:
EncFiltLog.menc
kbd_info
Android
cache
download
tmp
Private
Games
Installs
DCIM
Others
Videos
Images
Sounds
media
frx07
rhodimg.nbh
My android is in frx07
inside my frx07:
Code:
data.img
ts-calibration
startup.txt
modules-2.6.27.46-01348-g9de837f.tar.gz
zImage
haret.exe
initrd.gz
system.ext2
AndroidApps
conf
media
rootfs.img
-----------------------------------------
Backup/Restore
when you have the need to backup and restore data, look for an app called Titanium Backup. I have never used it but heard it works brilliantly, even backing up your apps! There is a 'donation' version and a free version with not many differences. I suggest you go check it out!
-----------------------------
USB CONNECTIVITY
When your phone is in Android you can not use it like a USB, HTC's drivers will not work and you have to use certain programs until this is implemented.
Windows: Install DroidExplorer this lets you open a terminal (like command prompt) on the phone, lets you browse device adding/deleting files, among other features that are very useful. If that DroidExplorer doesn't pick up your phone (when picked up it will be called 0000000000) install PDAnet on your phone and pc. PDAnet provides the drivers needed to connect the phone. It also lets you use your phone as a modem and you can send SMSs using your computer. Do NOT run PDANET at the same time as DroidExplorer. When PDANET is connected it WILL use your phone for data connections - this is the only warning. The phone is not used for any networking when DroidExplorer is connected.
Mac: Unknown to me (can someone post?)
Linux: Never tried, it is easier than windows (can someone post a method?)
---------------------
Overclocking
Do NOT overclock WINMO.
If you want to overclock your device do so at your own risk.
it is as simple as adding "acpuclock.oc_freq_khz=710000" without quotes to your startup.txt cmdline. 710000 (approx 710 mhz) can be swapped for any number but this is practically the highest stable speed achievable. I use 710000, works fine for me.
-------------------------
Known problems across ALL BUILDS:
Media Player Some tracks might have playing issues. FIX: HERE
Bluetooth is experiemental
Speakerphone static : seemingly random issue
USB plugging the device into a computer, it will be recognised, but not by HTC drivers. FIX: You must use something like DroidExplorer and PDAnet to browse the device and ADB (android debug bridge). See above ^^ (USB tethering is being fixed/has been fixed)
FN LED On keyboard the caps LED works but the FN LED currently does not. FN still works fine
No deep sleep: FIX: disable GPS (or kill the running app causing phone to not sleep)
Failure booting Android: Phone fails to enter android after running haret.exe FIX: Make sure your winmo is NOT overclocked before booting android.
Booting or SD Card related problems: Make sure your card is formatted as FAT32 (reformat as Full Format if it is not working)
More information is available on the wiki, there is also information there if you want to get into development. There is a pretty good FAQ on that wiki too
Remember XDAndroid is not just for this device.
If any of this is wrong or you think something should be updated/changed, please tell me
The CDMA startup should have "board-htcrhodium.is_cdma=1" instead of "...is_gsm=0"
otherwise, looks good!
AkumaX said:
The CDMA startup should have "board-htcrhodium.is_cdma=1" instead of "...is_gsm=0"
otherwise, looks good!
Click to expand...
Click to collapse
Indeed, there is no "is_gsm" command .
arrrghhh said:
Indeed, there is no "is_gsm" command .
Click to expand...
Click to collapse
Thanks to both of you, not bad considering I don't even have a cdma phone eh?
anything I need to add? I will tidy it all up soon
Something that might catch out a beginner is if they have an older SD card and it isn't detected by more recent kernels.
Need to include this in the cmdline:
msmsdcc_1bit msmsdcc_fmax=14000000
the.decoy said:
Something that might catch out a beginner is if they have an older SD card and it isn't detected by more recent kernels.
Need to include this in the cmdline:
msmsdcc_1bit msmsdcc_fmax=14000000
Click to expand...
Click to collapse
I thought this was squashed in recent kernels?
arrrghh said:
saneksem said:
add that to startup,helped me on 2 gb card
msmsdcc_1bit msmsdcc_fmax=14000000 msmsdcc_nopwrsave
Click to expand...
Click to collapse
You don't need this if you're on a newer kernel!!!!
Just update your kernel folks, no need for this in the startup!
Click to expand...
Click to collapse
Oh, ok. I must have missed that. I only needed it on my older SD which I haven't tried using for a month or so.
I guess the only thing I would suggest (all minor things) would be maybe to bold/underline keywords, like "kernel", "rootfs", etc.. to differentiate things that may change over time; ex: I'm running FRX05 system.ext2, 3/1/11 rootfs from F22, 3/1/11 zImage/modules (kernel) from arrgghh, etc... And, I guess you "could" be nice and show people what they could edit in the startup.txt, depending on their phone; ex: I'm Sprint, so I would do kb=rhod400, cdma=1, etc..., but for each phone.
I would probably have to do all the different startup.txt's in a different thread, unless I just provide a quick table... I will think about it however I do like the idea about bolding key words.
Most new people don't realize if they have their call/end/windows/back buttons on in winmo, they will stay on while on android and never go off. Might want to put that in your first post before telling them to run haret...
at the end where you say you can just delete the data.img and startover its probably a better idea to say to be patient and reboot the phone once or twice before ditching your data.img ! and creating it is the bulk of the first boot, the linux black screen with the scrolling words section.
you can talk about saving your data.img just incase something goes wrong.
titanium backup is a must
having an app that can save sms when you switch builds (not a big deal for everyone but important to some.)
also let new users know android isn't perfect, things randomly completely mess themselves all the time, don't get discouraged just start fresh with a format and new files when deleting the data.img doesn't work and you'll be just fine.
All I want to know now is if I have helped anyone yet and if they had any problems with any part of it or want me to clarify anything I will be quite happy with such replies ^-^
Is anyone able to provide me with some ETAs of fixes on the problems across all builds listed in the OP? Also are there any more I am not aware of? Oh and if anyone is working on them?
Much Appreciated
ryannathans said:
Is anyone able to provide me with some ETAs of fixes on the problems across all builds listed in the OP? Also are there any more I am not aware of? Oh and if anyone is working on them?
Much Appreciated
Click to expand...
Click to collapse
There's never an ETA for anything getting fixed - BT seems close, but who knows the exact date it will be done? As CyanogenMod says, the only rule is don't ask for release dates / ETA. It'll be ready when it's ready.
Some problems are being looked into more than others, but I wouldn't say one in particular has been left out to rot. jb is fixing up BT, entropy is working on GPS fixes, wistilt2 on the RIL of late... Basically devs pickup things that are of an interest to them to fix. There's a lot still to fix/cleanup, so taking it all on alone is a little daunting. Gotta break it down into smaller pieces so it's at least somewhat manageable.
Thanks and a question...
First, thanks for the awesome post - quite helpful...
Second: I haven't mussed with my phone for about a year, for various reasons, the main one being that I was happy with my previous phone and the ROM I finally settled on, the secondary one being that phone died, and I now have a (blech) Sprint TouchPro2 (RHOD400), and am on my sixth (yes, sixth!) brand new TP2 - they keep giving me a new one because of problems (things, like... oh... say, not being able to answer calls... kind of a basic function in a mobile phone, nah?!) And, I've had no interest in futzing with what is already a frustrating and non-functional phone. I was hoping I could upgrade instead of getting another TP2 the last time I brought it in for probs, but they would only downgrade me to worse phones. So... here I am, wanting to put Android on my phone and see if there is any improvement. Or, at the least, be able to utilize some of the decent progz/gamez for Android. I mean, if I can't answer calls, at least I can use it as a handheld gaming system, right?!
Long story short: when I was flashing ROMs to other phones, the instructions explicitly said that you needed to unlock, etc., first. I can't find any data re: if there are steps you must take on your phone to 'prep' it, *before* following the steps in this thread. I've browsed the DB and no luck.
My apologies for being an annoying n00b!
PS: one of my friends said "Tell 'em you're a hawt babe - then they'll help for sure!" (ROFL)
And, thanks, again!
Tynkrrbell said:
Long story short: when I was flashing ROMs to other phones, the instructions explicitly said that you needed to unlock, etc., first. I can't find any data re: if there are steps you must take on your phone to 'prep' it, *before* following the steps in this thread. I've browsed the DB and no luck.
My apologies for being an annoying n00b!
And, thanks, again!
Click to expand...
Click to collapse
Well the reason you can't find any info on it, is that it's not required .
These builds run entirely off of the SD (currently - I wouldn't try NAND yet, it's in its infancy) so there's no need to do any HardSPL or anything really to prep - just drop the bundle on your SD card - if it's at the root, run haret.exe and gogogo!
Oi. I get the stupidcard of the day!
That is awesome! Same friend that suggested I mention I am a 'hawt babe' said I should "give boobpr0n" to whomever helped me. You probably wouldn't want to see that, though!
You are heartily appreciated! I'm off to be an Androidite!!!!!!
Tynkrrbell said:
That is awesome! Same friend that suggested I mention I am a 'hawt babe' said I should "give boobpr0n" to whomever helped me. You probably wouldn't want to see that, though!
You are heartily appreciated! I'm off to be an Androidite!!!!!!
Click to expand...
Click to collapse
My gf suffices for that .
Hope you enjoy Android!
Tynkrrbell said:
That is awesome! Same friend that suggested I mention I am a 'hawt babe' said I should "give boobpr0n" to whomever helped me. You probably wouldn't want to see that, though!
You are heartily appreciated! I'm off to be an Androidite!!!!!!
Click to expand...
Click to collapse
Not to burst any bubbles here, but if you are saying you are a "hawt babe" and give boobpr0n mumbo jumba, you are prolly not one and won't give it anyways.. so nobody will most likely believe you here..
Good luck though~
I had an odd thought. A lot of us like to test out other ROMs, but NANDROID backups and restores result in significant downtime. I'm curious if it would be possible to nest a fully installed ROM inside a subdirectory of the current running one and then swap them out in Recovery by rewriting the pertinent directory paths.
Obviously, there would be a requirement that both ROMs be compatible with the file system in question (Ext4 , etc.)
I mention all this because I would like to be able to quickly boot into Cyanogen 7 every now and then for the bluetooth stack and some of the other features here and there, but my daily driver is Bionix.
Obviously, a nice chunk of space would be "wasted" having duplicate copies of lots of files for apps and such (in addition to the space used having a second ROM) but I think the Galaxy S series NAND space is sufficient to try something like this.
Holy crap that's an amazing idea!!!
Theres already a way to do this its called dual booting and uses your internal memory.
Complicated though.
Are there any guides?
Yes, their in the android section (lol)
http://forum.xda-developers.com/showthread.php?t=847423
work in progress.....close to alpha release
Aww I thought it could already be readily available .
Nice though can't wait .
edit nevermind
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!
Hello all. In the last 24 hours I've racked my head against a wall and I can't seem to get past this. So some pointers would be very welcome.
Backstory - Been doing backups of Titanium Backup onto my Nexus 9 (16GB internal storage) and I'm running into problems with running out of storage space. So I thought I'd look into doing a CIFS share mountpoint to my tablet and backup directly to the CIFS shares on my FreeNAS box. I figure a couple TB of storage is enough to store my Titanium Backups.
So first I read about CIFS Manager. Seems it may be discontinued or not functional on Lollipop.
Then I read about Busybox. Very cool, I think I'd marry Busybox if it was a woman. It seems so amazing I bought the Busybox Pro version.
So I tried to mount the CIFS/SMB share but I keep getting the dreaded "no device found" which means the cifs.ko isn't loaded. Apparently it's not in OS by default, so I need to compile it. (I'm not against someone giving me the .ko file, but I'd rather learn how to fish for myself than expect someone to give me a fish when I'm hungry) I have no clue how to compile it or even where to start to get a resemblance of the necessary steps. My experience is mostly Windows and FreeBSD, with only enough knowledge of linux to be very dangerous. I've tried searching all over for some kind of guide, pointers on what files I need to get, where to go to compile, etc but there seems to be nobody out there with any kind of good guide, even an outdated one I could use to fill in the blanks. I was hoping to put together a fairly detailed guide that includes steps on how to compile the cifs.ko yourself from source as well as mount your share on the device for whatever purposes you desire. But I'm finding that there is basically no info online on how to do this, where the source is, how to compile it, etc. If you know how to do this and are willing to help me write the guide (I've written quite a few articles on FreeNAS and ZFS) I'd be more than happy to give you some credit. I have no doubt lots of people will use the document once it is created.
Alternatively I considered doing the same with NFS but again I'd need to compile the nfs.ko module, so I'm stuck at the same point there.
Anyone have any pointers on how to do this? Or, anyone have any other options that will work just as well that allow me to not have to store the actual titanium backup files locally?
About the only thing I can find is someone saying that you need a Linux VM, the kernel sources, sdk, some knowledge in unix, and patience. But hell, I don't know if by saying "kernel sources" they are talking about the kernel source for the Linux VM or the Android OS I'm running (or both), if the SDK is referring to the Android SDK or not, etc.
Thanks in advance!
Joshy8 said:
Or, anyone have any other options that will work just as well that allow me to not have to store the actual titanium backup files locally?
Click to expand...
Click to collapse
I was in the same boat as you a few years back. Basically I would root, find a kernel that had the CIFS module, then use CIFS Manager to mount the shares. I would also use rsync & busybox. This stuff is tricky. The command to get Android to mount the shares, the CIFS module and kernel always has to be up to date, changes in busybox, etc.. I dreaded Android system updates. It starts to feel like a Rube Goldberg machine.
I started using an app called FolderSync (there's a paid version, too) and never looked back. It works quietly in the background and have never had any problem with it. It's one of the best apps on Android.
I do thank you for the advice, but that's how I've been doing backups for several years. I bought it back when the original Droid phone came out.
However in this case, since my tablet has only 16GB of internal memory and you can't easily have permanently attached external storage I'm forced to come up with an alternative of some kind.
I have had some problems lately with FolderSync. Not sure exactly what the problem is, but FolderSync seems to have issues from time to time and it gets stuck on random files and never finishes, even if left to complete for several days. I've had this issue randomly on 3 different devices, and one of my friends that also uses FolderSync has had the same issue on his. So I'm pretty sure there's a bug of some kind in FolderSync that sometimes breaks it.
Anyway, since my tablet has only 16GB of internal memory and you can't easily have permanently attached external storage I'm forced to come up with an alternative where the data is never actually stored on the device itself. :/
I know this isn't the answer you were looking for, but have you seen these:
http://www.meenova.com/st/p/mrg2.html
It's the closest thing I've found to convenient usable external storage.
Sent from my Nexus 9
The Fire-Ice kernel (http://forum.xda-developers.com/nexus-9/orig-development/kernel-fire-ice-t2930451) supports CIFS. I use it to connect to my SAMBA linux server. I also did the following, not sure if both of these are necessary: set SELinux to permissive with SELinux Mode Changer, and use the "patched" version of CIFS Manager (found on this forum).
I'm still hoping somebody will just write or cross-compile a FUSE module (like SMBnetFS) that works on all rooted devices, so we don't have to rely on custom kernels/modules anymore...
Since you asked for alternatives, you can also just get an OTG cable and hook up a USB stick or external HD to your phone (needs root and an app like StickMount).
Thanks for the reply. Been a bit busy with life stuff and just finally got to sit back down and look at this again.
I agree that a FUSE module would be useful for something like this. I don't have a need for high performance with regards to this problem, so a FUSE module would seem very appropriate.
I do have an OTG cable and I do have a 64GB thumbdrive I can use. I was just hoping for something that was a little non-obtrusive and passive so that I'm not actively having to be involved in the backup process itself. As soon as someone in the meat-world has to take active steps to make a backup every time, that's when backups typically stop happening, and then the next thing that happens is data loss. So I'm trying to remove myself from the equation as much as possible.