Related
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
can someone tell me if is possible port Android on this amazing device??
someone is working on this???
I wuold like a lot if someone port Andoid on oHD!!!
lukas_ita said:
can someone tell me if is possible port Android on this amazing device??
someone is working on this???
I wuold like a lot if someone port Andoid on oHD!!!
Click to expand...
Click to collapse
I was working on it for a long time. Unfortunately it is impossible, due to limited bootloader space (not enough for an android one) and no recovery partition. Also it would need a totally new partition layout (as it only has two accessable internal and one external drive, so no cache, recovery access, nor swap.
And also do not forget about the hardware incompatibility. Even if we manage to boot it, you will hardly be able to even make a phone call. Not to say use WiFi, or GPS, BT, or anything.
hi i joined because of some interest in this,
first of all let met tell you that i own a samsoung i8320 (vodafone h1).
this in some way helps because we now have a 'working' limo kernel, in my opinion it might help us out here.
the problem i have is that i never ever yet have been able to do 'any of the work here under' - the fact that i know howto doesn't make me capable of doing, (its like the fact that you know a plain fly's because of big wings and an engine, doesn't make you a pilot)
---------
the H1 uses a rather standard linux kernel as far as i can tell from the source could, though i havn't been able to run it inside quemu yet..
some guys allready interested in porting android say that they got android running but without functions like phone or wifi. this is because thay used an android kernel rather than the samsung one.
step 1:
so what if you would strip the samsung rom from all 'userland' software, keeping only the kernel, its drivers and busybox stuf.
creating a root shell only - you may even be able to make it mount as /boot rather than /
step 2:
now ad ad adtional filesystem on the internal phone memory or an external sdcard ... format it as you like (ext3 with noadtime could do, but other options are also availible).
this should now be where the remaining of the android rom should be. you could now always update most of your your android and apps exept for your linux kernel or drivers. without reflashing. this idea is largely based on apps-2-sd so we all know its been done before.
fonix232 said:
I was working on it for a long time. Unfortunately it is impossible, due to limited bootloader space (not enough for an android one) and no recovery partition. Also it would need a totally new partition layout (as it only has two accessable internal and one external drive, so no cache, recovery access, nor swap.
And also do not forget about the hardware incompatibility. Even if we manage to boot it, you will hardly be able to even make a phone call. Not to say use WiFi, or GPS, BT, or anything.
Click to expand...
Click to collapse
The i8910 community is great....this phone is great...a porting of android on this phone wuold mean a great number of donations!
cannot you use E\ (massmemory...8Gb or 16Gb) like partition?
I am using Truecrypt on my PC as well as Ubuntu 10.10.
I am looking for a similar technology in Android.
Like you can mount and unmount a container like a SD card.
Nearest I reached was, people suggesting hiding files, which is not secure, simply put the card in another machine, you will see everything.
Another suggestion was to use some secure files, but it can store some information only.
I cannot see any evidence in truecrypt forums, they are working on any android version.
I was just checking Folder Lock, they do have a iPhone version. Not that impressive idea. Needs to upload data online to see in iPhone!!!
We need better and safer ideas from Androids.
Crack on...
I have the same problem for Android.
The only programs I found that you can use are secretvault pro en FileCrypter.
I use the last one. It encrypts the folder you want, but it's a little bit slow for maps above 100 MB.
I don't understand that with more than 250.000 apps, nobody comes out with a program like truecrypt, etc, where you can mount the map as a container with his own driveletter.
Berny Boss said:
I have the same problem for Android.
The only programs I found that you can use are secretvault pro en FileCrypter.
I use the last one. It encrypts the folder you want, but it's a little bit slow for maps above 100 MB.
I don't understand that with more than 250.000 apps, nobody comes out with a program like truecrypt, etc, where you can mount the map as a container with his own driveletter.
Click to expand...
Click to collapse
technical limits maybe?
Just manually encrypting folders and files might be no problem, but truecrypt is different. files from a truecrypt storage are decrypted in memory and there's a driver that makes the native file functions of the OS think that the files are coming from a real storage.
I don't think you can develop such drivers for Android, at least not on non-rooted phones. It would have been possible on Windows Mobile. I mean, it has existed already: SafeGuard for instance.
Thank you very much for your suggestions
I tried both Filecrypter and secretvault pro on Samsung Galaxy S, but encrypted files were visible on gallery!!.
This was after encrypting the folder.
Does android 2.2 saves gallery viewed files in any cache or tmp folder?
Yes we are in a desperate need for encrypted containers, which can store anything.
If we loose phone, nobody will return it, we need to safeguard our personel files.
Let the thief format the sdcard and use it.
Encrypted Container for Android
Hi,
I did a project for a client implementing encrypted container for the android phone. Unfortunately I can't release any source. But, if somebody is willing to recreate this I can guide them. PM me for details.
i know this post is old, but is there anything available today that can mount veracrypt containers? i know of eds but its just awful. android should do this by now.
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.