Related
To create themes, or to edit themes to your liking, you will need a working knowledge of android, adb, how to resign apk's, knowledge of your own O/S.
Before you start be aware that you will may end up wiping your phone once, if not more. So lets go over the things that you will need.
You will need JF's RC30, RC8, or ADP1 V1.3, depending on what version you intend to create for.
Here is the link to these: http://forum.xda-developers.com/showthread.php?t=466174
You will also want to get the dev bootloader installed on your phone and to HIGHLY suggest everyone trying your theme to install it as well.
Link to dev bootloader: http://forum.xda-developers.com/showthread.php?t=455860
You will also need to resign all the apks located in /system/app and framework-res.apk located in /system/framework. When you push all of these to your phone.
JesusFreke was kind enough to build a custom signing tool for me that would allow me to right click on an apk and resign it from there. I am posting it here for others to use as well. Note that this is a courtesy of JF, so thank him for it. I cannot stress how much time this has saved me and will save you.
Here is the link: Http://www.FightForthePits.com/testsign(2).zip
Before using this you need to know how to set this up:
I will assume that you have the sdk downloaded and extracted somewhere(if not, do that now), extract both files to the tools directory of your sdk.
Now you will need to add the tools dir of your sdk to the environment variable CLASSPATH.(This is for XP, Vista coming soon)
To do this, right click on My Computer click properties, then choose the tab that says advanced. Click the button that says environmental variables. Go to system variables find the one that says CLASSPATH, double click it, go to the end of variable value. There should be a semicolon ; at the end. type in the path to the testsign.jar located in the tools directory of your SDK, for example the path to my testsign.jar was c:\sdk\android-sdk-windows-1.0_r1\tools\testsign.jar If CLASSPATH is not in your system variables then create it. Secondly, Find the system variable called PATH and add to the end of it, the full path to your sdk directory. For example, mine was c:\sdk\android-sdk-windows-1.0_r2\tools
Now right click the reg file that you extracted and choose to install it, or merge.
Now, right click an apk, do you see an option that says ResignApk? That's how you will resign your .apks and .zips.
If you find the right click menu not working for some reason you can type the following in cmd to sign your files: java testsign whateverfiletosign
Now through doing this you have done two things, first off you have made the resigning process extremely easy, secondly you will not have to cd to the tools dir of the sdk to use adb or any other tool in the sdk.
You will also need a version of linux installed or running vmware with linux, if you want to create, or edit, an update script, which will install the theme onto the users phone.
You will need to be specific in addressing what version your theme is for, RC8, RC30, or ADP1. Make sure every file gets signed. Make sure you test the update.zip before you release it.
Every .apk contains the images relating to itself. However, every apk has the ability to use the images in framework-res.apk. The images for every apk is located inside of itself. To find these images open up the apk, you can rename it to .zip or open it with an archiver of your choice, winrar, winace, etc. Then after opening the apk open the folder called res and inside of that there are folders that are named Drawable, drawable-land, drawable-port, etc. This is where the images are stored.
Ther are some things you cannot edit unless you rebuild the entire apk from source, which we will not go into here.(another tutorial, another time) Just know that at this time you SHOULD NOT edit, or even open images with the extension .9.png. If you do you will have problems...Trust me. These are special images called ninepatch images and android resizes these images to fit wherever android, or any other apk, needs it to. if you do open them or edit them they will no longer render correctly when resized. I believe that in order to edit these you must do so and then put them into the source and rebuild the entire apk.
Before getting started you must also realize that you cannot simply resign one or two apk's and stick them in your phone and expect them to work. You must resign every apk inside of /system/app and framework-res.apk and put them on your phone at the same time.
To simplify this process for you though, I have provided an empty update.zip which you can place all of your resigned apps into and use to update your phone to your custom theme. You can also download someonelses theme and use there files, since they are resigned already. It may also be easier to see what files do what and go where since they have already been edited and are easy to point out.
Now, your ready to start changing things up.
You will now need to open the apk, which you can do by adding .zip after .apk, effectively changing it to a zip. Note that if you are using windows you will need to unhide known file extension types. you can also use your favorite archiver such as winrar, winzip, etc.
See here to unhide known file extension types for Xp: http://www.mediacollege.com/microsoft/windows/extension-change.html
See here to unhide file extension types for Vista: http://maximumpcguides.com/windows-vista/how-to-change-a-file-extension/
After opening the apk go to res and copy the folders that have drawable in their name. Go to your desktop, or wherever, create a new folder called Images, or whatever. Open the folder, paste the drawable folders in there. Now you can see what the files look like without opening them. Btw, you may also want to add -frame, or -launcher, to the end of the folders you cope over to keep them separated from others.
Finally, you've edited the images put them all in the apk renamed it back to an apk and resigned it. Now it's time to push it to your phone and see the changes you've made.
Important! : Whenever pushing files to the phone NEVER do it while the phone is running. Do this in recovery mode! If you do this while the phone is running normally you will begin to lose space in /system.
So, boot into recovery plug your phone in and open a cmd prompt. From the cmd prompt type adb shell mount /system then type the following: adb push c:\whereveryourfileis\whateveryourpushing.apk /system/app (system/framework if your pushing framework-res.apk)
Now reboot your phone. If it doesn't boot, try doing a wipe, if that doesn't work reinstall an update and try again. There are alot of things people can do wrong, I can't explain them all here. If you get real stuck, you can ask for help here or contact me on Gtalk [email protected].
So now your theme is done and your ready to make an update.zip for others to install your theme.
I have created a template for you to make your own update.zip. Just download, add the system apps to app, and framework to framework. Zip it up, SIGN IT, TEST IT YOURSELF, and then distribute it!
Empty update.zip template: Http://www.FightForthePits.com/Androidstuff/update_empty.zip
If anyone has any questions please try asking for help in this thread before emailing me for help Usually I will respond to questions in this forum.
I hope this Tutorial has been helpful. I will add on to it as needed.
Stericson
Links of interest:
Downloading SDK: http://code.google.com/android/intro/installing.html
Using ADB: http://code.google.com/android/reference/adb.html
Working with ninepatch should be straightforward if you use the draw9patch tool included in the SDK. Documentation on usage here:
http://code.google.com/android/reference/draw9patch.html
JF could also save theme users a wipe by resigning /system/app/* and /system/framework/framework-res.apk in his builds with the test keys. Nice tutorial, btw.
However it doesn't. I have used that to no avail. I believe you need to edit the images, put them in the source then rebuild the apks from the source.
As for JF's update, it does not currently wipe your phone after install. So, for him to do this he would have to have his update do a wipe. So technically, they would still have to do this initial wipe.
Stericson
Stericson said:
However it doesn't. I have used that to no avail. I believe you need to edit the images, put them in the source then rebuild the apks from the source.
Click to expand...
Click to collapse
Good point. I thought you could simply drop a similarly dimensioned PNG in but apparently there is some metadata that only the android tool can create.
As for JF's update, it does not currently wipe your phone after install. So, for him to do this he would have to have his update do a wipe. So technically, they would still have to do this initial wipe.
Click to expand...
Click to collapse
True, but a user who is upgrading to a JF update after having put in customized (and test-key signed) system apps will have to wipe again anyway =) Anyone using custom themes will have to wipe every time a JF update (or any update) comes out. However if JF resigns, custom theme users would not have to wipe and stock theme users only have to wipe once. (Nevermind the fact I think everyone should wipe when updating...)
thx stericson this will help big time how long before I can get resigned rc30 last night when you said all the apk. need to be resigned I was like this is going to be a long night but I see jf hooked you up save some big time with his resigning tool
jashsu said:
Good point. I thought you could simply drop a similarly dimensioned PNG in but apparently there is some metadata that only the android tool can create.
True, but a user who is upgrading to a JF update after having put in customized (and test-key signed) system apps will have to wipe again anyway =) Anyone using custom themes will have to wipe every time a JF update (or any update) comes out. However if JF resigns, custom theme users would not have to wipe and stock theme users only have to wipe once. (Nevermind the fact I think everyone should wipe when updating...)
Click to expand...
Click to collapse
Ah, good point
The resigned apps will be released maybye sometime tonight...I had them done but ran into a script problem on adp1 and I have yet to try the rc30 and rc8 ones yet. so I won't release those until I've tested them. If you want to be a Guinea pig however, just let me know
Stericson
Stericson said:
Ah, good point
The resigned apps will be released maybye sometime tonight...I had them done but ran into a script problem on adp1 and I have yet to try the rc30 and rc8 ones yet. so I won't release those until I've tested them. If you want to be a Guinea pig however, just let me know
Stericson
Click to expand...
Click to collapse
The resigned apps have been released, each update file will resign all of apps in /system/app and framework-res.apk. However, these updates make no changes to them whatsoever...Meaning your phone will look just like a brand new phone without any modifications.
rc30 works thx Stericson made it easy for use
Issues with using the update.zip above
Hi all,
I just wanted to point out that after I applied the update.zip above and rebooted applications kept force closing randomly and constantly even through the initial setup (where you have to click the green android to start).
Prior to this, I had JF's RC30 1.3, and the engineering bootloader V2 no sigcheck.
First I did just a alt+s then a alt-w and alt+s. And still nothing.
I'm new to all this so I'm not even sure where to begin troubleshooting. Should I be using the HardSPL?
Thanks in advance and I appologize if this isn't the right place for this post.
Update:
After reflashing with JF's 1.3 RC30 and the problem persisted I noticed that there was a new release 1.31 and this has fixed the problem. I hope this helps anyone else who runs into the same problem.
I still don't know what went wrong though, can anyone shed some light on this? thanks.
Truly there's no telling, sounds like J'f's update fixed it. Can I ask what version you tested?
I would also like to announce that now, thanks to JF, again, you do not have to wipe your phone completely to apply the resigned app updates. However, you will have to re-enter your google info and your call history and other minor things will be gone, but all of your apps will be retained.
Stericson
Alright, I am a little confused........
So I downloaded testsign.zip and extracted it to the tools folder. Then I went into environmental variables and added CLASSPATH with the value D:\Android\tools\testsign.jar and now I am not sure what to do next. Can someone give me some clarification. And btw I am on XP but I can get on linux at home if I need it, but I am a total noob to all this stuff so be gentle.
I'm using http://www.fightforthepits.com/Androidstuff/update_Rc30.zip and have been encountering issues when the phone boots up. As soon as the initial phone setup comes up I get process force close errors, I extracted launcher.apk, edited the files I wanted, repacked it, signed it and then resigned the update.zip. Any ideas what I'm doing wrong? I'm already running JF's RC30 1.31
Did you repack it in linux? Did you resign Launcher.apk? Also, that update file was never meant to be used as a template for an update since it kind of wipes your phone. You should be using update_empy, to push your own theme.
If you want to do only one file at a time, flash that update(update_rc30) then adb push your file into system/app. There are lots of things that you can mess up, most of them are hard to catch too. At any rate, everyone who has made a theme can tell you it's not just a straight forward process, expect errors. I've had more than I count I know....
Trial and error is your best teacher
Stericson
Stericson said:
Did you repack it in linux? Did you resign Launcher.apk? Also, that update file was never meant to be used as a template for an update since it kind of wipes your phone. You should be using update_empy, to push your own theme.
If you want to do only one file at a time, flash that update(update_rc30) then adb push your file into system/app. There are lots of things that you can mess up, most of them are hard to catch too. At any rate, everyone who has made a theme can tell you it's not just a straight forward process, expect errors. I've had more than I count I know....
Trial and error is your best teacher
Stericson
Click to expand...
Click to collapse
Must .apk's be signed if they're pushed over ADB? I'm not running Linux, I'm repacking/signing in windows.
I also had the issue with force close when installing the resigned update from the first post, apps that shouldn't even run on start up were force closing.
Also the IM application was gone, had to do a wipe and go back to jf 1.31 to correct it
I will take another look at the update I provided...
Stericson
did you ever figure out how to change the text on the status bar from black to white?
to do that you have to rebuiuld the entire apk from source and edit an xml document
Stericson
has anyone tried making the icons bigger? I noticed they are 48x48 if we go bigger will that affect anything? Also has anyone been able to remove the text below the icons on the home screen? Oh and where is the tab located that has been made invisible?
*edit
well I tried making the icons bigger and it doesn't really do anything, they don't show up bigger on the screen. Might have something to do with the text underneath, not sure.
Kyeld said:
Must .apk's be signed if they're pushed over ADB? I'm not running Linux, I'm repacking/signing in windows.
Click to expand...
Click to collapse
yes they must be signed.
'K, so'm new 2 android hacking, but I'd like 2 make a framework-res.apk that includes StarBurst's MotoBlur x-itions here, SAShady's CRT Off animation here, & Gingerbread's Overscroll & MotoBlur Orient8ion animations when they become available. How would I go about merging the MotoBlur x-itions w/ the CRT Off animation, as they're both framework-res.apk files? Also, where mite I extract Gingerbread's Overscroll & MotoBlur Orient8ion files, is it from a stock Gingerbread framework-res.apk & MotoBlur (possibly Photon 4G) framework-res.apk? &, how would I know which files 2 extract? Are there any particular s/w tools that I need?
Thnx.
That's going to be a bit of work. I just went through the learning process of decompiling, modifying, and recompiling .apks myself. I don't have the most efficient method down yet, but I can get you started.
First up, are you using an odexed or deodexed ROM?
Thnx 4 the help.
Sycobob said:
...I just went through the learning process of decompiling, modifying, and recompiling .apks...
Click to expand...
Click to collapse
I'd really dig a link(s) to these resources. &, I'd b usin' the Stock ROM, which I'd imagine is odex'd.
EDIT: Man do I feel foolish. I just typed out way more than I needed to, thinking framework-res.apk was odexed. *sigh*. Oh well, I guess I just started the tutorial I was thinking about posting.
This won't be too hard:
Pull your stock framework-res.apk from /system/framework/.
Gather the other modded .apks
Decompile each of the .apks (luckily framework-res.apk doesn't rely on other stuff, so decompiling is easier)
Drag the modified file(s) from one of the decompiled, modded .apks to the stock one overwriting the old file(s)
Repeat for each mod
Recompile the new uber-modded .apk
Push it back onto your phone
Decompiling
You're going to need Apk Manager for decompiling and recompiling.
Place the .apks you want to decompile in the 'to be modded' folder of Apk manager
Run the script in the Apk Manager folder
Enter 22 to 'Set Current Project'
Pick the .apk you want to decompile
Enter 9 to decompile (no dependencies)
Repeat 3-5 for each .apk
Recompiling
(In Apk Manager) Enter 22 to 'Set Current Project'
Enter 11 to compile
Enter y (this is a system app)
Enter y (I haven't been able to get it to work when I answer no here)
Follow the prompt and delete the files you've modified from the 'keep' folder
Go back to the command prompt and press a key to continue
As for actually finding the changes, you're on your own here. I guess you can look for files with different sizes/modified dates or try to search the forums to see if people mention what they had to change for the mod. If two mods change the same file, you're going to have to open the file and make both sets of changes then toss it into the .apk.
Pro tip: if you have Eclipse set up with the Android SDK, you can go to Window > Preferences > XML > XML Files > Editor and check "Split multiple attributes each on a new line" so that when you hit Ctrl+Shift+F while looking at the messy decompiled .xmls it will instantly format it into a more easily read form. <--This is why I love Eclipse
If you don't know how to push the file back into place, it's a bit of a pain without a modded boot.img that allows you to use 'adb remount'. Copy the .apk somewhere on your phone. From command prompt (with phone plugged in):
Code:
adb shell
su
stop
mount -o rw,remount -t ext3 /dev/block/mmcblk1p21 /system
cp /wherever/your/file/is/framework-res.apk /system/framework-res.apk
mount -o ro,remount -t ext3 /dev/block/mmcblk1p21 /system
reboot
Unless you have CWM and know how to write/reuse an update.zip.
Thnx, Sycobob. I'm just afraid that there'll be an overlap in overwritten files. But'll c.
Sycobob said:
...and updating the archive...ext3
Click to expand...
Click to collapse
&, what d'ya mean by upd8ing the archive, is it signing? Also, I'd thought all of the E4GT partitions were ext4. Didn't even activ8 my E4GT, 'cause'm still tryin' 2 get my TP2 repaired, so I can flip it. Maybe u can help me w/ another Q - I've been lookin' all ovr 4 info on android OS, &'ve been able 2 find what each partition is, using adb cmds, but cannot find, 4 the life of me!, a glossary of sorts on all of androids system files, a la "framework-res.apk is..." I really wanna get n2 android hacking/modding w/o havin' 2 use an app 2 make any & every change that I'd wanna make 2 the OS. Comin' from WiMo, I was very familiar w/ the registry, exploring & hacking it, but there's no real equivalent n android. Also, do go here & vote 4 my Brushed Aluminum Barely There Case with Kickstand suggestion. We're already n 9th place. Thnx again 4 ur help.
System packages don't get signed. By updating, I mean dragging the file into the WinRAR archive which automatically replaces the existing file in the archive, therefor updating it.
All the partitions are ext4. This is where my newbishness shows, I have no idea why I have to use ext3. /dev/block/mmcblk1p21 isn't the correct path either, but it works. In one of ptfdmedics posts he uses the same options. If I use the 'correct' mount -o rw,remount -t ext4 /dev/block/mmcblk0p9 /system it doesn't work. *shrug*
Also, I just realized something I missed in my first post. If you modify an .xml the resources.arsc in the .apk needs to be regenerated. This is done when you decompile and recompile the package. I'll be editing my previous post to reflect this.
As far as a glossary, I have no idea where to find one. I would mind having access to something like that though. If you find something, please post it.
EDIT: don't worry too much about overlap. I'd imagine it'll be easy to find the changes you need to make, then you can just copy+paste the relevant lines. Pro tip: if you have Eclipse set up with the Android SDK, somewhere in Window > Preferences > XML > XML Files > Editor > Check "Split multiple attributes each on a new line" and when you hit Ctrl+Shift+F while looking at the messy decompiled .xmls it will instantly format it into a more easily read form. Adding this to previous post.
Thnx, 4 all of ur help. I've got a lotta wrk ahead of me 2 experiment w/ this stuff. Now, just gotta find the time.
Welcome back everyone
For those who are not familiar with the series, I recommend checking out part I and then part II to get caught up on our continued efforts to modify a ROM to your every whim and need.
We will be utilizing some really cool tools today. They come at a price of patience and perseverance, you know, kind of like what Valve expects from all of their loyal customers, and the worst part is....they could release the HL3 in 10 years, and I would still throw money at my screen.
I digress again.
Today we learn how to decompile those sneaky APK's and the necessary Framework files. They are located in the 2 most important folders:
MD4_Version_1/system/app
MD4_Version_1/system/framework
We need to start at the beginning of this topic.
To begin, let us test your ability to use JAVA....Wait STOP! Java? Programming? We do not need to be experts at programming at all, in fact, implementing mods is really a copy and paste procedure for us noobs, but if you know how to JAVA, maybe you can create your own mods that you can share with the community. Also, I am not a programmer, but I do know how to use logic to trial and error the crap out of the mods until they work.
To test if you have JAVA installed, open up a command prompt in Windows (because if you have Linux, you are not going to even be on this beginner's tutorial now are you?)
type in:
Code:
java
You should see
Code:
C:\>java
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-server to select the "server" VM
-hotspot is a synonym for the "server" VM [deprecated]
The default VM is server.
-cp <class search path of directories and zip/jar files>
-classpath <class search path of directories and zip/jar files>
A ; separated list of directories, JAR archives,
and ZIP archives to search for class files.
-D<name>=<value>
set a system property
-verbose[:class|gc|jni]
enable verbose output
-version print product version and exit
-version:<value>
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -jre-no-restrict-search
include/exclude user private JREs in the version search
-? -help print this help message
-X print help on non-standard options
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions
-da[:<packagename>...|:<classname>]
-disableassertions[:<packagename>...|:<classname>]
disable assertions
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
-agentlib:<libname>[=<options>]
load native agent library <libname>, e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:<pathname>[=<options>]
load native agent library by full pathname
-javaagent:<jarpath>[=<options>]
load Java programming language agent, see java.lang.instrument
-splash:<imagepath>
show splash screen with specified image
Wait, you did not see this did you? Well it happens, you probably got an Unknown Command or some shenanigans that doesn't look similar to the above?
Do not worry, we will need to add JAVA to the environment variables. First head over to JAVA and download the Java Runtime Environment (JRE). Install as you would by clicking next next next next and next and next.
When it installs, it goes to a specific location. The problem is, sometimes Windows does not recognize that path, which is why when you execute the JAVA command in a command prompt it tells you unknown command. We have to tell Windows to search in the java installation folder that you just installed for the JAVA.exe program so Windows can add it to the list of areas to search when you execute a command.
To do this, we will need to add the path in the environmental variables, java explains that sometimes this should not be necessary. But use this for more information and an understand of how to do this to different operating systems.
My path was the default "PATH" for java
Code:
C:\Program Files (x86)\Java\jre7\bin
Once that has been added to the environmental variables, test out the java code and see if it looks like what I have from above.
After this is done, we will need to install the Android SDK, this can be found here
The SDK, is a software development kit. It will allow for a user to create software for your android phone. This tutorial will not be doing that because that is a very heavy order. It will require the release of the Kraken. I do not recommend releasing the Kraken. Unless it is harmless Cthulhu. He's so adorable.
Anyway, this will install platform tools for us to push files to our phone and allow us to to execute these commands.
Remember, we can add the tools of the SDK to our PATH variable so we can execute these tools in any command prompt and at any location.
If you are having trouble at this point, let me know in the comments below and we can try and address this issue.
Now that we have the basic tools down, we need to understand what the heck that APKTOOL, SMALI and BAKSMALI do.
These tools are used to decompile the our APK and JAR files.
Keep this in mind at all times
APKTOOL will decompile and combile APK FILES
SMALI compiles DEX FILES
BAKSMALI decompiles DEX FILES
Do you know what any of these 3 are? Maybe you do, maybe you don't.
The APK stands for Android application package. It is basically the app. In windows, it would be equivalent to the program. The APK is unique in the sense that all the files in the app are actually zipped inside an APK file.
That logic only deduces, we can open almost any APK file with 7-zip. This is good news until we realize, the APK files are actually encoded in a way. We cannot make serious mods until we de-scramble the code hidden in the APK.
This is where APKTOOL comes into play. The APKTOOL can de-compile the encoded files and put it into a folder for us to work with. We can then make our mods, recompile and then put it into our ROM.
After explaining Smali and Baksmali, we will begin a basic mod.
Smali and Baksmali are actually java archive files. They contain instructions to take a DEX file and de-compile them into very interesting SMALI code. DEX is an EXE file for our Android system. We can only de-compile a classes.dex file for now, for it contains the majority of the rest of the tweaks. As a result, doing this is important and very difficult unless you understand what is going on. We will definitely have examples so do not fret, did I mention a half life reference yet...I don't think so.
So back to APKTOOL, we are going to need to understand what it does before we begin. I am assuming you got your APKTOOL downloaded from here, go to your C: drive and create a folder in there called APKTOOL in there, unzip the downloaded file, there will be a file Setup.bat, execute that file and a command prompt window with Green text will appear, I recommend selection 1 first to ensure you have the latest version, but we do not need to do this.
We will need to press option 2, but it says we must place some files in the other folder first. The files needed are actually the framework files, basically, the way our rom interprets the files are needed for this APKTOOL to operate.We will need to go to our ROM's
MD4_Version_1/system/framework/ folder and copy 2 files
Code:
framework-res.apk
tw-frameworkres.apk
These files will be copied into
Code:
C:\APKTOOL\other
This needs to be done before you select option 2.
Once the files are copied, press 2, then we need to install the first two options, so go one by one and install both.
Then when you are back to the main menu, press 3 and setup the directories for your need.
Personally, I took the
Code:
C:\APKTOOL\other
folder and moved into my own working directory. Assume that the locations will be selected by you for organization. I will use the following folder for reference:
Code:
C:\other
This will have all of the tools I need, while you are at it, create a new folder in their called Smali and copy the Smali.jar and BakSmali.jar files in there, they will of course be named something else like smali-1.4.2.jar and baksmali-1.4.2.jar
Rename the files to make life easier
Code:
from
smali-1.4.2.jar
to
smali.jar
and
baksmali-1.4.2.jar
to
baksmali.jar
Back to APKTOOL, now back to me, Now back to APKTOOL, now back to me.
We will be victimizing a specific APK to get modding started.
Before we get started, this is where we start version controlling more seriously. As each mod you add could cause a freeze, hang, bootloop or whatever, so go to the folder of your ROM, select the four files
META-INF
system
boot.img
installbusybox
right click them and "Add to Archive". Zip file only remember, compression level( Normal to no compression is fine)
Now
Lets grab a copy of SecPhone.APK located in the system/app folder
And put it into
Code:
C:\other
Open a command prompt and navigate to that location of the APKTOOL
Execute the following command
Code:
apktool d SecPhone.apk SecPhone
If done successfully, you will something like
Code:
C:\other>apktool d SecPhone.apk Secphone
I: Baksmaling...
I: Loading resource table...
I: Loaded.
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: C:\Users\<Your User Name>\apktool\framework\1.apk
I: Loaded.
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Done.
I: Copying assets and libs...
C:\other>
This means it successfully decoded the file. We will have a folder called SecPhone that has a bunch of folders.
Navigate to the following folder:
Code:
C:\other\Secphone\res\raw
There are 2 .ogg files. Well well well, I thought we took care of these, hmm, guess we need to change these to whatever you need to. Let's assume you did this already and have replaced them. We will need to stop the "mods" for now, for we are learning a process not a mod per se.
So we are done "modding" the file, I know it is not a BIG mod but we are trying to learn how to do this now so we can do the heavy stuff later. Now we can continue to recompile the file.
Go back to command prompt and direct yourself to
C:\other>
Click to expand...
Click to collapse
The put in the following command:
Code:
C:\other>apktool b SecPhone new-SecPhone.apk
Notice we changed 3 things, the d became a b, the second option is the folder we are recompiling, the third is the name of the new file
You should then see something that might be worrisome:
Code:
I: Checking whether sources has changed...
I: Smaling...
I: Checking whether resources has changed...
I: Building resources...
aapt: warning: string 'reject_cause_location_reg_fail' has no default translatio
n in C:\other\SecPhone\res; found: es pt
aapt: warning: string 'reject_cause_location_registering' has no default transla
tion in C:\other\SecPhone\res; found: es pt
aapt: warning: string 'stms_version' has no default translation in C:\other\SecP
hone\res; found: ja
I: Building apk file...
C:\other>
The warnings will be acceptable for the time being as they are related to a different language setting. If you are in English, you will be fine. If you are not, then that is a different tutorial altogether. Also, there is a very particular code bug that occurred the very first time I ran these commands and caused a catastrophic failure, more than any Movie-to-Game adaptation could ever be,
But you think you are done here, well that is not true. You see,
We have compiled the new APK file but unfortunately, it is a system file, we cannot sign this file to tell Android it is legit, we will have to cheat at this point, just like Valve did by creating any other project except Half Life 3 after number 2, you know they have enough funding for it, they are making it, and if I get kidnapped, I will probably be in a basement at Valve which I won't mind if they give me a grav gun. On a side note, while Brian Cranston would make a great Gordon Freeman, I still think Hugh Laurie would do a good job, just saying.
So back to our dilemma. We have created a new file called new-SecPhone.apk, open it with 7-zip, do not do anything yet, open the SecPhone.apk file you should have, it is the original file in the C:\other folder, we will need to drag two files for signature's sake
Copy the
Code:
Meta-INF Folder
AndroidManifest.xml
directly into the new-SecPhone.apk file. This can be done by dragging the files.
This will allow Android to think the file is signed and legit.
Take the new-SecPhone.apk file and copy it to your desktop and rename it to SecPhone.apk
Then place it into your ROM's system/app folder.
Your "first Mod" is ready to go, pretty easy actually but I really think the method is what many of us lack and this centralizes the effort. When you want to mod any System file, this process has to be done.
Its not a crazy mod, that will be after we explain how to modify files with Smali and BakSmali.
That will be in the next part of this set of series. These keep getting longer, I know, but we have a boat ton to cover. I think a central place to go-to for this information is important instead of jumping around to so many places for information. Eventually, the plan is to stick them as one big post I hope so we can integrate the vast amount of knowledge flowing.
Let me know what you think in the comments below, feedback is important, I felt this is so far the most complicated of the series and it will only get crazier. Luckily we can ask questions and keep this series going with an understanding for ROM building and see how much effort goes into someone else's effort modifying one of these ROM's out there, this is just a stock ROM mod tutorial, imagine something like CyanogenMod or any crazy ROM with a boat ton of features. It is time consuming and they deserve mad props for their amazing work.
Again great stuff. Can't wait for the next tutorial!
Sent from my SPH-L710 using xda app-developers app
bigpappags3 said:
Again great stuff. Can't wait for the next tutorial!
Sent from my SPH-L710 using xda app-developers app
Click to expand...
Click to collapse
He is very informative, and puts it in ways I can understand!
------------------------
Sprint Galaxy S3
Need Help? PM
Hit the "Thanks" button if I helped!
I'm stuck
I've downloaded the APKTOOL zip, and there is no setup.bat file in the unzipped package. There are only two files in the package and nothing else. One is an application called aapt, the other is a batch file called apktool. Both of which when executed briefly open a command prompt window that closes before I can read what they say. I've followed every direction to a "T" thus far, and can't figure out what to do. I thought that perhaps I had a bad download, but I've re-downloaded the file several times without success. Any suggestions would be incredibly helpful.
Might have a solution
balcoresbane said:
I've downloaded the APKTOOL zip, and there is no setup.bat file in the unzipped package. There are only two files in the package and nothing else. One is an application called aapt, the other is a batch file called apktool. Both of which when executed briefly open a command prompt window that closes before I can read what they say. I've followed every direction to a "T" thus far, and can't figure out what to do. I thought that perhaps I had a bad download, but I've re-downloaded the file several times without success. Any suggestions would be incredibly helpful.
Click to expand...
Click to collapse
Well it seems they have changed up quite a few things on the Wiki page, the version I was using was 1.5.2, the package has moved around and it seems these instructions are as obsolete as they are dependent on a website to not change things around.
They still offer the 1.5.2 of course but in the archives, suppose it was my fault linking to a constantly changing website than to link to the files directly that I used which I was considering.
This is the link
https://code.google.com/p/android-apktool/
zalooa said:
Well it seems they have changed up quite a few things on the Wiki page, the version I was using was 1.5.2, the package has moved around and it seems these instructions are as obsolete as they are dependent on a website to not change things around.
They still offer the 1.5.2 of course but in the archives, suppose it was my fault linking to a constantly changing website than to link to the files directly that I used which I was considering.
This is the link
https://code.google.com/p/android-apktool/
Click to expand...
Click to collapse
Thanks @zalooa. I'll give it a go tonight for sure. I appreciate you getting back to me!
Welcome back everyone,
We are in knee deep waters now, probably committed and ready to get going on the last of set of tools that need to do some serious modding.
If you are not up to speed, please go to Part I, Part II and Part III.
Get up to speed on those tutorials first before we continue. Remember, this is not Call of Duty, this isn't even Star Wars, this War of the MegaZord 5. We are in the serious stretch of the basics of modding the final frontier son!
Our target today is to utilize the Smali and BakSmali tools.
As you recall from the previous tutorials, the Smali and Baksmali have been put in our very specific folder
Code:
C:\other\Smali\
So, what does the Smali/Baksmali code need to do for it to work? We will need a JAR file. The JAR is a java archive file. You can also open those files with 7-zip, in each of the JAR files we will look at has a classes.dex file which we will need
Each Jar file in our
Code:
MD4_Version_1\system\framework\
Will have a classes.dex file inside, since the name is the same for all files, this is very tricky to manage unless you are organized so remember that each classes.dex file you take out, you remember where the new one needs to go.
So, lets open the following file in 7-zip,
Code:
android.policy.jar
Take the classes.dex file and place it in the folder where the Smali.jar file is and Baksmali.jar files are.
Now open a command prompt to that location and execute the following code,
Code:
C:\other\Smali>java -jar baksmali.jar -o output classes.dex
You will not receive feedback from this command. Do not stress if it looks like nothing happened, of course coincidentally, a new folder has been created in our folder called output(You can name it whatever you want just trying to keep it simple.
This folder will have a de-compiled set of .smali code that will allow us to modify very critical settings and make amazing mods.
The good news is we have the technology now we need the....wait wrong show,
We have the ability to take any classes.dex file and modify it and we can recompile it and execute a mod perfectly.
To recompile, we will need to execute the following code
Code:
C:\other\Smali>java -jar smali.jar -o newclasses.dex output
This will create a new file called newclasses.dex
We will need to place it inside the android.policy.jar
Of course, take the file and place it on your desktop, rename it to classes.dex and place it in the android.policy.jar and your mods are ready to go.
So that's all you need to do because the signatures cannot be messed with so this is the best way to do it.
Now, to the modding part, we have the tools to do all the mods you can set your furry little thoughts on.
learned how to implement the following with all of the code belonging to their expert makers.
Removed increasing ringtone
Call Record built into phone
Quick Unlock implemented(only reason I got into this ROM modifying because it annoyed me to press OK button to unlock, only thing iPhone got right...lol android wins)
Sounds modified
Default Sounds Set
Free Tethering working
1 percent battery
Removed apps from system/app to reduce clutter
Modified default wallpapers from Samsung
Phone contacts Theming
4 in 1 reboot enabled
No Sound on Camera
TouchWiz default layout
Seems basic enough but it is all I need, sure there are much fancier things to add, but these tutorials are about adding only what you want.
If all of these sound like you need them or want them, I can go into how to implement these. Not sure what the level of interest is at this point from people as these are not terribly tricky but sometimes, the code made from the original developer does not match exactly and then you have to find it and implement it.
Of course, this comes at a great cost to time, as I was working one each mod, I made 17 versions had to back track to version 12 as a mod I implemented had a bug I did not know exists until I did a fresh install.
This happens a lot by the way. The other day, I had Bluetooth on and connected to headset, a call came through, answered it, switched from headset to speaker and phone just turned off, I am sure there is another bug from another thing in another place that I overlooked.
My point is, making any mod will require a LOT of time. I installed each ROM after that glitch to make sure everything worked. I used Titanium Backup to assist me in my endeavor but it was a hassle to change all my settings to what I needed(there is a way to set your settings any way you want as well while working in the ROM)
The thing is, each developer here takes a great deal of time and effort to do this and sure they have the expertise but it was because they got down in the nitty gritty and found a way to make it happen. They also usually do it out of their good will and hearts(well most of the ones I know). It has to be the most inspiring thing ever to find a group of people that are not doing this to make money but they take time out of their lives and help us Nooblets out. I mean it is our super phone we want to modify right? And I want to say thanks to them. I want to say thanks to everyone who I mooched off their code for to get what I need, because without you, I would be on Google doing something unpronductive. Luckily, things started to work and mods made more sense and it is not so intimidating as it once was...of course several hundred flashes later, it better make more sense.
Thanks for everyone who reads this and gains something. This concludes the part of the tutorial I set out to accomplish and that was to get all the tools needed to make anyone a ROM builder(at least modifier).
Team Venum thanks for your great support as always you guys rock, I dabbled with their ROMs when I had an issue with exchange email
The MOAR team who helped me understand ROM structure for their crazy ROM.
loserskater for his quick unlock code which was by far amazing, I still look through the code and think he made it up on the spot.
lmike6453 who got me closer to figuring out loserskater's epic code.
So many more to thank but cant think of where all my research is, guess I should have listened to my own advice and stayed organized.
zalooa said:
Welcome back everyone,
We are in knee deep waters now, probably committed and ready to get going on the last of set of tools that need to do some serious modding.
If you are not up to speed, please go to Part I, Part II and Part III.
Get up to speed on those tutorials first before we continue. Remember, this is not Call of Duty, this isn't even Star Wars, this War of the MegaZord 5. We are in the serious stretch of the basics of modding the final frontier son!
Our target today is to utilize the Smali and BakSmali tools.
As you recall from the previous tutorials, the Smali and Baksmali have been put in our very specific folder
Code:
C:\other\Smali\
So, what does the Smali/Baksmali code need to do for it to work? We will need a JAR file. The JAR is a java archive file. You can also open those files with 7-zip, in each of the JAR files we will look at has a classes.dex file which we will need
Each Jar file in our
Code:
MD4_Version_1\system\framework\
Will have a classes.dex file inside, since the name is the same for all files, this is very tricky to manage unless you are organized so remember that each classes.dex file you take out, you remember where the new one needs to go.
So, lets open the following file in 7-zip,
Code:
android.policy.jar
Take the classes.dex file and place it in the folder where the Smali.jar file is and Baksmali.jar files are.
Now open a command prompt to that location and execute the following code,
Code:
C:\other\Smali>java -jar baksmali.jar -o output classes.dex
You will not receive feedback from this command. Do not stress if it looks like nothing happened, of course coincidentally, a new folder has been created in our folder called output(You can name it whatever you want just trying to keep it simple.
This folder will have a de-compiled set of .smali code that will allow us to modify very critical settings and make amazing mods.
The good news is we have the technology now we need the....wait wrong show,
We have the ability to take any classes.dex file and modify it and we can recompile it and execute a mod perfectly.
To recompile, we will need to execute the following code
Code:
C:\other\Smali>java -jar smali.jar -o newclasses.dex output
This will create a new file called newclasses.dex
We will need to place it inside the android.policy.jar
Of course, take the file and place it on your desktop, rename it to classes.dex and place it in the android.policy.jar and your mods are ready to go.
So that's all you need to do because the signatures cannot be messed with so this is the best way to do it.
Now, to the modding part, we have the tools to do all the mods you can set your furry little thoughts on.
learned how to implement the following with all of the code belonging to their expert makers.
Removed increasing ringtone
Call Record built into phone
Quick Unlock implemented(only reason I got into this ROM modifying because it annoyed me to press OK button to unlock, only thing iPhone got right...lol android wins)
Sounds modified
Default Sounds Set
Free Tethering working
1 percent battery
Removed apps from system/app to reduce clutter
Modified default wallpapers from Samsung
Phone contacts Theming
4 in 1 reboot enabled
No Sound on Camera
TouchWiz default layout
Seems basic enough but it is all I need, sure there are much fancier things to add, but these tutorials are about adding only what you want.
If all of these sound like you need them or want them, I can go into how to implement these. Not sure what the level of interest is at this point from people as these are not terribly tricky but sometimes, the code made from the original developer does not match exactly and then you have to find it and implement it.
Of course, this comes at a great cost to time, as I was working one each mod, I made 17 versions had to back track to version 12 as a mod I implemented had a bug I did not know exists until I did a fresh install.
This happens a lot by the way. The other day, I had Bluetooth on and connected to headset, a call came through, answered it, switched from headset to speaker and phone just turned off, I am sure there is another bug from another thing in another place that I overlooked.
My point is, making any mod will require a LOT of time. I installed each ROM after that glitch to make sure everything worked. I used Titanium Backup to assist me in my endeavor but it was a hassle to change all my settings to what I needed(there is a way to set your settings any way you want as well while working in the ROM)
The thing is, each developer here takes a great deal of time and effort to do this and sure they have the expertise but it was because they got down in the nitty gritty and found a way to make it happen. They also usually do it out of their good will and hearts(well most of the ones I know). It has to be the most inspiring thing ever to find a group of people that are not doing this to make money but they take time out of their lives and help us Nooblets out. I mean it is our super phone we want to modify right? And I want to say thanks to them. I want to say thanks to everyone who I mooched off their code for to get what I need, because without you, I would be on Google doing something unpronductive. Luckily, things started to work and mods made more sense and it is not so intimidating as it once was...of course several hundred flashes later, it better make more sense.
Thanks for everyone who reads this and gains something. This concludes the part of the tutorial I set out to accomplish and that was to get all the tools needed to make anyone a ROM builder(at least modifier).
Team Venum thanks for your great support as always you guys rock, I dabbled with their ROMs when I had an issue with exchange email
The MOAR team who helped me understand ROM structure for their crazy ROM.
loserskater for his quick unlock code which was by far amazing, I still look through the code and think he made it up on the spot.
lmike6453 who got me closer to figuring out loserskater's epic code.
So many more to thank but cant think of where all my research is, guess I should have listened to my own advice and stayed organized.
Click to expand...
Click to collapse
It was nicely done, thanks. :good:
Does anyone know if they already have a solution to fix the fingerprint on any GSI on the moto g7 play?
I don't think there will be a fix for it. GSIs are basically developed for testing purposes and are not functionally ROMs.
---------- Post added at 07:01 AM ---------- Previous post was at 06:58 AM ----------
https://source.android.com/setup/build/gsi
Guhl0rd64 said:
Does anyone know if they already have a solution to fix the fingerprint on any GSI on the moto g7 play?
Click to expand...
Click to collapse
I'm working on this right now. It requires a jar from /system/framework, and some libs from the stock OS. And maybe an overlay, but that part I'm unsure about. If I get anything working I'll post a flashable zip.
Spaceminer said:
I'm working on this right now. It requires a jar from /system/framework, and some libs from the stock OS. And maybe an overlay, but that part I'm unsure about. If I get anything working I'll post a flashable zip.
Click to expand...
Click to collapse
man, you are the g7 play hero ngl, can you post an explanation of what needed to be done when youve done it, you know like the technical side, so people like me can learn?
00p513 said:
man, you are the g7 play hero ngl, can you post an explanation of what needed to be done when youve done it, you know like the technical side, so people like me can learn?
Click to expand...
Click to collapse
I use a few methods in general to figure stuff out.
1. Google, Arch linux Wiki, stack exchange.
2. Sleuthing. Go digging though system files or app manifests.
3. Poke it with a stick. Running strings or grep on a file for keywords. Poke the box with the right input, and it'll often give you prizes in return. This is especially true for things you can't just decompile like a bootloader image. You can even do things like tease partition mounts from a vendor image this way.
4. Load files into a hex editor. I personally use HxD. This works similar to the poke the box method. If strings and grep are like a radio, then using a hex editor is like watching TV.
5. Don't reinvent the wheel if you don't have to. Look for things that you know accomplish the same, or a similar task, then adapt them to your situation. This isn't always easy but 90% of the time it'll get you there or damn close.
This project is a combo of 2 and 5.
I first went digging through system and vendor files. I know from prior experience that apps and hardware features often require library files (/system/lib/*.so), bin files (/system/bin & /vendor/bin), jar files (/system/framework/*.jar), and permissions (/system/etc/permissons & (/vendor/etc/permissions). Occasionally hardware features also have an init script to start them. (/system/etc/init & /vendor/etc/init)
So I searched with a root explorer for any files in those locations that have "finger" in the name. That gave me gold. I made a note and created a file structure to match them, then copied the files over and created a zip.
This is where #5 comes in. In order to flash it, we need a script to tell twrp how to mount the partitions we're going to modify, where the files go, and what file permissions to set. (rw-r--r--, 0755 etc.) I knew how to do this from modifying phh's su to work on Lineage OS 17. And I learned how to do that by looking at the flashable zips for, viper for android, and the universal disabler. Since I had adapted those for Phh su, when I needed to do it again, I pulled the scripts from Phh su and edited them to use the new files and permissions.
That's the jist of it. If you want to see how the scripts are written, extract the zip and look at META-INF/com/google/android/updater-script with a text editor. I recommend either Quick Edit pro for android, or notepad++ if using Windows.
Finger Print Test #1
If anyone running a GSI wants to test this, just flash it in twrp and let me know if the finger print sensor works. It should NOT break anything. If you get any flashing errors please tell me. It means there's a typo somewhere in the scripts and I need to fix it.
Spaceminer said:
I use a few methods in general to figure stuff out.
1. Google, Arch linux Wiki, stack exchange.
2. Sleuthing. Go digging though system files or app manifests.
3. Poke it with a stick. Running strings or grep on a file for keywords. Poke the box with the right input, and it'll often give you prizes in return. This is especially true for things you can't just decompile like a bootloader image. You can even do things like tease partition mounts from a vendor image this way.
4. Load files into a hex editor. I personally use HxD. This works similar to the poke the box method. If strings and grep are like a radio, then using a hex editor is like watching TV.
5. Don't reinvent the wheel if you don't have to. Look for things that you know accomplish the same, or a similar task, then adapt them to your situation. This isn't always easy but 90% of the time it'll get you there or damn close.
This project is a combo of 2 and 5.
I first went digging through system and vendor files. I know from prior experience that apps and hardware features often require library files (/system/lib/*.so), bin files (/system/bin & /vendor/bin), jar files (/system/framework/*.jar), and permissions (/system/etc/permissons & (/vendor/etc/permissions). Occasionally hardware features also have an init script to start them. (/system/etc/init & /vendor/etc/init)
So I searched with a root explorer for any files in those locations that have "finger" in the name. That gave me gold. I made a note and created a file structure to match them, then copied the files over and created a zip.
This is where #5 comes in. In order to flash it, we need a script to tell twrp how to mount the partitions we're going to modify, where the files go, and what file permissions to set. (rw-r--r--, 0755 etc.) I knew how to do this from modifying phh's su to work on Lineage OS 17. And I learned how to do that by looking at the flashable zips for, viper for android, and the universal disabler. Since I had adapted those for Phh su, when I needed to do it again, I pulled the scripts from Phh su and edited them to use the new files and permissions.
That's the jist of it. If you want to see how the scripts are written, extract the zip and look at META-INF/com/google/android/updater-script with a text editor. I recommend either Quick Edit pro for android, or notepad++ if using Windows.
Finger Print Test #1
If anyone running a GSI wants to test this, just flash it in twrp and let me know if the finger print sensor works. It should NOT break anything. If you get any flashing errors please tell me. It means there's a typo somewhere in the scripts and I need to fix it.
Click to expand...
Click to collapse
Wow, thank you very much my friend, I will test now
Spaceminer said:
I'm working on this right now. It requires a jar from /system/framework, and some libs from the stock OS. And maybe an overlay, but that part I'm unsure about. If I get anything working I'll post a flashable zip.
Click to expand...
Click to collapse
Thank you.
---------- Post added at 06:41 PM ---------- Previous post was at 06:40 PM ----------
Guhl0rd64 said:
Wow, thank you very much my friend, I will test now
Click to expand...
Click to collapse
So...?
Marcondes BR said:
Thank you.
---------- Post added at 06:41 PM ---------- Previous post was at 06:40 PM ----------
So...?
Click to expand...
Click to collapse
I installed by TWRP, I have Lineage OS 17.1, still with the same problem
Descendent Modified GSI, doesnt work. It sees the reader, but doesnt recognise me touching it
Spaceminer said:
I use a few methods in general to figure stuff out.
1. Google, Arch linux Wiki, stack exchange.
2. Sleuthing. Go digging though system files or app manifests.
3. Poke it with a stick. Running strings or grep on a file for keywords. Poke the box with the right input, and it'll often give you prizes in return. This is especially true for things you can't just decompile like a bootloader image. You can even do things like tease partition mounts from a vendor image this way.
4. Load files into a hex editor. I personally use HxD. This works similar to the poke the box method. If strings and grep are like a radio, then using a hex editor is like watching TV.
5. Don't reinvent the wheel if you don't have to. Look for things that you know accomplish the same, or a similar task, then adapt them to your situation. This isn't always easy but 90% of the time it'll get you there or damn close.
This project is a combo of 2 and 5.
I first went digging through system and vendor files. I know from prior experience that apps and hardware features often require library files (/system/lib/*.so), bin files (/system/bin & /vendor/bin), jar files (/system/framework/*.jar), and permissions (/system/etc/permissons & (/vendor/etc/permissions). Occasionally hardware features also have an init script to start them. (/system/etc/init & /vendor/etc/init)
So I searched with a root explorer for any files in those locations that have "finger" in the name. That gave me gold. I made a note and created a file structure to match them, then copied the files over and created a zip.
This is where #5 comes in. In order to flash it, we need a script to tell twrp how to mount the partitions we're going to modify, where the files go, and what file permissions to set. (rw-r--r--, 0755 etc.) I knew how to do this from modifying phh's su to work on Lineage OS 17. And I learned how to do that by looking at the flashable zips for, viper for android, and the universal disabler. Since I had adapted those for Phh su, when I needed to do it again, I pulled the scripts from Phh su and edited them to use the new files and permissions.
That's the jist of it. If you want to see how the scripts are written, extract the zip and look at META-INF/com/google/android/updater-script with a text editor. I recommend either Quick Edit pro for android, or notepad++ if using Windows.
Finger Print Test #1
If anyone running a GSI wants to test this, just flash it in twrp and let me know if the finger print sensor works. It should NOT break anything. If you get any flashing errors please tell me. It means there's a typo somewhere in the scripts and I need to fix it.
Click to expand...
Click to collapse
I have tested on several GSI, and I have had no success
Guhl0rd64 said:
I have tested on several GSI, and I have had no success
Click to expand...
Click to collapse
You might need to add ro.fpsensor.position=1 & persist.qfp=false to the build prop.
Spaceminer said:
You might need to add ro.fpsensor.position=1 & persist.qfp=false to the build prop.
Click to expand...
Click to collapse
it still didn't work
Guhl0rd64 said:
it still didn't work
Click to expand...
Click to collapse
I'm unfortunately out ideas at this point.
Spaceminer said:
I'm unfortunately out ideas at this point.
Click to expand...
Click to collapse
I guess this means no fingerprint on Ubuntu Touch when i get it to work