Related
The answer is simple: do not include any non-open source apks or code that you have not explicitly received permission to distribute.
Instead, after building your entire update.zip, strip out all the proprietary software. Then, create a .bat and/or .sh file that will perform the following tasks:
- Download the official update.zip from the google.com site.
- Extract the required apks, obexes and jars.
- Add them to the correct locations in your update.zip
- Sign the update.zip (so include signapk.jar with your script)
- Rename the file update.zip
Name your zip as "incomplete-update.zip" (or something of the sort) and include your completer script with the file. Users will run the script and receive a complete update.zip as you had intended to distribute. THAT'S IT! A completely license-abiding way to distribute cooked "roms" without infringing on Google's licenses.
I wish google or HTC would contact me, I would say huh, what, me no speak spanish.... lol
Only if that would actually stop lawyers. God I hate lawyers. If that defense worked MMOGlider.com would still be working.
TheArtiszan said:
Only if that would actually stop lawyers.
Click to expand...
Click to collapse
It would, atleast in this case.
TheArtiszan said:
Only if that would actually stop lawyers. God I hate lawyers. If that defense worked MMOGlider.com would still be working.
Click to expand...
Click to collapse
Glider actually had a detrimental effect to the community, these mods don't. Horrible comparison.
afflaq said:
Glider actually had a detrimental effect to the community, these mods don't. Horrible comparison.
Click to expand...
Click to collapse
One man's detriment is another man's free market. It's a tough question.
Disclaimer: I hated MMOGlider and the people who use it, and wish they would've died in car crashes.
jashsu said:
The answer is simple: do not include any non-open source apks or code that you have not explicitly received permission to distribute.
Instead, after building your entire update.zip, strip out all the proprietary software. Then, create a .bat and/or .sh file that will perform the following tasks:
- Download the official update.zip from the google.com site.
- Extract the required apks, obexes and jars.
- Add them to the correct locations in your update.zip
- Sign the update.zip (so include signapk.jar with your script)
- Rename the file update.zip
Name your zip as "incomplete-update.zip" (or something of the sort) and include your completer script with the file. Users will run the script and receive a complete update.zip as you had intended to distribute. THAT'S IT! A completely license-abiding way to distribute cooked "roms" without infringing on Google's licenses.
Click to expand...
Click to collapse
This would work. But, it seems to me you could also take a similar approach that works like this:
1) Strip the proprietary code out of the update before signing.
2) Sign and distribute the update.
3) People install the update and return to the recovery screen.
4) Drop into terminal mode and run a script that downloads and installs the missing proprietary code in the proper places.
5) Reboot and enjoy.
Any reason that wouldn't work equally well (but be somewhat simpler)?
stellarman said:
This would work. But, it seems to me you could also take a similar approach that works like this:
1) Strip the proprietary code out of the update before signing.
2) Sign and distribute the update.
3) People install the update and return to the recovery screen.
4) Drop into terminal mode and run a script that downloads and installs the missing proprietary code in the proper places.
5) Reboot and enjoy.
Any reason that wouldn't work equally well (but be somewhat simpler)?
Click to expand...
Click to collapse
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk). However, if it can be worked around then yes, that would be a method too. Any variation on the theme of "partial update.zip plus files from a locally downloaded official update" would be good.
Is it more work to do this than just to distribute a fully complete (but not license compliant) update.zip? Yes. But it not only protects the cook from being C&D'd, it also helps to legitimize the "ROM" cooking scene.
You are still distributing the the unlicensed files, you are just providing a different way to distribute them. instead of including them directly in your ROM, you are supplying a script that adds them to your ROM.
Man all this is too much.... I might get rid of my G1. Google is always trying to ruin the good things for us. -__-"
jashsu said:
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk)
Click to expand...
Click to collapse
The framework.apk is APL and part of the Android source. To see what you get without the Googlebits, just run the emulator.
I think the easiest is to have the updater copy the proprietary bits from the phone to your SD card, perform update, then copy back. then reboot.
jashsu said:
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk). However, if it can be worked around then yes, that would be a method too. Any variation on the theme of "partial update.zip plus files from a locally downloaded official update" would be good.
Is it more work to do this than just to distribute a fully complete (but not license compliant) update.zip? Yes. But it not only protects the cook from being C&D'd, it also helps to legitimize the "ROM" cooking scene.
Click to expand...
Click to collapse
Read my post again. I am not suggesting that you try to boot without the parts. I am saying to use the terminal WITHIN Recovery. Do the step of re-adding the proprietary bits BEFORE you leave Recovery and reboot.
Actually people, let's not forget that perhaps Cyanogen had to modify some closed-source apps like Market and Camera on several occasions, right? To avoid crashes due to resource-id changes?
So just downloading older binaries might not always work?
--Tim
I sent a twitter to Cyanogen about this last night. Downloading every time would be slow and a waste of bandwidth. I think you could do it one of two ways.
1) add a script to cm-recovery that is executed with ALT+G the extracts the apks, etc from an official google dist file on the sdcard and copy them to the proper locations.
2) add a script (which does the extraction, etc. from a zip on the sd) someplace into update.zip. cm-recovery looks for that script and if it exists then it will automatically execute after the normal update routine is complete
3) a combination where the script is in update.zip but the users has to hit ALT+G to execute it.
I think #2/#3 would be most flexible because you wouldn't have to change recovery image for different ROMs and all ROM developers could have a custom script in their update.zip to fit their needs.
rewrite those applications if they haven't already been rewritten in one way or another many dialers, a couple marketplaces, youtube, all the apps could be developed just like messenger and browser come on lets just get around google and create the missing apps
kanstin said:
I sent a twitter to Cyanogen about this last night. Downloading every time would be slow and a waste of bandwidth. I think you could do it one of two ways.
1) add a script to cm-recovery that is executed with ALT+G the extracts the apks, etc from an official google dist file on the sdcard and copy them to the proper locations.
2) add a script (which does the extraction, etc. from a zip on the sd) someplace into update.zip. cm-recovery looks for that script and if it exists then it will automatically execute after the normal update routine is complete
3) a combination where the script is in update.zip but the users has to hit ALT+G to execute it.
I think #2/#3 would be most flexible because you wouldn't have to change recovery image for different ROMs and all ROM developers could have a custom script in their update.zip to fit their needs.
Click to expand...
Click to collapse
Anything that requires a user to press more keys is dumb. The problem Google has is that their apps are being redistributed by rom makers.
Lets take a look at how Google circumvents the same restrictions for HTC binaries: http://source.android.com/documentation/building-for-dream
Remember they are advocating circumventing HTC's proprietary licenses by running a script to copy these files. We need to do the same thing, and as long as we are coping the files, using the phone as the SOURCE, the process can be transparent to the user.
Edit:
Also has anyone thought about the fact that HTC proprietary files are being redistributed also? The phones are UNUSABLE without these files.
fauxhawk said:
Anything that requires a user to press more keys is dumb.
Click to expand...
Click to collapse
Yeah, it is dumb. Option #2 runs the script automatically and and Option #3 requires pressing ALT+G. Option #3 is in case the lawyers get really nasty; there is no way they can say that option is in violation because it requires user intervention (pressing ALT+G).
would this approach at distribution impact the optimization and tight fit of the ROM?
This is pretty much the same idea I had last night.
http://forum.xda-developers.com/showthread.php?t=564303
camalot said:
You are still distributing the the unlicensed files, you are just providing a different way to distribute them. instead of including them directly in your ROM, you are supplying a script that adds them to your ROM.
Click to expand...
Click to collapse
But you are not distributing these files. The update.zip you supply has absolutely no intellectual property which you are not entitled to distribute. Even the script, the IPR for it would be with the dev who write it. Now it might well be illegal - and personally I'd debate whether it is, but let's leave that for now - to *RUN* that script. But that's not the dev's concern and everything he supplied would be his own IPR.
Say you had a friend who worked for Google. It's the same as the difference between this friend emailing you a copyrighted MP3, versus you using Google to search for the same MP3 and then clicking on a link that appears. In the latter case Google hasn't distributed anything - they've merely provided the means for you to find the file on-line. YOU are then the one who breaks the law by downloading it. In the former case, it's your friend - and possibly Google as the people who provide the email system - who break the law.
Any dev who provided a script to download what is needed from a place on the internet and extract them from a zip would be very difficult to C&D.
Good day,
I am new to the forum so please forgive me if this is not the right place to ask.
I have been reading through some of the threads on the forum and is curious to know if there is a way to load custom kernel libraries or device drivers onto the phone.
If there is a way, is there a correct procedure? For example to load a custom device driver / kernel library, do I also have to have an entry in the registry? Does the dll file have to be in /Windows?
Thanks in advance.
Good questions. There's been only a little research on this so far. I can tell you waht I've found, though:
For a stock ROM, nobody has managed it yet, but it might be possible. You'll need to have your DLL signed, and the certificate added to the Code Integrity store on the phone (just mailing yourself the .cer is insufficient! That will put it in the wrong store). You'll probalby want the DLL to be in \Windows, although I'm not sure it's needed. You almost certainly will need to add registry entries; the current drivers seem to have them.
Good day,
thanks for your reply. And thanks for all the good research you have done.
So at the moment, the software approach is not working but for custom roms, is it possible to include custom device drivers / kernel libraries in them?
Thank you.
mousefish321 said:
Good day,
thanks for your reply. And thanks for all the good research you have done.
So at the moment, the software approach is not working but for custom roms, is it possible to include custom device drivers / kernel libraries in them?
Thank you.
Click to expand...
Click to collapse
Well, it's possible. The HD2 Multitouch driver is an example that its somehow possible. Should be the same for the other devices (espacially HTC first gens)...
But don't know what you're getting at? Why would you need a custom driver?
Good day,
well, I just think that having a driver that acts like HTCUtility would make things convenient.
As for file operations, besides the application that Heathcliff has created (WP7RootTool), are there other applications that can do write operations to the /Windows folder?
What are the things that needs to be done before we can write to that folder?
Thank you.
Any app with Elevated or TCB privileges can write to \Windows, I think. Using HtcRoot project or WP7 Root Tools works (both elevate apps to TCB permissions, though using different methods). Also, using an OEM driver, such as HtcProvisionDrv or HtcFileUtility, works (although those two particular drivers were crippled in the 4.x firmware).
Good day,
thanks for the information. I tried the HtcRoot tool and it works. Thanks for the tool and the source that allows me to know how it works.
Can I assume that I would be able to have write access to the Certificate and Code Integrity store also?
I am also curious as to the workings of HTCFileUtility. A quick search on this turns up little information on its workings.
Furthermore, is there a guide to inserting custom certificates to the root Certificate and Code Integrity store? I have tried downloading the Certificates.zip file in http://forum.xda-developers.com/showthread.php?t=1236027 and test rom files in http://forum.xda-developers.com/showthread.php?t=1248799 hoping that they will shed some light but is unable to download them.
Any help is appreciated. Thank you.
Yes, installing your own cert into Code Integrity is possible (in several ways, actually, but I did it using HtcRoot just as an exercise). The certificates are actually stored in the registry, so any tool that can write to HKLM can add them. I believe that WP7 Root Tools will also let you choose the store for adding a certificate if you "open" the cert from the Root Tools filebrowser.
Although I don't know exactly how HtcFileUtility works, here's the basics. It's a software driver that exposes an interface - probably an IOCTL - which apps can use to perform filesystem operations. Since it runs with TCB permissions (it's probably kernel mode, though I haven't actually checked, but it's definitely in TCB) it can perform any operation that the filesystem supports. Of course, that doesn't mean that it exposes all those operations through the IOCTL... but it exposes enough of them for a pretty solid filebrowser implementation (that's how TouchXplorer and Advanced Explorer worked, although they used an OEM COM DLL that called into the driver rather than doing the IOCTL themselves).
The new version of it has very limited operations permitted; it will only list files in a few folders and so forth. It does still "work" within those limitations - Connection Setup, for example, uses it to check the folder that we use for interop-unlock on HTC - but it isn't useful for a general-purpose browser anymore.
It would be great to even figure out how to roll back the OEM drivers to earlier versions. For example, I've got WP7 Root Tools installed on my HD7, but I don't want to install HTC updates because they'll break my drivers such that if something ever goes wrong I won't be able to re-install Root Tools, or if a new hack is found (or developed; I'm working on some stuff with HtcRoot still) I won't be able to run it on my phone. Being able to use the advantages of the new firmware (Internet Sharing, compass in managed apps, hopefully an end to the damn music player freezing between songs...) while still having hackable OEM drivers would be reallllly nice...
Good day,
thanks for the information.
I noticed in the HTCRoot project thread where you mentioned that "It is not a true handle (no handle table, no handle data) but everything that checks for tokens also checks for this const value, and appears to pretty much skip all remaining permissions checks if it finds it".
Would you mind sharing some of the function names so that I could take a look at the code where the checking occurs?
Thanks.
APKSPY - RESURRECTED
First:
I want to thank @ido for the original application -- It was his idea (and his code I've hacked :cyclops and modified.
Second:
Since Ido seems not to be active anymore I'll re-publish the application here.
Unless for some reason Ido will specifically ask me to remove it.
The original post
ido said:
ApkSpy is a simple tool I hacked up tonight which allows you to easily view the manifest of an APK (screenshots attached - not up to date though) just by double clicking it. (It can even associate with the .apk filetype, yay!)
ApkSpy relies on the aapt.exe tool from the android SDK, so you must have that installed (or just copy aapt.exe from somewhere, that's the only file needed to run ApkSpy).
Click to expand...
Click to collapse
Third:
Requires Microsoft©® .Net Framework v4
(Kind of since I've done it some time ago and waited for Ido [the orignal developer] to respond and allow or disallow me to re-publish... So, I don't remember all the changes I've already done...)
v1.8.19 CHANGELOG:
Fixed some Date parsing function (zipped file with no time stamp) in ZipStorer (by @Jaime Olivares) maybe causing some of the error reported here...
v1.8 CHANGELOG:
Changed Icon - CONTRIBUTED BY @Jarmezrocks
Removed unneeded tabs (System, Batch Rename, Log)
Minimize / Maximized restored back
v1.7 CHANGELOG:
(Actually 4.1.7.870, but the first and the last parts are internally used :fingers-crossed:)
Try to automatically find adb.exe and aapt.exe in ApkSPY directory or in PATH variable: If failed finding any of the executables, the user is asked to manually locate them
(★ Currently the location is not saved... ★).
Check if the ADB server is running and Start or ask if to Restart ADB server
Tidy up the code
Refining the original libraries written by Ido related to ADB and AAPT
Some more minor code updates
Revised most of the "General" tab (other tabs ware not touched) of the UI:
Grouped and ordered controls on form
Added DropDown of devices attached (★ Not automatically updating upon plugging... ★)
Added some control over ADB actions
Added status bar that some other details are shown, e.g. device type (Nexus, I9100...), OS version (4.1.2, 4.4.2...) and OS build (KOT49H, KVT49L...)
Added (nice looking) information panel with clickable links (for actions on the form) and coloring
Other changes (I can't recall right now, since I've done it some time ago and waited for a response from Ido for permission to republish)
(★ Maybe I'll add an option for this later, depending on my -- not to much -- free time and requested by users .... ★)
Known bugs:
Sometimes ADB fails to return build.prop property for the status bar (however it has not caused any critical problem, so (I think) it can be safely ignored) -- haven't been able (yet) to find the exact state it is happening
Please take the time to look at the application ABOUT tab
Any Other ideas are welcome!
If you like it, Don't forget to Thank me
If you enjoy using this application as much as I have enjoyed re-writing it
please donate to show your appreciation
RESERVED
Nice
Sent from my SM-N900T using Tapatalk
Good news
Bug report, every time I open this program, this dialog pops up, after click OK, this program works well.
PS, aapt.exe is in the same dir with ApkSpy
I got this errors:
1:
2:
Error in property: [email protected]@usrdata
cmlx said:
Good news
Bug report, every time I open this program, this dialog pops up, after click OK, this program works well.
PS, aapt.exe is in the same dir with ApkSpy
Click to expand...
Click to collapse
Hey dude,
I am not sure what you are doing wrong on your PC but it's certainly not the app as it works perfectly fine on my computer? Out of interest and for the sake or helping the new dev I thought I would raise a few points just to eliminate any finger pointing. There's a wishy-washy area when it comes to building/hacking things that were originally someone elses work...so yeah one can easily make great improvements yet open the door to bugs at the same time too. Anyway...thought I'd ask this:
Does aapt sit on your path? I know you said it is in the same directory, however just like a batch script in Windows it needs to "CD" or change directories to the %~dp0 if it is to understand what an executable is that happens to be sitting in the same directory as it's self. So this is is kinda directed at the new dev now. What I think is happening is that aapt is assumed to be in the system path when quite often it is not (i.e. those on XDA who have not yet played with the Android SDK properly). Put simply unless the application knows it is in the same directory as your executable it won't at all understand what aapt is. Does that make sense?
@dmagician , I would make sure that the apkspy app can do a check (even if it is a string search for the first few lines returned from aapt.exe), a simple if statement before throwing that error ....actually it would likely be an 'if not' statement. I don't have any of the code in front of me atm but I can help you out if you like? I was hacking this app myself sometime ago when ido first released it just using reshacker.
Note: If you are stuck and don't have source code you technically could write a full AutoIT wrapper for this app that could do all the checks and more and then bundle everything up into the one exe still. Check out the newer WinAPI stuff for AutoIT and in particular "Run binary" (yes that's correct you can just about run anything repackaged now and not need to deploy the original exe's or even libraries....they can all be stream fed to AutoIT @Compile time and need not be typically "installed" like you used to have to do. Anyway...I am waffling on shoot me a PM man.
@cmlx, to overcome your ApkSpy woes, and until dmagician can put his finger on what the cause is or what ido did when building it ages ago.....then you will firstly need to be patient (props to dmagician to figuring sh!t out so far) but till then where ever you have dumped the ApkSpy and aapt.exe on your system; just copy the address and put it on your system path. To do this 1) right click on My Computer or Computer if you are on Win 7 or 8. 2) Choose properties. 3) Advanced System settings and then at the bottom of tab you will see 'Environment Variables', click it and you will see some "User" and "System" options. Depending on your User access rights on the system you are running on (hopefully you are running as Admin surely?) then you can choose to edit your main system path or create a new variable in your user settings called 'path' Note User variables are always postfix to system variables but should always work anyhow.
Disclaimer: cmlx, if however you have already got an aapt.exe already existing on your system path but it is dodgy then you have to ensure that the good aapt.exe in your app directory is placed on path BEFORE the dodgy one....just sayin. Cause your system searches till it finds what it wants and then doesn't search anymore. Simple but can stuff people up quite often....and likely your case. Nowdays we tend to work from the known application location and not from a "Global environment path" when we know that there are going to be conflicts...and I can assure you that aapt is possibly the worst and most modified binary out there LOL. Hence this is also a note to the dev to ensure that ApkSpy reads from the current directory.....or like I am suggesting, wrap aapt up in the main application as well and that way there is no confusion EVER.
And I am done.....
Oh wait no I am not....sorry bug reports LOL :good: you thought I was all praise eh? Got another thing coming man
OK....so um the red boxes should explain everything. A picture says a thousand words (and yeah I needed at least 1 picture for this god damned long arsed post - sry). Um why in gods name would you remove the minimise and expand buttons? WTF? Anyway...it works but errrm yeah it doesn't wrap the text anymore? and it cuts the words off lol.
Other than that....I only really have one suggestion and it isn't even really a suggestion as I have kind of already made it so I can just give it to you if you want it? And that is that most people (well I can't say most as I am not speaking for everyone) tend not to like how apps take over their system. This isn't your fault at all in anyway as the first dev thought it was a good idea back then.....and back then hardly anything in Windows knew what a freakin apk was so it was a GOOD thing.....However now, every man and his dog wants to steel .apk extension for himself. I myself tend to be all over the shop with apks so I tend not to want to have any particular Windows app take it away from my control. I use WinZip as the main app for simple double click open as I want to see the contents of apks without needing to decompile them (great for theming) however I have apk shell extensions displaying the apks main icon to explorer, so if I set WinZip as default I get a nice lumping hunk of gold turd/box running rampet all over my Windoze bro ......so if you like I can show you my code that allows me to have default apps for specific tasks without interfering with anyones existing sh!t It looks neat too as you can right click any apk and just choose from a dropdown list what particular app you want at the time. If one has the need to use more apps then they need only put those apps in a list. There is nothing worse than double clicking an apk to find that Bluestacks or some other rubbish Windoze crApp has taken offf with your apk.
Lastly I thought I'd ask, Why no config file? Why store everything in memory? I know it's only small....but seeking for things everytime it is executed is a pain in the arse and not good practice. At the very least if you have no idea how to make an exe totally portable then you could reference a config file in the same directory....Or do as most do and write entries to the registry all neat and tucked away. If we get paranoid about "portable-ness" then we write to temporary space in the registry and make sure we clean up upon closing and/or inspect at runtime. simple!
I have plenty of AutoIT scripts that do exactly that too, so if you are stuck for ideas let me know. Anyway I have rambled enough, good luck and I will keep reporting bugs haha
Edit: That's waaaay too many emoticons. Oooops someone is a little high aren't they?
PS: I have attached my PNG of the icon I used for this bugger waaaaaay back....it's less generic and feel free to take it and abuse it and do as you please.
cmlx said:
Good news
Bug report, every time I open this program, this dialog pops up, after click OK, this program works well.
PS, aapt.exe is in the same dir with ApkSpy
Click to expand...
Click to collapse
Yes, I know of this one (and I've specifically wrote about it in the OP), it is NOT related to AAPT executable but to the way ADB is acting (sorry, out of my hands... :angel:
Explanation
The error comes from the application when trying to query the "ro.build.id" property via adb ('ADB shell getprop "ro.build.id" ') command.
I've came across this one but cannot determine the exact situation it is happening (as it can occur when first launching of the app, but after the app is loaded, clicking on refresh does not show this error)...
[ I've tried it on with the (only) two devices I own (1st dev. is stock (only the kernel is changed) 4.4.2 Nexus 4, 2nd dev. is S2-i9100 with customized RR ROM)and it seems to happen ONLY on the S2...]
It looks that in times, the getprop is being executed before the whole "build.prop" is being processed by ADB (This one I cannot control since it is happening on the ADB shell side [running on the device] -- unless MAYBE doing some [UGLY] delay after first initialization of ADB, which is, by far NOT best practice of process handling according to the literature)...
CyberianIce said:
I got this errors:
1:
2:
Error in property: [email protected]@usrdata
Click to expand...
Click to collapse
Which came first, the "SpkSpy spy stopped working" or the "Error in property" (if anyways related)?
Was it on the same run or two different runs?
As of the 1st one:
I do not have enough information from your post to check it up...
I'll post a new version which shows the exception details
As of the 2nd one:
Can you send me a copy of your /system/build.prop (so i'll be able to dig trough it and check it)?
It looks like my name-value splitter character exist as part of a given value in your build.prop .
Wooow, Long one! But it is nice to know people are using (trying) it!
Jarmezrocks said:
Hey dude,
I am not sure what you are doing wrong on your PC but it's certainly not the app as it works perfectly fine on my computer? Out of interest and for the sake or helping the new dev I thought I would raise a few points just to eliminate any finger pointing. There's a wishy-washy area when it comes to building/hacking things that were originally someone elses work...so yeah one can easily make great improvements yet open the door to bugs at the same time too. Anyway...thought I'd ask this:
Does aapt sit on your path? I know you said it is in the same directory, however just like a batch script in Windows it needs to "CD" or change directories to the %~dp0 if it is to understand what an executable is that happens to be sitting in the same directory as it's self. So this is is kinda directed at the new dev now. What I think is happening is that aapt is assumed to be in the system path when quite often it is not (i.e. those on XDA who have not yet played with the Android SDK properly). Put simply unless the application knows it is in the same directory as your executable it won't at all understand what aapt is. Does that make sense?
Click to expand...
Click to collapse
Hi
As I've replied to @clmx, This error is not related to AAPT (either executable [location or whatever] or results), but to the ADB command being used...
Jarmezrocks said:
@dmagician , I would make sure that the apkspy app can do a check (even if it is a string search for the first few lines returned from aapt.exe), a simple if statement before throwing that error ....actually it would likely be an 'if not' statement. I don't have any of the code in front of me atm but I can help you out if you like? I was hacking this app myself sometime ago when ido first released it just using reshacker.
Click to expand...
Click to collapse
Sorry I did not understand... Check for what?
Jarmezrocks said:
Note: If you are stuck and don't have source code you technically could write a full AutoIT wrapper for this app that could do all the checks and more and then bundle everything up into the one exe still. Check out the newer WinAPI stuff for AutoIT and in particular "Run binary" (yes that's correct you can just about run anything repackaged now and not need to deploy the original exe's or even libraries....they can all be stream fed to AutoIT @Compile time and need not be typically "installed" like you used to have to do. Anyway...I am waffling on shoot me a PM man.
Click to expand...
Click to collapse
I do not need the Auto-IT to wrap these files (although I am using it for other automation in windows), as I can do it right in the C# code (on one of my early versions these files was embedded...)
BTW, I know there are some antiviruses out in the wild that do not like the embedded executables -- but it can be done -- and probably will save some time to anyone using this app...
If it will be required / asked, I'll embed the 4 binaries (AAPT.EXE, ADB.EXE, and two DLL's AdbWinApi.dll and AdbWinUsbApi.dll [I'm not sure both are required]) needed by the application.
Jarmezrocks said:
@cmlx, to overcome your ApkSpy woes, and until dmagician can put his finger on what the cause is or what ido did when building it ages ago.....then you will firstly need to be patient (props to dmagician to figuring sh!t out so far) but till then where ever you have dumped the ApkSpy and aapt.exe on your system; just copy the address and put it on your system path. To do this 1) right click on My Computer or Computer if you are on Win 7 or 8. 2) Choose properties. 3) Advanced System settings and then at the bottom of tab you will see 'Environment Variables', click it and you will see some "User" and "System" options. Depending on your User access rights on the system you are running on (hopefully you are running as Admin surely?) then you can choose to edit your main system path or create a new variable in your user settings called 'path' Note User variables are always postfix to system variables but should always work anyhow.
Disclaimer: cmlx, if however you have already got an aapt.exe already existing on your system path but it is dodgy then you have to ensure that the good aapt.exe in your app directory is placed on path BEFORE the dodgy one....just sayin. Cause your system searches till it finds what it wants and then doesn't search anymore. Simple but can stuff people up quite often....and likely your case. Nowdays we tend to work from the known application location and not from a "Global environment path" when we know that there are going to be conflicts...and I can assure you that aapt is possibly the worst and most modified binary out there LOL. Hence this is also a note to the dev to ensure that ApkSpy reads from the current directory.....or like I am suggesting, wrap aapt up in the main application as well and that way there is no confusion EVER.
Click to expand...
Click to collapse
The application IS searching for AAPT and ADB executables; The order is
Application directory (where ApkSpy.exe resides)
PATH environment variable
Jarmezrocks said:
OK....so um the red boxes should explain everything. A picture says a thousand words (and yeah I needed at least 1 picture for this god damned long arsed post - sry). Um why in gods name would you remove the minimise and expand buttons? WTF?
Click to expand...
Click to collapse
Mostly I like it this way, otherwise - No specific reason...
It will be back in the next version...
Jarmezrocks said:
Anyway... it works but errrm yeah it doesn't wrap the text anymore? and it cuts the words off lol.
Click to expand...
Click to collapse
This Tab was NOT changed by me in any way... To be honest, I've thought of removing it completely -- But -- out of respect to Ido's work -- I've left it in.
I assume it is not wrapping due to Font size changed by me globally...
I'm seriously giving it second thoughts -- if it should stay at all (It was originally meant for batch rename of multiple APK's... I haven't used it even once...)...
I'm Really, REALLY, think of removing it completely (unless someone is / will be using it -- then I'll fix it all)...
Jarmezrocks said:
Other than that....I only really have one suggestion and it isn't even really a suggestion as I have kind of already made it so I can just give it to you if you want it? And that is that most people (well I can't say most as I am not speaking for everyone) tend not to like how apps take over their system. This isn't your fault at all in anyway as the first dev thought it was a good idea back then.....and back then hardly anything in Windows knew what a freakin apk was so it was a GOOD thing.....However now, every man and his dog wants to steel .apk extension for himself. I myself tend to be all over the shop with apks so I tend not to want to have any particular Windows app take it away from my control. I use WinZip as the main app for simple double click open as I want to see the contents of apks without needing to decompile them (great for theming) however I have apk shell extensions displaying the apks main icon to explorer, so if I set WinZip as default I get a nice lumping hunk of gold turd/box running rampet all over my Windoze bro ......so if you like I can show you my code that allows me to have default apps for specific tasks without interfering with anyones existing sh!t It looks neat too as you can right click any apk and just choose from a dropdown list what particular app you want at the time. If one has the need to use more apps then they need only put those apps in a list. There is nothing worse than double clicking an apk to find that Bluestacks or some other rubbish Windoze crApp has taken offf with your apk.
Click to expand...
Click to collapse
The application is NOT taking over anything, Unless you've clicked the asterisk ("*") button on the System Tab...
Was it registered for you without clicking this button?
If so, I'll recheck the code (may be it's some residue from the original code).
BTW
As the previous part of the answer I've wrote -- this one was left in as of respect to @ido's work...
2nd BTW
I'd like to see that explorer extension (and [preferable] the code of it - if you are willing to share it) you ware writing about...
Jarmezrocks said:
Lastly I thought I'd ask, Why no config file? Why store everything in memory? I know it's only small....but seeking for things everytime it is executed is a pain in the arse and not good practice. At the very least if you have no idea how to make an exe totally portable then you could reference a config file in the same directory....Or do as most do and write entries to the registry all neat and tucked away. If we get paranoid about "portable-ness" then we write to temporary space in the registry and make sure we clean up upon closing and/or inspect at runtime. simple!
Click to expand...
Click to collapse
Yep, I've thought of it... But... I was thinking, that (at least) everyone is as geeky as me dauuh , and the most are setting the path correctly...
It'll be added in next version (I hope... TIME, TIME!!!! :cyclops...
Jarmezrocks said:
I have plenty of AutoIT scripts that do exactly that too, so if you are stuck for ideas let me know. Anyway I have rambled enough, good luck and I will keep reporting bugs haha
Click to expand...
Click to collapse
I prefer writing my own code (sorry, I'm a developer in heart and soul...) then using automation like Auto-IT...
Jarmezrocks said:
Edit: That's waaaay too many emoticons. Oooops someone is a little high aren't they?
Click to expand...
Click to collapse
Jarmezrocks said:
PS: I have attached my PNG of the icon I used for this bugger waaaaaay back....it's less generic and feel free to take it and abuse it and do as you please.
Click to expand...
Click to collapse
(@Jarmezrocks please see my PM to you.)
PHEW...
Long Answer, BUT HEY, I'm not the only one writing longies... :angel: (and i like referencing each and every part separately)...
dmagician said:
PHEW...
Long Answer, BUT HEY, I'm not the only one writing longies... :angel: (and i like referencing each and every part separately)...
Click to expand...
Click to collapse
Ahh yes. I write long messages sometimes when my medication has kicked in and I am high....not my fault I kinda need to get all the info out of my head in one go while I am awake.....or else there would just be zeds on the response zzzzzzzzzzzzzzzzzzzzzz lol :laugh: (ref narcolepsy).
I commend you on your efforts at responding to such gibberish and making good sense of it! :highfive:
I have responded to your PM accordingly, and hopefully covered all you need? I have attached all info and sources etc.....well most of it...actually a fair bit of it you will have to workout your self but that is part the fun. Shoot me any questions if you need to...although I have a feeling that you will have mostly all of it covered as you are streets ahead of my knowledge already. I may have misjudged a little in my previous post (although hopefully not to make you feel any less than you actually are? please excuse me if I had said anything that may offended - being naive or what ever....you ARE definitely on the right track). As for the middle menu....I think you could easily remove it and not offend the original dev. It wasn't being used as you mention...and I think it could make way for more/better functionality don't you think? (discuss). However I would ensure all the things I mentioned in my PM first before going too deep and releasing on here.
Good move on bringing the buttons back. They were functional. But I DO like the single button close GUI myself on just about everything else....It looks clean. We have similar taste in that regard. It just isn't functional for me to pressing the task notification desktop link everytime I want to minimise the app LOL.
The rest I we can discuss via PM, this is pretty much only posted here as an open area for other forum members to provide input and opinion (or complaint....like how often it usually is, eh?).
CyberianIce said:
I got this errors:
1:
2:
Error in property: [email protected]@usrdata
Click to expand...
Click to collapse
I'd got the same error!
For me it helped to copy two files to the install dir
"adb.exe" and "AdbWinApi.dll"
Both are installed with the well known MyPhoneExplorer into "Program Files\MyPhoneExplorer\DLL"
Hope it helps!
Feature Request
I use this tool for testing new APK builds on a project I am working on it. It allows me to quickly verify the version number and push to the device. However, since I am usually installing another version of an existing installed APK, I must manually uninstall before using APKSPY. Would it be possible to add a check box that would uninstall any previous versions? It would be really helpful.
Nevermind - I didn't fully read the message presented when it fail. It say uninstall/update and it allows the installation. HOWEVER, that brings up a question... Does it uninstall or does it update? There is a difference as you know.
Thanks,
Jonathan
Hi, I try to run this on Mac via Wineskin Winery, but no luck. Do I need something like .Net, or something else to run ApkSpy?
Thank you.
Ja_som said:
Hi, I try to run this on Mac via Wineskin Winery, but no luck. Do I need something like .Net, or something else to run ApkSpy?
Thank you.
Click to expand...
Click to collapse
The only requirement is the Microsoft .Net 4.
(I'll add this to OP)
jmo said:
I use this tool for testing new APK builds on a project I am working on it. It allows me to quickly verify the version number and push to the device. However, since I am usually installing another version of an existing installed APK, I must manually uninstall before using APKSPY. Would it be possible to add a check box that would uninstall any previous versions? It would be really helpful.
Nevermind - I didn't fully read the message presented when it fail. It say uninstall/update and it allows the installation. HOWEVER, that brings up a question... Does it uninstall or does it update? There is a difference as you know.
Thanks,
Jonathan
Click to expand...
Click to collapse
Yes I know there is difference between the two (update vs uninstall and install again).
It is updating the application (like using "adb install -r apk_file_name.apk"), not doing remove and install
Removed unneeded tabs (System, Batch Rename, Log)
Click to expand...
Click to collapse
The unneeded Batch Rename tab was the only tab I needed really. :laugh: Luckily I found Ido's original version. It's ideal for renaming all those apk's I downloaded and still have the package name when I back them up to my PC.
I have an Asus Memo Pad 10 and an Asus Memo Pad 7 and neither are recognised by APKSpy. Not that it's a problem as I have no problem copying to and from them with Windows Exploder or Total Commander.
Other than that, it's been a handy little app for this tablet/smartphone virgin newbie.
Martin.
wolrik said:
The unneeded Batch Rename tab was the only tab I needed really. :laugh: Luckily I found Ido's original version. It's ideal for renaming all those apk's I downloaded and still have the package name when I back them up to my PC.
I have an Asus Memo Pad 10 and an Asus Memo Pad 7 and neither are recognised by APKSpy. Not that it's a problem as I have no problem copying to and from them with Windows Exploder or Total Commander.
Other than that, it's been a handy little app for this tablet/smartphone virgin newbie.
Martin.
Click to expand...
Click to collapse
Hello.
1st:
I can -- if requested - re-add the Batch rename.
2nd:
I don't know why these two devices are not being recognized -- unless not being recognized by ADB itself -- since I'm spawning devices by parsing the resulting text of "ADB devices" command, So unless being unrecognized by ADB, there should be NO PROBLEM detecting ANY android device with ADB on...
if you have any exception messages thrown by the application, please post them here.
dmagician said:
Hello.
1st:
I can -- if requested - re-add the Batch rename.
2nd:
I don't know why these two devices are not being recognized -- unless not being recognized by ADB itself -- since I'm spawning devices by parsing the resulting text of "ADB devices" command, So unless being unrecognized by ADB, there should be NO PROBLEM detecting ANY android device with ADB on...
if you have any exception messages thrown by the application, please post them here.
Click to expand...
Click to collapse
No need to re-add the tab just for me, but thanks for the offer. As I get to know my way around Android I'll probably need such things less and less.
Sorry, but I know nothing about ADB other than APKSpy needing it. As you can see from the attached pic, the Asus is recognised by Total Commander
Martin.
Hi dmagician,
Nice work, and a shout-out to Ido who originally created it.
I have a feature request:
Could you add the option to remove certain permission(s) and save the modified APK file?
There are many apps which I feel allow themselves way too much permissions, and this option could be very useful to tame them apps.
One more thing:
I noticed that APKSpy v1.8.2 doesn't work with the latest version of AAPT.exe (1432KB), from the Android SDK r24.
So I had to use a previous version of AAPT.exe (833KB), which worked.
Thanks,
Eric
Hey does anybody know where the name of the apk is in the XML files inside the apk?
Code:
*** Disclaimer
As usual, I am not responsible for thermonuclear war or other apocalyptic futures.
TL;DR: If you break your device with this project, it's not my fault (although I will of course be willing to help you in your troubles!!).
Introduction
Have you ever wanted to use your Android device as a fully-fledged desktop Linux box? Now you can, with Tuxoid!
A year or two ago, I discovered the Linux-on-Android project. (http://forum.xda-developers.com/showthread.php?t=1585009) I was fascinated by the possibility of running Linux on top of Android and using a desktop environment. However, I was slightly disappointed by the lack of some features, as well as a lack of development over the time of the project's existence. Thus I embarked upon an epic quest (well maybe not quite that dramatic) to build my own version from the ground up, basing it upon the ideas explored by Linux-on-Android.
After some on and off hacking on my OnePlus One, I now have some very early working code.
Below is a video demonstration of the current state of Tuxoid, demonstrating a few of its features.
Here is a list of some of these features:
- The big one: fast and high quality display system
- Native keyboard and mouse support (automatically disables Android's built-in system)
- Audio support. Audio from the desktop environment is piped into Android's audio system, so you can use your device's speakers, headphones or bluetooth etc
UPDATE: First builds!
I've built the first publicly available versions of the project. Before you get excited, I should warn you that they are in an unstable state. You can grab the APKs in the Downloads section of this project, as well as on the Releases page of the project on GitHub. These builds are not for n00bs! If you're still determined to give them a try, here are the instructions:
Requirements
An Android device running 4.1 or newer (it will be availabe for older versions in the future, but for know only Lollipop is supported) Older versions now supported!
Root with SuperSU for managing permissions. I will not explain this here, as there are already hundreds of guides available. If you don't know how to root your device, this project (at least in these early stages) is not for you.
A reasonable amount of internal storage (at least 1-2 GB free)
A stable internet connection. Make sure you're using WiFi for best results.
A mouse and keyboard to control the desktop environment. You should be able to use wired ones (via an OTG adapter) or wireless via bluetooth. As long as Android recognizes it, you should be good to go.
This is not a requirement, but you won't be able to do much without it (for now): knowledge of the Linux command line and preferably how to use the pacman package manager for Arch Linux, as that is the distro upon which Tuxoid is based (more distros will be available down the line!)
Setup and installation
Once your device is rooted, open up the SuperSU app and go to the Settings tab. Find an option labelled "Mount namespace separation" and ensure it is UNchecked. (Make sure to reboot before continuing if you had to do this)
Download and install the APK for Tuxoid. Again, if you don't know how to do this, you shouldn't be attempting to install an early build Tuxoid...
Open the Tuxoid app and tap the gear in the actionbar to go to the settings menu. There are a few options you can tweak here, but the main one you should be interested in right now is 'Disk image size'. Select a size that suits the amount of space you have free on your internal storage. I would recommend 4GB (the default) to allow room for installation of your own packages later. If you have less space free on your internal storage than you select here, the setup process will fail.
Go back to the main screen of the app and ensure you have a stable internet connection. Now connect your keyboard and mouse (you must connect them before booting Tuxoid up every time). Then, press 'Start' to begin the setup process. This will probably take a while, so just leave your device down for a while and check up on it every once and a while.
Eventually, if all went well, you should see a screen with a grey background and an xterm window. Feel free to run some commands. To start, I'd recommend installing the Chromium browser (open source version Google Chrome). To do this, run 'sudo pacman -S chromium' (without quotes). The password is the same as your username. Once installed, run 'chromium' to start the browser. For those who are interested, the window manager installed by default is Openbox. If you want to install some more packages, the list of available ones in Arch Linux for ARM devices is available here: http://archlinuxarm.org/packages If you weren't able to get up and running (i.e. no screen with a cursor and no xterm), you can try some of the steps described in Troubleshooting & Tips.
When you're finished playing around, follow the steps below to ensure clean shutdown of Tuxoid. If you want to boot up again, you can just open up the app at any time and tap on the start button. Tuxoid will use your existing system image.
Shutdown procedure
When you're done, simply press the back key on your device to close the GUI and press the stop button to shutdown Tuxoid. After a few seconds, the log will show "SHUTDOWN!", meaning the shutdown procedure was completed successfully.
Troubleshooting & Tips
If Tuxoid failed to boot during the initial setup, you can retry by first removing files in the 'droidtop' folder on your internal storage (usually 'system.img' and 'arch.tar.gz') and then pressing 'Start' again in the app.
If your mouse and keyboard aren't working in Tuxoid, ensure that they were connected to your device BEFORE you pressed the start button and make sure they were detected by Android. If they weren't detected by Android itself the they definitely won't work with Tuxoid.
If you something goes wrong at any stage while using Tuxoid, please press the 'Send log' button in the app to send me a copy of the log shown on the main screen.
If the app crashes, a dialog will pop up asking you to send a report. Please do this as it makes it much easier for me to fix bugs!
If you have any feedback and suggestions, feel free to post them here in the forums! You can also submit issues on the GitHub project (although this is really more orientated towards developers)
If you are a developer and want to get involved in the project, you can post here in the forums and/or submit pull requests on GitHub.
Source code
I've published all of the source code for the app to GitHub (http://github.com/jackos2500/tuxoid) Feel free to fork and make changes, and, even better, submit pull requests to move the project forward!
Finally, I would like to say thanks to the guys over at Linux-on-Android for their great work, without which the idea for this project would never have existed!
XDA:DevDB Information
Tuxoid, App for all devices (see above for details)
Contributors
jackos2500
Version Information
Status: Testing
Created 2015-06-13
Last Updated 2015-06-14
Reserved
Changelog
v0.1.1
Adds compatibility for Android versions as far back as 4.1 (API level 16).
Bug fixes:
screen resolution could be detected incorrectly
'setenforce' could fail to execute due to its lack of existence on older platform versions
v0.1
Initial public release.
Reserved
Its really interesting to hear about linux on android
shahzu3 said:
Its really interesting to hear about linux on android
Click to expand...
Click to collapse
Yup! I think I'll put out a build later with some instructions so that people can try it for themselves.
Mm
shahzu3 said:
Mm
Click to expand...
Click to collapse
Well I've pushed out the first public build. Give it a try and tell me what you think!
Hi. Your project sounds great ??
Is really necessary to have so internal space or could it be possible one day to have the whole stuff on the external sd.??
That is just amazing, thanks for your work, a tablet running this would be really nice... I'm going to try it out.
Hello! This looks very promising but I can't find any download link. Is it missing?
Edit: My phone just didn't load the page fully, the download section is on the top.
DirkStorck said:
Hi. Your project sounds great
Is really necessary to have so internal space or could it be possible one day to have the whole stuff on the external sd.?
Click to expand...
Click to collapse
Good point! I'll see if I can do something about that sometime soon. Unfortunately if the chroot environment is not stored in a disk image the filesystem it is stored on must support Unix permissions, so no FAT32 formatted sdcards without disk images. FAT32 also limits file size to 4GB, so that would be the max size for a disk image there. I'll probably add a way of optionally adding an extra partition to your SD to get around this at some stage.
WideBRs said:
That is just amazing, thanks for your work, a tablet running this would be really nice... I'm going to try it out.
Click to expand...
Click to collapse
Cool, tell me what you think when you give it a go!
jackos2500 said:
Good point! I'll see if I can do something about that sometime soon. Unfortunately if the chroot environment is not stored in a disk image the filesystem it is stored on must support Unix permissions, so no FAT32 formatted sdcards without disk images. FAT32 also limits file size to 4GB, so that would be the max size for a disk image there. I'll probably add a way of optionally adding an extra partition to your SD to get around this at some stage.
Cool, tell me what you think when you give it a go!
Click to expand...
Click to collapse
I have been using Linux Deploy on my tablet and it worked quite well. They have the environment as an image on the internal or external sd card. I think 4GB is a enough for a Linux system. For those who want more would have to format the external as ext4.
DirkStorck said:
I have been using Linux Deploy on my tablet and it worked quite well. They have the environment as an image on the internal or external sd card. I think 4GB is a enough for a Linux system. For those who want more would have to format the external as ext4.
Click to expand...
Click to collapse
I've pushed a new release with support for devices running Android 4.1 and above. I think I'm going to start working on improving the user-friendliness of the project tomorrow. This will probably include improving the UI and setup process, as well as better error handling. Once that code is in place I won't have to refactor any new features I add to the new UI, so it makes sense to do it first. It will take a while, and whenever it's done, I'll probably start working on some of those new features.
Hi,
Could you tell me if:
a) my phones built-in keyboard will work?
b) if there's an option to use the touch screen to control the mouse?
Thanks
moodroid said:
Hi,
Could you tell me if:
a) my phones built-in keyboard will work?
b) if there's an option to use the touch screen to control the mouse?
Thanks
Click to expand...
Click to collapse
Right now, no. Both of these are definitely a high priority though.
jackos2500 said:
Right now, no. Both of these are definitely a high priority though.
Click to expand...
Click to collapse
Excellent, thanks. I'll keep an eye on this...
Can i decompile and compile apk with this Linux for Android? I havent pc
this is really amazing, as it is very useful for tablets, at least for my tab s 10.5 inch, keep it up!
Currently using Xserver Xsdl, with the pain of slow refresh rate and input interrupt.
Thank you for this effort!
Hello,
So far, I had these issues before it worked, otherwise its awesome, the only way to render x server on android smoothly and no input latency without using direct (kernel) framebuffer:
1)Latest arch armv7hf use xorg-server and xf86-input-evdev compiled for/by version 1.18.x , had to recompile 1.17 from source since your module (the source code isnt released in your github :/, guess you forgot) is compiled for ABI module 20, currently 23.
2) High cpu usage, probably implement refresh rate limitation on the app side for displaying the shared memory framebuffer, though having the source code for the module would really help, guess its a modified dummy.so (?) to copy framebuffer to shm? Anyways ill try to workaround the issue using a compositor.
Thats all! working perfectly... If anyone need the compiled 1.17 versions of xorg-server and evdev, just use ABS or pm me.
Thanks!
EDIT: I think it would be better to turn this into X server framebuffer viewer app, and combine it with Linux deploy (+ 'custom scripts' option is already implemented in Linux Deploy, useful for evdev and xorg config) for more linux flavours
apparently, it seems that you have copied droidtop project without mentioning it (license: MIT) : https://code.google.com/p/droidtop/
which has been archived now with no public access
Hello guys,
I have been searching for answers to some of the tech stuff, but couldn't find them.
Here are some of those questions. Hope some of you would have answers to these. Thanks in advance!
ANDROID
1. How to share files between multi-users on Android 11?
Before Android 11, it was possible to save files inside the Android/ obb folder, and these files were visible for all users on the device. In Android 11, this is no longer working as the 'obb' folder appears to be exclusive to each user.
I know this is possible via USB OTG or a cloud service, but is there a solution without these?
2. How to copy/ backup game data for non-rooted devices?
Helium Backup doesn't seem to work. I have played a game for long on my Mediapad, and I would like to copy that game to my phone. Unfortunately, my Mediapad is not rooted and losing all that game progress has become a nightmare. I have written to the app developer to provide some sort of backup using either Google Play Games or social media integration like Facebook/ Twitter, but haven't received any response.
3. How to force apps (esp. file managers & gallery apps) to use in-app media viewer without changing system default.
For example, I may use the stock gallery app as default for viewing media. But if I am using another gallery app or a file manager that is capable of viewing media files using its own media viewer, I would rather want it use it than open the default app. Is there a way to do it?
4. Replace stock file manager (a system app) with another app from Google Play Store or other sources. Is this possible?
I am not asking how to convert a user app into system app. I know that part. I tried replacing the apk file of the stock file manager with a 3rd party apk, even renamed it, but it didn't work.
5. Extract a system app from one device and install it on another device without root. Is this possible?
I have tried it, but apk installation fails. For example, Samsung Gallery app on OnePlus phones.
iOS
1. How to install .ipa (iPhone app) on an iPhone (not jail-broken) without a laptop (iTunes)?
2. Is it possible to have SFTP server for iPhone?
All Operating Systems
1. How to provide LAN only access for non-rooted devices as well as in Windows & iOS?
For rooted devices, we have apps like AFWall+ that can do it. But is there a way to do it for devices without root, as well as for Windows and iOS?
For non-rooted devices, we have apps like Netguard that support 'Allow LAN access' whilst blocking internet access.
Are there any alternatives and solutions for other platforms?
2. How safe is it to enter login credentials in an app to allow it access to network drives?
I use several apps (on various platforms) to connect to my laptop over SMB. This requires me to provide the app with my Windows Login Credentials, which is a Microsoft account. Am I risking my account by providing this info to the app? Is it safe to enter login credentials of cloud services in file manager apps?
Just bumping this thread as it seems to have been lost/ unnoticed.
@Ultramanoid can you answer some of these?
Sridhar Ananthanarayanan said:
@Ultramanoid can you answer some of these?
Click to expand...
Click to collapse
Can't help much, sorry. As to Android, some notes :
1. Never have used an OEM / Google's version of Android, or anything other than rooted single-user systems.
2. In addition to the previous answer, I'm not a gamer.
3. I usually don't ever set defaults with some rare exceptions, so I am always given a choice of what I want to use to handle a file. It may vary depending on many things; I may want to edit an SVG file as text, or view it as an image, for instance. There are applications / services that will intercept intents to allow you to do this sort of thing as well, but I can't recommend a specific one, never use them myself.
4. Possible, but will break Android as by now the system requires it as a file picker in many instances without recognizing alternatives and developers of most applications do expect it as well and their services will not work without it. Don't do it. With recent Android storage changes, including the scoped storage debacle, this is not a viable option anymore.
5. Depends, but not likely as a general rule, specially for OEM garbage, which relies on their own proprietary modifications of Android, their libraries, frameworks, et al. You'd have to carry those over to the destination too, which may not even be possible. Use OEM-independent and not Google Services reliant applications. ( Edit : you'll find some of those applications built to install on all devices here on XDA by single developers, "SONY camera for all devices" and that sort of thing, not recommended anyway, not well supported or long-lived experiments. )
Ultramanoid said:
Can't help much, sorry. As to Android, some notes :
1. Never have used an OEM / Google's version of Android, or anything other than rooted single-user systems.
2. In addition to the previous answer, I'm not a gamer.
3. I usually don't ever set defaults with some rare exceptions, so I am always given a choice of what I want to use to handle a file. It may vary depending on many things; I may want to edit an SVG file as text, or view it as an image, for instance. There are applications / services that will intercept intents to allow you to do this sort of thing as well, but I can't recommend a specific one, never use them myself.
4. Possible, but will break Android as by now the system requires it as a file picker in many instances without recognizing alternatives and developers of most applications do expect it as well and their services will not work without it. Don't do it. With recent Android storage changes, including the scoped storage debacle, this is not a viable option anymore.
5. Depends, but not likely as a general rule, specially for OEM garbage, which relies on their own proprietary modifications of Android, their libraries, frameworks, et al. You'd have to carry those over to the destination too, which may not even be possible. Use OEM-independent and not Google Services reliant applications. ( Edit : you'll find some of those applications built to install on all devices here on XDA by single developers, "SONY camera for all devices" and that sort of thing, not recommended anyway, not well supported or long-lived experiments. )
Click to expand...
Click to collapse
Thanks very much. But I wish you answered the last 2 questions as well.
If time permits, would you be interested in telling us how you use your phone? I mean which device, which OS and what apps you use. I would like to give that a try (on a spare device) and see if it is possible for me to live without Google.
Sridhar Ananthanarayanan said:
Thanks very much. But I wish you answered the last 2 questions as well.
If time permits, would you be interested in telling us how you use your phone? I mean which device, which OS and what apps you use. I would like to give that a try (on a spare device) and see if it is possible for me to live without Google.
Click to expand...
Click to collapse
Didn't answer because it won't be helpful.
As to the 1st, I don't use LAN, and I don't keep data in any device or computer unless in use. External independent encrypted storage to be used wherever, whenever, independent of device, cables if needed.
As to the second, it's a matter of common sense, being informed of vulnerabilities and aware of reputation, and trust. Would you trust Chrome or Mozilla with data if you're online banking ? Seems reasonable -- but be aware of major vulnerabilities that may be going on. Would you trust an application released yesterday by a single developer for the same ? Probably not a good idea.
Finally, I doubt what I use and how I use it would be acceptable for you, or most people. In essence you could : Install latest firmware, wipe device, install latest security patched Lineage build for it, remove vendor / Lineage applications, get full root, remove anything you don't need or use which could have vulnerabilities; frameworks, libraries, binaries, etc ( Bluetooth, SMS, Android system-wide downloader, system-wide WebView, NFC, and on and on .. ), install your own binaries, fonts, hosts file, and applications where appropriate ( /bin /etc et al ), install Termux and all Linux packages required for your use, everything open source whenever possible, and stay away from any Google services / Play / applications with ANY trackers, analytics, data mining or even crash report capabilities; zero tolerance. Internet permission only for a secure web browser -- and terminal if / when needed. Half of what I do or use goes through terminal to be honest. In short, for me an Android device is a full Linux laptop replacement with added perks : Always on and on me, camera, GPS, pedometer, unlimited LTE data, and emergency calls for medics / police. ( Edit : And Japanese EEW alarm of course ! Only notification I use. We learned our lesson well in 2011. )
You can use ApkExport to extract any apk including system apks. I've transferred apks between other devices devices with it.
Never had need of doing that though with a system apk.