Hello.
I discovered that the encryption, which I understand comes with ICS, is not available with my cheap D2Pad with ICS 4.0.4. I have looked in Settings/security, and do not find encryption there, or anywhere else. The online documentation points me to Settings/Personal/Security/encryption, but my problem is that Personal and Encryption are missing entirely from my settings interface.
Is it possible to install Encryption through a file obtained here at XDADevelopers? I have downloaded a settings.apk posted by one of your members. Is this what I need to replace? Would I use ADB to push/pull the Settings.apk?
My theory, after doing some reading on this, is that my device has a dumbed-down version of ICS, which has excluded encryption from the settings.apk.
May I ask for your advice?
The NOOB video is wonderful, by the way.
Thanks in advance.
Robert
Ever since I've moved to AOSP based roms (SlimKat, CyanogenMod, OmniRom, Resurrection-Remix,...) , I've noticed that in the DDMS tool (a tool for developers) that it shows all processes, and not just debuggable processes, including all third party apps' processes and OS's processes.
This never occurred for me on stock roms, no matter which device or stock rom I've looked at.
This issue annoys me as a developer, since I usually run only a single app that I develop and when I go to DDMS to choose the app's process, I need to find it amongst many processes (even of WhatsApp) , and, provided it hasn't changed its position on the list, click it and debug it.
So I asked about this on some kernels forums, and usually people didn't mind about it (and for good reason - it can bother only few people).
I've found the next tweak which can do it, but since I'm a complete newb in creating/modifying kernels, I have no idea how to patch it:
setprop ro.debuggable=0
Click to expand...
Click to collapse
Found from here .
I've contacted a few kernel developers and one of them agreed to check it out. I've tested it on CM and it worked just as it was intended :
Only debuggable apps' processes were visible and ready to be debugged.
Anyway, I wish to ask whoever is an expert in developing/modifying kernels those questions:
1. Why isn't this tweak enabled by default?
I mean, this is not the normal way roms work. It's not like this on any stock rom I've seen, not even on Nexus stock roms...
I also don't get why it's this way even for "final/stable" version roms (meaning not nightlies or experimental ones), since you'd probably not need to be able to debug them (users won't give you their device just for that...) .
2. Can you please explain to me, step by step (but don't assume I know anything about kernels development), how to take a rom's zip, and change its kernel so that this tweak will be enabled?
Maybe I could make an automatic tool that does it, either in Java for desktop or for Android.
3. Is there any way to enable this tweak without modifying the kernel? Maybe by using a tool that works with it?
Or maybe, provided we got root, change something to enable it?
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
oxiroxt said:
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
Click to expand...
Click to collapse
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
synesthete said:
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
Click to expand...
Click to collapse
OMG Finally some light! THANK YOU, THANK YOU, THANK YOU for all the info. I didn't get much right now, I'll need to read through your post a few times before I get it all, haha. I'll be sure to check the links too. Thank you!
First off, before I get into it; nay sayers and trolls please keep the thread clear. Hopefully we can figure something and more minds together normally equal victory.
Last night an idea hit me, I use a hack with Windows that allows admin permissions and I don't have enough info about android apks to say that it wont work.
In Windows (yes I know they are way different) if you can figure a way to temp change one sys program to be command prompt, you can add users, change admin passwords, delete logs and the such. Basically you own the box at that point. Im not going to go into the details cause as far as I know M $ hasnt fixed it and I dont want them to.
So if we can find an apk with root writing permissions and can change it to be a term emulator we should be able to chmod root.
I have made some attempts, using the hidden menu apk. I figure it can change the prop file it should have root privileges; with no luck. Maybe I am not repackaging the apk correctly or something?
If someone that knows more about apks thinks it may be a possibility lets get to cooking!
The Command Prompt trick you're talking about is very well known. It's been around since Vista and has yet to be patched and unlikely to be due to the nature of how it works.
Thanks Pirate, I know what versions it works with. But I guess no one knows how we can possibly accomplish the same in android.
Zer0C0oL said:
Thanks Pirate, I know what versions it works with. But I guess no one knows how we can possibly accomplish the same in android.
Click to expand...
Click to collapse
If you did, wouldn't you end up in a bootloop due to dm-verity, or is this not modifying /system?
Lifehags said:
If you did, wouldn't you end up in a bootloop due to dm-verity, or is this not modifying /system?
Click to expand...
Click to collapse
The way I understand the DMVerity mechanism is it rebuilds its trust chain every time a legitimate system change is made. When you perform a PRL update, the app makes a change to the system. This does not equal bootloops and I believe we can accomplish the same via this hack, if apk permissions can be loaned.
In the M$ hack you can't leave the change in place as it messes up other processes. Basically you use it to add a user with admin permissions/ open a backdoor and then cover your tracks: which one step is reverting the swap so there are no system issues for the users to find.
Alas, I fear the people this post should be reaching are the ones working towards claiming the bounty and for that reason collaboration will be non-existent.
@Zer0C0oL, please note that unless you are a developer working on a recovery, ROM or a Kernel, you should not be posting the development section. Please refer to this announcement if you have any questions.
I've moved this thread to the How-To section where it belongs.
Cheers :good:
Zer0C0oL said:
First off, before I get into it; nay sayers and trolls please keep the thread clear. Hopefully we can figure something and more minds together normally equal victory.
Last night an idea hit me, I use a hack with Windows that allows admin permissions and I don't have enough info about android apks to say that it wont work.
In Windows (yes I know they are way different) if you can figure a way to temp change one sys program to be command prompt, you can add users, change admin passwords, delete logs and the such. Basically you own the box at that point. Im not going to go into the details cause as far as I know M $ hasnt fixed it and I dont want them to.
So if we can find an apk with root writing permissions and can change it to be a term emulator we should be able to chmod root.
I have made some attempts, using the hidden menu apk. I figure it can change the prop file it should have root privileges; with no luck. Maybe I am not repackaging the apk correctly or something?
If someone that knows more about apks thinks it may be a possibility lets get to cooking!
Click to expand...
Click to collapse
I'm pretty sure it may be possible however impossible to avoid tripping knox.
Hey, I hope I am in the right place.
I need to do some modifications to a custom android version.
I have the source code of the whole android and can compile it,
thing is, I need to modify some system settings so these are my questions:
1. Is it possible to see which driver is loaded into the system?
2. Is it possible to see some sort of booting log? What is being loaded into the system, stuff like that.
3. Is it possible to modify this drivers list? Change which driver is loading, cancel loading of a specific driver and so on.
Also, if anyone could refer me to a guide on the matter, something that explains the system level of android I'd appreciate it too
Bump. Anyone?
Bumpy again