[Q] Capture Stylus events before they go to Apps - Galaxy Note 3 Developer Discussion [Developers Onl

Reposting from where I previously put this, on the suggestion that folks here might have more idea what I am talking about.
Yes, this is a question but I couldn't see that it fit in better to one of the other forums. If I am wrong please accept my apologies and redirect me, thanks.
I'm trying to work with a custom build of Android based on KitKat to incorporate a stylus, copying some of the functionality (though not code) from Samsung which sells Android-with-stylus builds for e.g. the Note 3. I'm not including details of the specific device because right now I am working on a custom dev device and my aim is to write code which is generic enough to be usable from any Android (based on KitKat). The build (written by others) already incorporates drivers and sends stylus events correctly as motion events etc. Programming at the app level I can receive onHover, onTouch, onClick etc
The specific functionality I am trying to achieve is to pick up a stylus-button-click while hovering. It's perfectly possible to do this in any app, using an onGenericMotion Listener.
However, I want to make my "stylus-action" have system-wide effect - so that anywhere (in any other app, or in the launcher or whatever) I will pick up the event (prior to any other app) and bring up my custom menu. (just like AirCommand in Samsung Note 3) I guess in my custom Android this would then make that particular action somewhat protected or unusable for other users, but I'm ok with that.
In older Android (prior to ICS) you could try something by putting up a System Overlay (i.e in regular app code, without hacking the ROM at all), but this is no longer possible.
This is not an attempt to tapjack or whatever, I understand why this functionality has been removed from the domain of the regular programmer, and I don't want to regress my ROM back to pre-ICS behaviour by allowing the System Overlay hack. Now I am programming the system (if my change is good enough I'd like to submit it back to AOSP) so I would like to know the best method to address this. Since Samsung have already done this, it must be legal (using legal in the terms of "Android will allow it"), and I want to do it right.
Is it possible to write something similar to the System Overlay when you are running from a system service? Or is there a good choke-point to capture events before they are broadcast to the current running apps?
I was looking at (sorry, not allowed to post links) AndroidXRef /frameworks/base/core/java/android/view/View.java specifically in the function dispatchHoverEvent() which looks like a promising place. My naive idea is that I would place code here checking the MotionEvent to see if the button is pressed and if it is, don't call any listeners and instead call my little menu app (or broadcast a custom message, or something anyway). However, I've never written code on the ROM level before (LOTS of experience writing app code) so I don't know if this is a really bad point or a good point to add in code. Should I be putting things at a higher level or a lower one? Will this capture all events or not? Is it all just trial and error?
If this is the wrong place to ask questions like this, please tell me where on XDA I should be asking it. If it's the right place - please answer
Thanks
Kibi

Related

[Q] Android development capabilities

Hey guys,
I'm in the very very early stages of my masters work and I was toying around with the idea of using an Android tablet for part of it. I want to ask you devs what can be done when modifying the Android OS itself specifically in terms of a few things.
1. Logins - I would like to implement a classic user/password combination with levels of access for user, administrator, and some sort of superuser.
2. Restriction of User account - I would like to lock the user into one particular application. It must be relaunched when the device is booted and if the application crashes (hopefully not!) it must be restarted. Additionally, no market access, web access, etc.
3. Remote management if possible
4. Data encryption if possible
5. Prevent anything from being introduced from USB ports, SD slot, etc if unwanted.
I guess this brings me around to - is Android even the most suitable platform for such an endeavor. I'm not sure, to be honest, but I would love to get into development myself and this seems like a great way to learn. This is all just one part of a much larger project that I don't want to discuss just yet so sorry for being lax on details.
Thanks guys!
Android runs a virtual machine system called dalvik, in which each application gets it's own insuranceof the machine. It's implemented in such a way that each application gets assigned a user id, which unfortunately for you means each app is a different user, at least to the system. That's going to be a major wrench in the multi user plans. taking that into consideration, to have the same level of control over your tablet you'd have to give even the most basic user level "root" access or else the apps will start crapping their collective pants. As far as unwanted usb, there are a few apps that implement this functionality freely available through the market. Same with remote management. What I haven't seen yet is total encryption and I don't know enough about it to say it's possible or not. Seems feasible though.
My advice: write a custom login screen widget and then bake all these features into a pretty rom.

Intent Evolution Idea: Sentence

