This is some hobby project i want to accomplish with, i have decent experience in programming java. But after quite a lot searching around and asking professors and anyone with experience in android development i got no clear vision of how this is accomplishable. The thing is, i want to develop an application that runs for a given amount of time(there´s a timer the user sets), during this given time certain applications will be blocked(or rather killed, or intents changed so they won´t even start to run). This selection will be done from a list given of third party applications installed.
As mentioned, ive searched everywhere i can, and the only leads i could ever find was the following:
1. Have continous check which kills the given application if it detects the specific applications running and will kill it. Downfall of this will be cpu-usage, optimalization and battery use. And also the device has to be rooted.
2. Have an alternative launcher, somehow this should help me a bit on the way to accomplish my goal. But here i sit thinking: Will i need to develop my own launcher to be able to succeed?
Nothing pointed me in any direction whether there are some native methods or similar in the android that perform similar tasks and how to implement it at all. Those who are saying there are plenty of applications our there similarly: No, they give you choices like block apps with a password and similar which is not what i´m after. I need some application that blocks it for the given time it´s set to(even though it is possible to go on your own in task manager and kill this application i want to develop, but that is out of the scope for now). This is to increase productivity without reaching for your cellphone all the time(yes, it might sound silly, but i´m quite sure it will help.
Any help is greatly appreciated as i´ve researched for over a month without any success.
Bring up your activity no matter which app starts. Make it a transparent activity and kill it as soon as it starts.
Is it possible to create an application that would hook all api calls to windows and be able to accept or deny the call? How trivial would this be?
All calls, for all apps? Very damn hard. You'd basically need to shim the entire standard libraries. The shims could probably be programmatically generated, but you'd need to write the program to create them. Then you'd need Admin access to install them, and then...
Why don't you explain what you're trying to do? This is a very complicated thing to attempt, and it might not be the right approach at all,
GoodDayToDie said:
All calls, for all apps? Very damn hard. You'd basically need to shim the entire standard libraries. The shims could probably be programmatically generated, but you'd need to write the program to create them. Then you'd need Admin access to install them, and then...
Why don't you explain what you're trying to do? This is a very complicated thing to attempt, and it might not be the right approach at all,
Click to expand...
Click to collapse
Due to recent program vulnerabilities *cough cough* IE exploit, I want to create a program to minimize and effectively stop the exploits, by blocking reading api calls from programs that have the vulnerability and determining if the call should be made or not.
There's already tools like EMET, which blocked that (and may other) exploits.
Have you ever looked at the output generated by procmon on a typical Windows application? Even for just the subset of system calls that it monitors, the log scrolls too fast to read, much less to make a decision about each call. Something as simple as opening a single static HTML page in IE would require an incredible number of clicks. Your typical modern page, which has dozens of separately-requested elements, generates considerable traffic to log files and cookies and so forth, and may contain rich content requiring a bunch of additional functions... Yeah, not practical at all.
GoodDayToDie said:
There's already tools like EMET, which blocked that (and may other) exploits.
Have you ever looked at the output generated by procmon on a typical Windows application? Even for just the subset of system calls that it monitors, the log scrolls too fast to read, much less to make a decision about each call. Something as simple as opening a single static HTML page in IE would require an incredible number of clicks. Your typical modern page, which has dozens of separately-requested elements, generates considerable traffic to log files and cookies and so forth, and may contain rich content requiring a bunch of additional functions... Yeah, not practical at all.
Click to expand...
Click to collapse
For educational purposes and further knowledge could you show me what I would have to do to hook one api call from a process? it does not have to be a global hook.
There's a handful of possible approaches.
If you *wanted* to do it globally, and didn't mind doing so only at the kernel syscall layer (meaning any purely user-space code wouldn't get caught, but since anything that can go between processes in any practical way involves the kernel anyhow...) you could create a driver that filters the relevant system calls. Filtering the entire system call interrupt at one place is possible if you can mess with the relevant interrupt service routine, but I believe that's protected by PatchGuard. There may be some all-in-one place anyhow, but it would be tricky. Anyhow, this is how tools such as Process Monitor (which only handles a relative handful of system calls) work.
If you want to modify the behavior of a bunch of programs, you could create modified versions of the system libraries, and put them where the programs would load them (usually the application directory would work, but sometimes you would need to replace the system copy). This approach is a lot of work, though not completely impractical; you simply need to shim all the exported functions (or at least, the ones you care about) with a version that filters the call before passing it through to the "real" version, but you would need to cover all the exported functions without breaking their ABI. Doable, but a lot of work.
If you only want to get one function, the easiest way would be to re-write all calls to that function in the process memory such that they go to your filter instead. This is how the Detours library (http://research.microsoft.com/en-us/projects/detours/) works; you can find code samples of using it online. I believe that is also how Microsoft's application compatibility shims work. There are registry keys which will cause a given program to be loaded in a debugger (which can be mostly non-interactive, and just make this change for you) or I *think* there's a way to specify an arbitrary DLL that a given program must load (and run its DllMain function) when it starts up too, which would also do the trick.
Bear in mind that the second and third methods can be bypassed by an attacker who knows what you're doing; the attacker just (re-)overwrites the function tables to point at the real versions of the APIs, or alternatively makes the relevant system calls directly (Win32 programs basically never do this, instead letting the Win32 subsystem translate their Win32 function calls in NT system calls and invoking the wrapped syscall, but there's nothing *stopping* them). The first approach can't be bypassed by an attacker with less than Admin privileges (assuming you did it right; I can think of a couple of potential gotchas you'd need to avoid) but you would need Admin yourself in order to install that driver in the first place, and if you want to *interactively* filter the API calls you would need the entire interaction path including the UI to protected against tampering by less-privileged processes.
With all that said, a real Mandatory Access Control that gives finer-grained control than Windows' Mandatory Integrity Control would be a really cool thing (something more like SELinux or AppArmor). It would probably be more effort on NT than on Linux though, due to NT not (so far as I know) having any equivalent of http://en.wikipedia.org/wiki/Linux_Security_Modules (a good place to start reading about the topic).
GoodDayToDie said:
There's a handful of possible approaches.
If you *wanted* to do it globally, and didn't mind doing so only at the kernel syscall layer (meaning any purely user-space code wouldn't get caught, but since anything that can go between processes in any practical way involves the kernel anyhow...) you could create a driver that filters the relevant system calls. Filtering the entire system call interrupt at one place is possible if you can mess with the relevant interrupt service routine, but I believe that's protected by PatchGuard. There may be some all-in-one place anyhow, but it would be tricky. Anyhow, this is how tools such as Process Monitor (which only handles a relative handful of system calls) work.
If you want to modify the behavior of a bunch of programs, you could create modified versions of the system libraries, and put them where the programs would load them (usually the application directory would work, but sometimes you would need to replace the system copy). This approach is a lot of work, though not completely impractical; you simply need to shim all the exported functions (or at least, the ones you care about) with a version that filters the call before passing it through to the "real" version, but you would need to cover all the exported functions without breaking their ABI. Doable, but a lot of work.
If you only want to get one function, the easiest way would be to re-write all calls to that function in the process memory such that they go to your filter instead. This is how the Detours library (http://research.microsoft.com/en-us/projects/detours/) works; you can find code samples of using it online. I believe that is also how Microsoft's application compatibility shims work. There are registry keys which will cause a given program to be loaded in a debugger (which can be mostly non-interactive, and just make this change for you) or I *think* there's a way to specify an arbitrary DLL that a given program must load (and run its DllMain function) when it starts up too, which would also do the trick.
Bear in mind that the second and third methods can be bypassed by an attacker who knows what you're doing; the attacker just (re-)overwrites the function tables to point at the real versions of the APIs, or alternatively makes the relevant system calls directly (Win32 programs basically never do this, instead letting the Win32 subsystem translate their Win32 function calls in NT system calls and invoking the wrapped syscall, but there's nothing *stopping* them). The first approach can't be bypassed by an attacker with less than Admin privileges (assuming you did it right; I can think of a couple of potential gotchas you'd need to avoid) but you would need Admin yourself in order to install that driver in the first place, and if you want to *interactively* filter the API calls you would need the entire interaction path including the UI to protected against tampering by less-privileged processes.
With all that said, a real Mandatory Access Control that gives finer-grained control than Windows' Mandatory Integrity Control would be a really cool thing (something more like SELinux or AppArmor). It would probably be more effort on NT than on Linux though, due to NT not (so far as I know) having any equivalent of http://en.wikipedia.org/wiki/Linux_Security_Modules (a good place to start reading about the topic).
Click to expand...
Click to collapse
I want to write open sourced code that will be like super user and permissions for windows so you can have the open feeling of windows but a secure feeling as well with little to no anti-virus's. This would not be like windows rt's locks, you can run any program you like.
You're not the first person to have this idea, but I don't think you understand the magnitude of what you're asking for. Even if such a system were created, it would be a lot of work to create all the rule sets for every program you want to protect. Besides, you'd still be vulnerable to malicious code that runs as Admin (i.e. most installers, etc.) since they could unload or modify your driver.
Most of us know you can install apps over ADB from a PC to run apps that weren't made for Wear. I hope we can discuss why some apps crash on launch so we can better understand Android Wear and not waste time testing apps that we know Android Wear can't launch. Here is what I have found can cause crashes and apps simply "not working".
An Action Bar
A lot of "sideloaded" apps just crash on launch and this entry in the logcat error explains why:
android.util.AndroidRuntimeException: You cannot combine swipe dismissal and the action bar.
Click to expand...
Click to collapse
The action bar that runs along the top of most Holo design apps is "banned" from Android Wear. Developers can get around this by editing their app's code to remove the action bar or swipe dismissal ,but unless the app is open source this is useless to us users. Interestingly enough apps with Material Design action bars do launch just fine. The lesson here is to check an app's screenshots for a Holo action bar before attempting to sideload it.
Internet Connectivity
Android Wear does not have a true internet connection. Instead, Wear apps must use Google's APIs to transfer data to the phone (and the internet via a phone app if necessary). This means any app not made for Wear that requires an internet connection won't work at all. I wonder if Bluetooth Tethering a Wear watch to its host phone could fix this.
Screen size
Few apps were made with screens this small in mind. Some layouts simply don't fit important buttons within the screen, making the app useless. Bugging app developers to fix this isn't worth their time and editing the screen DPI makes Android Wear tend to crash (from what I've heard) so those apps must simply be ignored after testing.
These are the three reasons I've found sideloaded apps don't work. Please correct any mistakes I've made and contribute your own criteria if you can. I hope you found this informative!
All ad networks have their ups and downs. They'll have a good campaign, then it will end, then later they'll get another, and so on. It's best to have multiple networks and mediate them. That way you get the benefit of the ups, and can mitigate the downs.
What is the best? That is a question that is always asked but can never really be answered. But now you CAN try out these different networks without wasting valuable time and resources.
Using Enhance, you can now integrate all of the services that providers offer without ever having to touch an SDK again. With little to NO coding at all and without touching source code, Enhance® is the easiest way to integrate 3rd party services into your project or to keep them up to date. (Ads, Mediation, Analytics, Attribution, Crash Reporting and more) No more SDK integration!!!
Gone are the days of spending hours or even days implementing and updating SDKs. How does a few clicks and a few minutes sound? Well, follow the link for more information on how to get started with Enhance® : https://goo.gl/LUjTLt
Have you checked out Enhance lately?
Our team has been hard at work making it even easier to be GDPR compliant!
https://goo.gl/LUjTLt
Hello All,
I am developing a watchface in Android studio in java targeting Android 12.
I need to add complications data on my watchface. I want that complication should be set to a default system complication without requiring user to configure it.
I also found it challenging to handle double click/touch gesture on the complications in wear os.
Is there any good and complete tutorial/guide/sample for adding complications on wear os watchfaces in java?
I found one sample on the android developer website but it is not sufficient.
Any help would be much appreciated.
Thanks all.
Teste
salwan.hemant said:
I want that complication should be set to a default system complication without requiring user to configure it.
Click to expand...
Click to collapse
I'm not sure that is even possible? The whole complication system gets data from the system. Your watch face only gets to receive the data the user has allowed via the system dialog your app invokes.
salwan.hemant said:
I also found it challenging to handle double click/touch gesture on the complications in wear os.
Click to expand...
Click to collapse
I made a watch face, but ended up not using the system's support for drawing complications, rather I grabbed the data and did the drawing myself. That also made it trivial to handle clicking, since there isn't anything else to capture events.
The example I link to below suggests you can just not pass tap events to the drawable (if it's not doing what you want). I'm going to guess the standard thing is just to invoke the pending intent, which you can do yourself.
salwan.hemant said:
Is there any good and complete tutorial/guide/sample for adding complications on wear os watchfaces in java?
Click to expand...
Click to collapse
I found this project to be useful...
GitHub - android/wear-os-samples: Multiple samples showing best practices in app and watch face development on Wear OS.
Multiple samples showing best practices in app and watch face development on Wear OS. - GitHub - android/wear-os-samples: Multiple samples showing best practices in app and watch face development o...
github.com
But since I was targeting an older watch (stuck on Android 8) and using Java, I had to go back to a much older version of the code.
git checkout 5c2e340