Hey guys, random thoughts/rant for a software idea.
I was thinking of the next evolution of the Intent system on Android. I always thought OSs seemed to spend almost no effort on integrating softwares on it. It was almost like an afterthought every time. Android was a huge step in the right direction. The next step would have to be very definitive, and backwards comparable of course. It would have to be something users want, and make it easier on the developers as well.
This system would be called something along the lines of 'Sentence'. It evolves with developer and end-user choices and, if I'm right (here's the big pitch, would have the potential to make software measurably more stable, secure, efficient, and user-oriented without really changing any behavior on the developer's side. Of course it has the same potential to be stagnant, but I think the users would punish (unwittingly) developers who lagged behind or didn't put in the effort.
The sentence system allows a user to build a sentence to discover not only the correct application, but an infinitely specific task before ever encountering UI. It is reminiscent of auto-completing sentences in Google Search. An example is the quickest way of demonstrating. The [] specify user interaction and ** specify user choice (probably a button press):
I would like to
[*send*] [search] [open][...
[a][*multiple*][...
[2][*3*][4][5][CUSTOM][UNTIL...
[files][emails][smss][*pictures*][...
[*to*][GO][...
[emily][drake][*george*][...
[*and*][GO][with message][...
[emily][*drake*][george][...
[and][GO][*with message*][...
[CUSTOM][*check this out*][...
[*GO*][and]
this immediately opens the camera app for exactly 3 pictures. Once the 3rd picture is taken, the UI informs the user that the next action is about to take place. After a short time out, the 3 pictures are sent to George and Drake. After the first shot, the user can shut off the screen or pocket the device knowing the timeout will occur and then the task will continue. Being an OS-level function, the user can trust it regardless of the app.
Unless the app task fails. If Apps that use this system can't provide tasks that don't fail, they will become unpopular far quicker than the tasks that do fail that users just deal with anyway.
Furthermore, many apps can be published virtually without any UI at all, significantly cutting down on development time and allowing the dev to focus on the task and functionality.
This could turn around voice activation as well, since the user quickly understands the routine task format to get the best results, and would be more confident to provide far more complex long-winded sentences that the OS could understand perfectly to the detail.
While some sentence lines will be defined by the OS, the developers and users alike will be able to define the evolution of the sentence tree. Developers will make the smart decisions, while the users will crowd-source the popularity of each possible route. The most logical and/or common sentences would quickly be the norm. If the OS prioritizes specific routes over general ones, then developers will be incentivised to make their apps as task-specific as possible as well as as task-plentiful as possible.
The losers in this quickly become apps that use ads, apps that rely on 'convincing' the user of something with UI, and of course utility apps. Of course, this brings back the main reason for 'pro' apps: functionality. The pro version will have these features. The free version will only have these.
There wouldn't be a way to exploit the system or flood it. If the functionality doesn't work, the app becomes not only intrusive and annoying, but offensive to the user as it promised a specific task and performed something else entirely. Those apps simply wouldn't survive.
Of course, application for this kind of thing would have to be imposed by Google et all for it to exist, but there is another way. It can be implemented as a shared library that provides the necessary interfaces and cache all the necessary information for other compatible apps. That would work for a full implementation, and I can't see any features that would be missing. Backwards compatibility would still work just fine, as the app would simply fit existing intents into this sentence tree as well as it can. The sentences would simply end up being smaller. The best part is that with the right effort, this sentence tree could act as an 'Intent builder' for existing android apps. I bet I could build a handler for the tree that would get me through the above demonstration with the standard Gmail app using known intents. See where I'm going with that?
I would build it myself if I had more time, but I'm def interested in helping (or instructing) anyone who would like to take a crack at it. I think if someone got this idea into Cyanogenmod, we'd have a pretty huge win, and Cyanogenmod would have an incredibly unique UI gem to show off to stock users.
Honestly, I see no way that a system similar to this won't be built and become the standard within a decade. It would be trivially easy to build as well although some of the decisions to be made might not be so easy. So yeah, that's it. Rant over.

Accessing features in Windows phone 8(.1) development

When developing an application for desktop windows, there's always a way to access functionality - sometimes through back doors like the registry, etc... I'm developing an application for Windows Phone 8.1, but there are certain pieces of functionality that aren't exposed in the PRT APIset that is available to me. For example, we want to ensure that the user has password protection on the lock screen when using the application. There doesn't seem to be any associated APIs to readily use. So my question is, are there back door ways to do such things? How? Is there a way to access ALL system settings - like a registry or something of the like?
proch said:
When developing an application for desktop windows, there's always a way to access functionality - sometimes through back doors like the registry, etc... I'm developing an application for Windows Phone 8.1, but there are certain pieces of functionality that aren't exposed in the PRT APIset that is available to me. For example, we want to ensure that the user has password protection on the lock screen when using the application. There doesn't seem to be any associated APIs to readily use. So my question is, are there back door ways to do such things? How? Is there a way to access ALL system settings - like a registry or something of the like?
Click to expand...
Click to collapse
Another question would be - if something like intune can enforce lock screen password policies, shouldn't I be able to do it the same way that intune does it? If so, how? If not - why not?
It's not possible to check if user enabled lock screen password or not as far as I know
but if you want to made your app secure (because it may include important data)
you can create a password for your own application !
I did it in a little notepad app my password page allow user to set a password with all English and Persian Characters , numbers and special Chars like [email protected]#$ and etc.
Sent from my RM-994_eu_poland_1183 using Tapatalk
It's pretty easy to check, using the registry, but at least in 8.0 that's not allowed at all for store apps (your app would get rejected). I don't know if the rules changed for 8.1. There are ways to sneak past the store checks, but they could pull your app from the store if they ever found out. I know of at least three ways to access the registry APIs (4 in WP8.1) and two of them are pretty hard to detect unless somebody checks for them specifically... but they're the kind of technique that malware uses, so such checks may be in place.
I don't know what InTune is doing, specifically - I'd need to pull the app apart to see - but there are special application capabilities (not normally available to third-party developers) that can query and even set policies. Apps without those capabilities will get Access Denied if they try to use the same methods though, and normally you can't add those capabilities to your app.
GoodDayToDie said:
It's pretty easy to check, using the registry, but at least in 8.0 that's not allowed at all for store apps (your app would get rejected). I don't know if the rules changed for 8.1. There are ways to sneak past the store checks, but they could pull your app from the store if they ever found out. I know of at least three ways to access the registry APIs (4 in WP8.1) and two of them are pretty hard to detect unless somebody checks for them specifically... but they're the kind of technique that malware uses, so such checks may be in place.
I don't know what InTune is doing, specifically - I'd need to pull the app apart to see - but there are special application capabilities (not normally available to third-party developers) that can query and even set policies. Apps without those capabilities will get Access Denied if they try to use the same methods though, and normally you can't add those capabilities to your app.
Click to expand...
Click to collapse
Thanks for this great and detailed information. See, that's exactly what I'd do if I were developing a desktop app - since i know that intune does it, I'd figure out how intune does it and voila. I'm finally getting over the idea that the same methodologies apply to windows phone development.
For my own educational purposes (since I want to understand this platform better), I would really like to know specifically how you go about accessing the registry APIs (for example). If there's any way for you to describe any number of these methods, I'd greatly appreciate it. Thanks again!
My NativeAccess libraries (check my signature, or search on the forum or on Codeplex) contain an example of one way to access the registry. The code is open-source; you may use the libraries as-is (don't expect to get them into the store, though I won't stop you from trying), use the source code as a reference, or modify/build them yourself; the license is very liberal (MS Permissive). The functions I use are generally documented on MSDN, in the desktop APIs section; the phone has the same functions, although the DLL names are changed and the header files hide them.

Make sure apps don't get rejected

Hi,
I have created an application using Phonegap for a platform similar to Wordpress. The app allows users to login into their accounts, view personal messages, files, etc. Now, I want to publish the source code so that developers can grab their own copy of it and submit it to the PlayStore/Appstore. What I am worried about: Apps sometimes get rejected due to the fact that they are similar to another one. Is there any way to prevent this? A few colors and the site name will be changed by the site owners, but the core will stay the same. I saw many companies selling apps like I am planning to do and it doesn't seem like there are any problems. How can they make sure there is no rejection because of the similarity (in this case in my JS files)? Should I change the source code for every copy of it? (this might be pretty hard but I could change the order of my JS functions or rename some objects, randomly include some useless scripts etc) Or am I just way too worried about this?
Thanks for your help

keyloggers in custom roms.

i am concerned.
i love to root my device and remove bloatware. ya. samsung devices. full of junk.
i use titanium backup but it seems to have trouble with magisk because its systemless and not like supersu.
anyways, my concern is about custom roms that we download from these forums.
what are the odds of rom creators infecting "Keyloggers" in these roms? i mean these days we use Lastpass to enter in our master password which contains all our passwords for our emails and other sites.
as well as authy.
its just a question.
yes. i prefer a custom rom and favor it as opposed to samsung roms.
any feedback?
@cylent
It's absolutely possible from looking at the Android Accessibility APIs:
developer.android.com/guide/topics/ui/accessibility
But, from my knowledge and testing, the key logger would need EXPLICIT access to the 'Accessibility Services'.
(Options > Settings > Accessibility) + see the attached screen shot.
If you installed a custom ROM and saw an application listed here not explicitly defined in the release notes, ensure it isn't enabled. Next query the developer as to its purposes. It's possible that just because it shows here that it isn't necessarily malicious and might serve a greater purpose.
If you receive no response or a runaround, disable it under 'Accessibility' and find the corresponding name under 'Apps' and remove it.
For that matter, dump the ROM altogether and find another immediately. I'd like to think our savvy little community would pick up on this breach of trust ASAP.
For testing purposes, mine is called 'Android Keylogger' but a malicious user could (and likely would) call it something less threatening.
Hopes this helps!

Categories

Resources