[DEV] NFC Unlock - Nexus 5 Android Development

Hi, I've been building my own N5 ROM for a while now but don't have the time to release/maintain/support it plus there are plenty of other options out there that are very similar. BUT, I recently got me an NFC Ring and so wanted to build NFC unlocking into the framework and this is something that currently can only be achieved using an Xposed module so I thought I'd share the code.
First of all, a huge thanks to MohammadAG and qwerty12 for their work on the Xposed module here as this is what a lot of my changes are based on.
The first thing I did was modify Nfc and Settings apps so you can choose when to enable Nfc Polling...
Polling off
Screen off
Screen on and locked
Screen on and unlocked
Screen on and locked only - this is a new mode i've put in that turns Nfc on with the screen and then off again once unlocked. As I only use Nfc on my phone for unlocking, this is really useful as its nice on the battery and doesn't prompt with the empty tag viewer every time i unlock!
Then, using the Xposed module as a basis for the code I added Nfc unlocking into the framework and Nfc app as well as a new item under Security Settings where you can add/remove tags that are allowed to unlock.
In terms of security:
the Nfc tag acts as an override to whatever other lock screen you're using, pattern, pin etc.
The tag contents are only handled if the screen is unlocked. If polling is set to 'screen on and locked' then the tag will be picked up as soon as the device is unlocked but there's no way for an unauthorised tag to have its contents handled while the screen is off or on and locked.
The unlock is triggered from the Nfc app as an intent, it's probably possible to trigger this intent from elsewhere but the tags uid is checked from within the keyguard while handling it so the uid needs to be known and passed as part of the intent for this to work.
It's all working nicely for me so far but given I'm not massively familiar with the guts of the android lock screen security and creating new UI's, there's probably room for improvement.
So, ROM devs feel free to add this to your ROMs, giving credit where credit is due and let me know of any fixes or improvements either here or as pull requests on my github. The modified repos are here:
https://github.com/AospPlus/android_packages_apps_Settings/commits/aosp-plus_4.4
https://github.com/AospPlus/android_frameworks_base/commits/aosp-plus_4.4
https://github.com/AospPlus/android_packages_apps_Nfc/commits/aosp-plus_4.4

So I fully apologize because I know this is not the right place to ask this question, however, this is exactly what i'm looking for.
'm running an n5 with elementalx 1.00 and rooted stock 4.4.4. I would like to add this functionality to my phone, because i too (****ing eventually) have a NFCRing.
I'm not a dev, so i understand that this request is tricky for you to help me with. but anything you can suggest, to avoid dealing with the xposed framework or the relatively useless functionality of the NFC ring unlock app, would be greatly appreciated.
Simon
tombriden said:
Hi, I've been building my own N5 ROM for a while now but don't have the time to release/maintain/support it plus there are plenty of other options out there that are very similar. BUT, I recently got me an NFC Ring and so wanted to build NFC unlocking into the framework and this is something that currently can only be achieved using an Xposed module so I thought I'd share the code.
First of all, a huge thanks to MohammadAG and qwerty12 for their work on the Xposed module here as this is what a lot of my changes are based on.
The first thing I did was modify Nfc and Settings apps so you can choose when to enable Nfc Polling...
Polling off
Screen off
Screen on and locked
Screen on and unlocked
Screen on and locked only - this is a new mode i've put in that turns Nfc on with the screen and then off again once unlocked. As I only use Nfc on my phone for unlocking, this is really useful as its nice on the battery and doesn't prompt with the empty tag viewer every time i unlock!
Then, using the Xposed module as a basis for the code I added Nfc unlocking into the framework and Nfc app as well as a new item under Security Settings where you can add/remove tags that are allowed to unlock.
In terms of security:
the Nfc tag acts as an override to whatever other lock screen you're using, pattern, pin etc.
The tag contents are only handled if the screen is unlocked. If polling is set to 'screen on and locked' then the tag will be picked up as soon as the device is unlocked but there's no way for an unauthorised tag to have its contents handled while the screen is off or on and locked.
The unlock is triggered from the Nfc app as an intent, it's probably possible to trigger this intent from elsewhere but the tags uid is checked from within the keyguard while handling it so the uid needs to be known and passed as part of the intent for this to work.
It's all working nicely for me so far but given I'm not massively familiar with the guts of the android lock screen security and creating new UI's, there's probably room for improvement.
So, ROM devs feel free to add this to your ROMs, giving credit where credit is due and let me know of any fixes or improvements either here or as pull requests on my github. The modified repos are here:
https://github.com/AospPlus/android_packages_apps_Settings/commits/aosp-plus_4.4
https://github.com/AospPlus/android_frameworks_base/commits/aosp-plus_4.4
https://github.com/AospPlus/android_packages_apps_Nfc/commits/aosp-plus_4.4
Click to expand...
Click to collapse

Hey man, give me a few days and ill compile a pure aosp rom with just these changes and hopefully you should just be able to push I think 4 system files and have the functionality.
Sent from my AOSP+ on HammerHead using Tapatalk

Related

[INFO] Palm Pre (Cards-Like) Thumbnails

Hi all,
@ruqqq (aka arctu, author of HelixLauncher) tweeted me a whole bunch of stuff this afternoon, and to be honest, this is 99% his credit, I only changed the required line in framework to help him test, so I get 1% . Anyway, @ruqqq did some searching online, and the one of most importance was this:
http://www.mail-archive.com/[email protected]/msg21135.html
After looking at the code, we simply uncommented the following line in ActivityThread.java:
Code:
//info.thumbnail = createThumbnailBitmap(r);
With it commented, it thumbnail will always be null, with it uncommented, well, we may be able to get actual thumbnails. @ruqqq then went on to write a quick (and ugly ) app to find out if thumbnails of running apps can be retrieved, and the result is, yes, it can be retrieved. The screenshot I posted only shows 2 apps cause of the lack of ScrollView, but I believe he's writing a better proof-of-concept as we speak, while I'm rushing to go out once I end this post (else the girlfriend's fury ).
Screenshot: http://twitpic.com/1w1p6t
New Screenshot (Still ugly ): http://twitpic.com/1w1v6k
So what's the point of this post? Nothing, really. It's just that the commented line has apparently been in there as early as 1.5, but it was always commented out. We removed the comment, and it actually does return thumbnails. With this, it means that if future ROMs are compiled with that line uncommented, it will be possible to actually write apps to emulate/simulate the cards system, possibly even on a system level (by overriding the recent applications dialog).
That's all .
@ruqqq's concept app source: http://github.com/ruqqq/ActivityThumbnailPrototype-Application
framework source: Come on, it's just a line .
Very interesting. Looking forward to seeing/hearing more! =)
yay! experimentation succeed.
just to add on:
the idea is that third-party developers can implement this in their apps without any breaking codes. the api has always been official. if thumbnail doesn't exist, it returns a null. so, a dev simply has to write a code that checks for this property and carry out 'instructions' based on the availability of the thumbnail.
implications:
what we learn is that the reason they disabled the code is to prevent wasteage of resource (CPU and Mem) as the thumbnail code runs everytime the onPause of an activity is performed. This means that enabling it may or may not cause slowness in the system. Conclusion? Need extensive testing.
wow this is great news looking forward to seeing cards like on web os
the wonders of Android!
Pretty cool stuff. Perhaps you can make it so only if the app is running is that variable on and generating thumbnails ? Regardless cant wait for what developers do with this, im sensing the app taskos with live thumbnails it already has the fling up to end task.
Also to prevent this from being rom specific, maybe you could compare the hexcodes of 2 framework-res.apk's one with uncommented and one without, that way it could be added to any existing rom ?
Daneshm90: This has to be baksmali/smali-ed in.. ^^
Cyanogen Please Put this in you next ROM! Android is just awesome! thanks for the post!
Daneshm90: This has to be baksmali/smali-ed in.. ^^
Click to expand...
Click to collapse
Is that even possible ? it doesnt have a classes.dex (Nvm, u have to push the classes.dex of framework.jar into framework-res and decompile)
can u give me a modded and unmodded framework-res ? just wanna do some digging
Wow this has great potential!
I agree is this became stable Activity closer and switcher in the format + ADW + cyan or any other great developer + froyo = greatness
The bitmap can be used to make rotation and other screen changes faster. Load the bitmap before you load the real screen. This could be very important.
lsim001 said:
The bitmap can be used to make rotation and other screen changes faster. Load the bitmap before you load the real screen. This could be very important.
Click to expand...
Click to collapse
Thats actually true. The iPhone OS takes a screenshot of each app on exit, and then when you open it again it displays that screenshot until the activity is fully loaded. Could be implemented as such on Android too, but would take a lot of back end work.
Also, theres one thing I'm worried about. Since it takes a screenie on every OnPause of the activity, how will you stop it from displaying a "card" for every activity of an application. I mean for instance my game has 3 activities, one for each the play surface, the start screen, and the score screen, wouldn't I see a "card" for each of those the way this is now?
Sounds like that was put in to future proof the OS.
At the time it was probably too gpu reliant, and they decided to forego it.
Hello!
Please excuse my ignorance, but I have a few questions.
I am the developper of TaskOS and this feature is what I'm looking for months in my application.
Si, if I understand well this topic, the linecode to add must be done by ROM's developpers, is it true?
I really would like to have a list of compatible ROM's or please tell me if I am totally misunderstanding what you say.
Profete162
Profete, I don't think that any ROMs have this yet because it has just been discovered.
Je crois qu'il n'y a pas de ROMs qui utilisent ce code car il vien d'etre decouvert
Hi all, by uncommenting the line, you can then simply refer to the official API (oddly), and all the methods will work instead of returning null (for thumbnails). Check it out here: http://developer.android.com/reference/android/app/ActivityManager.RunningTaskInfo.html
According to Fede (developer of LauncherPro), the thumbnail resolution is 84dip by 63dip .
profete162: As of now, I doubt any ROMs include this. Hit me up on Twitter @Wysie_Soh !
profete162 said:
Hello!
Please excuse my ignorance, but I have a few questions.
I am the developper of TaskOS and this feature is what I'm looking for months in my application.
Si, if I understand well this topic, the linecode to add must be done by ROM's developpers, is it true?
I really would like to have a list of compatible ROM's or please tell me if I am totally misunderstanding what you say.
Profete162
Click to expand...
Click to collapse
this is at discussion stage currently and the first post is just my prototype to show it works.
basically, the current plan is to improvise the code to:
1. higher resolution + optimization (perhaps: a bit sensitive issue)
2. orientation detection (discussed with Fede on twitter, it's quite simple)
3. incorporate in custom rom (e.g. cyanogenmod)
...if you're using CyanogenMod, get in touch with Wysie to get his framework or .. you can compile yourself to test it.
i don't have my N1 with me right now and hence can't develop this any further than now. *irritated*
Any further developments with this, guys?
gee
gee willickers!

[Q] Simple blank lock screen, tap to unlock

Hello everyone,
Since I have 1 posts including this one on the XDA forum and couldn't post in the dev section, I guess it'll have to go here. I'd like to make a simple lock screen for my Galaxy S2 (Android 2.3).
It would be similar to the default pattern lock but I don't want a combination of dots. Instead, I want it to unlock at a single tap at a position on the screen, or maybe two correct taps.
Since the default pattern lock requires at least 4 dot connections, I couldn't use it. I also want it to show the background with no widgets, only maybe the notification bar.
Now I downloaded the Android SDK, but I have no experience with it. I have past C++ experience and I'm willing to learn, but I would like some directions and perhaps code snippets to get me started.
Inb4 NOT SECURE LOL: It's what I want to have.
tl;dr Mewants to make single or double tap lock screen with no widgets showing. Halp?
Try AppInventor ...It is a good way to learn to make apps for Android without really knowing the programming...all you need to know is hoe you you want your app to work...and since you have previous experience with C/C++..am sure the loops such as if/if-else etc in the pictorial manner won't confuse you..Good luck..Its a good Idea you have there..dunno if it can be implemented for sure though!
There are many AOSP Lockscreens available in the dev section anyway...check them out till then

[Tool][02 Nov]Kernel Gestures Builder

Hi fellow devs of XDA !
On Aug 13 2012, Tungstwenty introduced a new awesome feature to android kernel, that empower our touch devices to a new level, the ability to respond to multitouch gestures:
[Ref][Kernel]Triggering actions with touch gestures
As Far as I Know, The feature is implemented in the following kernels:
Samsung Galaxy SII - I9100
Siyah // Siyah Mali v2
DorimanX
Samsung Galaxy SIII - I9300
Siyah
Now let me introduce to you Kernel Gestures Builder, the tool that allows you to define the gesture pattern in a user friendly fashion:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
​
Install (for free):
Link to Google Play (The Place Formerly Known as Store)​
Usage:
If you have DorimanX kernel you config is in /data/gesture_set.sh
If you don't have current config the script will be installed in /etc/init.d/S50GestureActions
Backup current script config, will be overwritten
Launch Kernel Gesture Builder App
Select Menu/Reset Gestures
Select Menu/Reset Actions
(optional) Select Menu / Settings / Grid Columns and Grid Rows (default 3 columns and 5 rows)
Draw Gesture with as many fingers as you like (maximum supported by kernel is 5)
When last finger leaves the screen, gesture definition is copied to clipboard and local file is saved
Configure Actions by selecting Launch Application or Set Action
If Desired, select Test Action to execute defined action
Open gesture definition script with editor and paste gesture OR
Configure Actions in /data/data/ar.com.nivel7.kernelgesturesbuilder/files/gesture-*.sh
and Select Install Gestures to REPLACE without backup current gesture_set.sh or S50GestureActions and new directory /data/gestures (do not edit anything here, will be overwrite on each Install Gesture action)
Select Menu/Select Gesture to edit another gesture and repeat the process from
Draw Gesture for each desired gesture
Select Menu/Install Gestures, if you have DorimanX kernel with Gestures enabled, turn off screen and turn it on again to activate new gestures. If you have another kernel reboot to apply changes.
enjoy!
Thanks To:
Tungstwenty , gokhanmoral, DorimanX , Robert Green , Gustavo_s
This list is not complete please inform me anyone that contributed and have credits
License (Open Source, feel free to contribute and giving proper credit if you use it):
GPL Version 3​
Sources:
https://github.com/flint2/KernelGesturesBuilder​
APK Archive:
http://d-h.st/users/flint2/KernelGesturesBuilder​
Changelog:
Version 1.15 [Nov 02 2013]
Support for Android 4.4 KitKat
Version 1.14.1 [Jun 11 2013]
Bug Fix: FC on start
Version 1.14 [Jun 06 2013]
Select Gesture from Main Menu
Version 1.13 [May 03 2013]
(unpublished)
Version 1.12 [Apr 26 2013]
Set Action to gesture
Test Action
Version 1.11 [Apr 19 2013]
German, French & Spanish Translations
Browse for Applications to Launch on Gesture
Version 1.10 [Apr 8 2013]
Google Analytics for better support and future development
Version 1.9.1 [Mar 12 2013]
Add support for new Superuser https://github.com/koush/Superuser
Version 1.8.1 [Jan 7 2013]
Resolved bug in gesture install script
Version 1.8 [Dec 26 2012]
Display actions for current gesture
Force Portrait Mode
Default gestures for 1280x720 devices
Install Script in /system/etc/init.d if no /data/gesture_set.sh
Version 1.7 [Nov 30 2012]
Draw actual path of traversal of every finger with different color and alpha blending [Debadatta]
Read and Write to Scripts [It_ler]
Parse gestures from config
Version 1.6 [Nov 23 2012]
Install new Actions and Gestures config in /data/gestures (overwrites current script!)
Changed max fingers to 5 (kernel limit)
Version 1.5 [Nov 15 2012]
Allow changing of Gesture Number (1-30) from Settings
Version 1.4 [Nov 11 2012]
Copy Gesture to Clipboard
Version 1.3
Display Gesture Number fixed
Version 1.2
Display Intercepted Hotspot
Version 1.1
Detect Hotspot
Known Bugs:
Bad finger numbering if finger not lifted in inverse order
Any Bug that you report
Todo:
Animate the spots of an existing gesture to view on screen what trace you must do with fingers [Mario1968]
Custom name for gestures [Mario1968]
Always show current gesture anim, gesture number, gesture name on screen [Mario1968]
Any Feature that you request
If you like my work please buy me a beer
DONATIONS FROM:
DorimanX​
Reserved I
Reserved I
Reserved II
Reserved II
Great, will try
Hay buddy, tnx for kg tool. Wanna trying these. Report u later.
sorry for my bad english.
Just my thoughts:
Have you thought about a collaboration with Tungstwenty to combine / integrate your gesture building app into his multi touch gesture kernel feature?
Ok, copy & paste the gesture definition into a script is not that difficult, but if you could define the gesture and assign it directly to a script/action (without manual copy & paste), that would be even easier and more (end-)user friendly.
I have something similar to tasker app in mind, but with your gesture (builder) as the trigger.
Good idea anyway !
That's is Awesome!
Thanks allot!
beer on me
Confirmation number: 2WN54160CY969421P.
Now that is really cool thnx for this!!!
Sent from my GT-I9100 using xda app-developers app
Sounds great! I'll try it right now.
Sent from my GT-I9100 using xda app-developers app
dorimanx said:
That's is Awesome!
Thanks allot!
beer on me
Confirmation number: 2WN54160CY969421P.
Click to expand...
Click to collapse
You're my hero!
Thank you very much for your support and everything you're doing for the community!
Sent from my GT-I9100 Powered by Dorimanx kernel and AOKP unicorn
It_ler said:
Just my thoughts:
Have you thought about a collaboration with Tungstwenty to combine / integrate your gesture building app into his multi touch gesture kernel feature?
Ok, copy & paste the gesture definition into a script is not that difficult, but if you could define the gesture and assign it directly to a script/action (without manual copy & paste), that would be even easier and more (end-)user friendly.
I have something similar to tasker app in mind, but with your gesture (builder) as the trigger.
Good idea anyway !
Click to expand...
Click to collapse
Yes, the objective of this app is to be able to parse, edit, and generate Tungstwenty rc.d script (or DorimanX equivalent)
If you find anything else please ask and will be included in TODO
Sent from my GT-I9100 Powered by Dorimanx kernel and AOKP unicorn
Flint2 said:
Yes, the objective of this app is to be able to parse, edit, and generate Tungstwenty rc.d script (or DorimanX equivalent)
If you find anything else please ask and will be included in TODO
Sent from my GT-I9100 Powered by Dorimanx kernel and AOKP unicorn
Click to expand...
Click to collapse
How about drawing the actual path of traversal of the finger? Would be helpful for some people. After the hand is lifted off, you can show an animation to replay how the finger was moved i.e. how the gesture actually will be. Then ask for a confirmation and copy to clipboard or merge with S50GestureActions like lt_ler said. Plus, you might want to ask gesture number before generating the definition. The def is always assuming 1. Yes, some people actually will have problems with changed a 1 to their desired number I know after being so long on XDA.
Also, when merged with S50GestureActions, create a check to check if a requested gesture already contains a predefined gesture. This is because, even if this gesture is defined, the predefined gesture will execute halfway between the requested gesture. I know, "Duh!", but this app makes defining gestures so damn easy, you'll have a noob attack here. So, its essential for this to be noob proof.
P.S. the drawable lines should have some percentage of transparency to avoid confusion when they overlap.
Debadatta said:
How about drawing the actual path of traversal of the finger? Would be helpful for some people. After the hand is lifted off, you can show an animation to replay how the finger was moved i.e. how the gesture actually will be. Then ask for a confirmation and copy to clipboard or merge with S50GestureActions like lt_ler said. Plus, you might want to ask gesture number before generating the definition. The def is always assuming 1. Yes, some people actually will have problems with changed a 1 to their desired number I know after being so long on XDA.
Also, when merged with S50GestureActions, create a check to check if a requested gesture already contains a predefined gesture. This is because, even if this gesture is defined, the predefined gesture will execute halfway between the requested gesture. I know, "Duh!", but this app makes defining gestures so damn easy, you'll have a noob attack here. So, its essential for this to be noob proof.
P.S. the drawable lines should have some percentage of transparency to avoid confusion when they overlap.
Click to expand...
Click to collapse
Added lt_ler and Debadatta request to TODO section
Great initiative Flint!
This will be really useful for wider adoption of this "oh so scary" script-only feature
Here are some comments from me on your current Todo list:
Generate the scripts
Since there's at least 3 ways of launching the scripts (I wasn't aware of all these ), I'd suggest deciding a well-known place for storing per-gesture files for configuration (finger positions) and for actions (execution when detected) which would then be called by the main script(s).
Example:
Code:
[B]/etc/gestures/gesture-1.config[/B]
1:1:(0|100;0|100)
...
and
Code:
[B]/etc/gestures/gesture-1.sh[/B]
# Toggle "outdoor" mode
if [ `cat /sys/class/lcd/panel/user_gamma_adjust` != "50" ]; then
echo "50" > /sys/class/lcd/panel/user_gamma_adjust
echo 1 > sys/class/mdnie/mdnie/outdoor
else
echo "0" > /sys/class/lcd/panel/user_gamma_adjust
echo 0 > sys/class/mdnie/mdnie/outdoor
fi
Each of the wrapper script implementations would then:
- cat the *.config files all at once to the gesture_definitions file (it currently doesn't support incremental configuration, each write clears all the previous definition)
- loop waiting for a detected gesture and when each of those is detected launch the corresponding gesture-N.sh if it exists
This allows the definition and detection logic to keep working, and at the same time allow a frontend app such as this one to granularly parse and store each gesture's individual definition and action.
Additionally, the main script(s) can then be fixed and all the logic of maximum gestures, etc. depend only on whatever files exist on /etc/gestures/ or whatever. The app can ignore that part, especially taking into consideration that there are different approaches.
On a side note, I still am not sure about DorimanX's approach of stopping the loop while the screen is off, as the overhead afaik is nearly none (is memory relevant?). Also, I'm thinking of allow the configuration of whether you'd like gestures while screen is off or not; now that Siyah includes s2w it's merely an extra check and the associate configuration parameter for STweaks.
Review gesture paths
I also think this would be useful, not only for viewing but also "tuning".
Actual situation: if I want to draw e.g. a diagonal from top-left to bottom-right, it will pick up some of the rectangles in the middle depending on how much I deviate from the ideal diagonal.
Ideally, once a gesture is finished one would see all the touched rectangles - probably a small circle in the middle - and allow the removal of some of them as in the situation of the diagonal where the intermediate steps should be removed.
There are of course some challenges, like crossing paths or even the same finger that repeats the same path multiple times. Personally, the gesture I use to kill the current app is: 1 finger on the middle-left, another one goes from top-right to bottom-right and back, 3 times in a row.
Actions
In this topic I see several things:
- launching an app (which could allow you to browse for an app, or even better, configure a shortcut which can be a direct dial, compose message to, etc.)
- all the other advanced stuff that can be done by "am start ...", "service call ...", etc.
For this second group of items, perhaps a list of well-known things could be added gradually to the app, and still allow a fallback of directly editing the script's text for those things the user would like to add himself.
Gestures Configuration
Tungstwenty said:
Great initiative Flint!
This will be really useful for wider adoption of this "oh so scary" script-only feature
Here are some comments from me on your current Todo list:
Generate the scripts
Since there's at least 3 ways of launching the scripts (I wasn't aware of all these ), I'd suggest deciding a well-known place for storing per-gesture files for configuration (finger positions) and for actions (execution when detected) which would then be called by the main script(s).
Example:
Code:
[B]/etc/gestures/gesture-1.config[/B]
1:1:(0|100;0|100)
...
and
Code:
[B]/etc/gestures/gesture-1.sh[/B]
# Toggle "outdoor" mode
if [ `cat /sys/class/lcd/panel/user_gamma_adjust` != "50" ]; then
echo "50" > /sys/class/lcd/panel/user_gamma_adjust
echo 1 > sys/class/mdnie/mdnie/outdoor
else
echo "0" > /sys/class/lcd/panel/user_gamma_adjust
echo 0 > sys/class/mdnie/mdnie/outdoor
fi
Each of the wrapper script implementations would then:
- cat the *.config files all at once to the gesture_definitions file (it currently doesn't support incremental configuration, each write clears all the previous definition)
- loop waiting for a detected gesture and when each of those is detected launch the corresponding gesture-N.sh if it exists
This allows the definition and detection logic to keep working, and at the same time allow a frontend app such as this one to granularly parse and store each gesture's individual definition and action.
Additionally, the main script(s) can then be fixed and all the logic of maximum gestures, etc. depend only on whatever files exist on /etc/gestures/ or whatever. The app can ignore that part, especially taking into consideration that there are different approaches.
On a side note, I still am not sure about DorimanX's approach of stopping the loop while the screen is off, as the overhead afaik is nearly none (is memory relevant?). Also, I'm thinking of allow the configuration of whether you'd like gestures while screen is off or not; now that Siyah includes s2w it's merely an extra check and the associate configuration parameter for STweaks.
Review gesture paths
I also think this would be useful, not only for viewing but also "tuning".
Actual situation: if I want to draw e.g. a diagonal from top-left to bottom-right, it will pick up some of the rectangles in the middle depending on how much I deviate from the ideal diagonal.
Ideally, once a gesture is finished one would see all the touched rectangles - probably a small circle in the middle - and allow the removal of some of them as in the situation of the diagonal where the intermediate steps should be removed.
There are of course some challenges, like crossing paths or even the same finger that repeats the same path multiple times. Personally, the gesture I use to kill the current app is: 1 finger on the middle-left, another one goes from top-right to bottom-right and back, 3 times in a row.
Actions
In this topic I see several things:
- launching an app (which could allow you to browse for an app, or even better, configure a shortcut which can be a direct dial, compose message to, etc.)
- all the other advanced stuff that can be done by "am start ...", "service call ...", etc.
For this second group of items, perhaps a list of well-known things could be added gradually to the app, and still allow a fallback of directly editing the script's text for those things the user would like to add himself.
Click to expand...
Click to collapse
Thank you very much for your feedback and suggestions!!
Generate the scripts
I can support many configurations, i'm aware of:
- Yours original (/system/etc/init.d/S50GestureActions) , will need root for remount system and modify file
- DorimanX (/data/gestures_set.sh), no need to be root, only adequate permissions on file
I'm not aware of 3th method that you mentioned.
Do you know other devices besides S2 and S3 or kernels apart from Siyah and DorimanX that have your feature implemented?
If you want to split the config and actions in an alternate setup, I will support it to, these are my suggestions:
- Please keep the writeable config in /data , so no remount and root is needed
- Keep in mind the overhead of forking one more process on each gesture (modular overhead vs. current monolithic approach)
I think DorimanX intention is to keep the script always working
dorimanx said:
Kernel 7.17 ICS-JB-MALI Uploaded. (BUG FIX) and STABLE.
*Thanks to GM for guide, now cortex + cron + gestures will never be killed from RAM. so stability restored to 100% no more stuck CPU on low/high freq.
Click to expand...
Click to collapse
May be later I will ask by PM or drop a question in his thread.
Review gesture paths
- My idea is to paint every hotspot with finger color and display the sequence number in the path inside it
- Even if i will include parsing and displaying current gestures, for now I think is easy to redo the gesture than to edit or trim it (I can change my mind later on this subject)
- There is no need to keep your second or third finger in the screen all the time, you can just touch on the first point of you imaginary line, lift the finger, and touch on the end of the imaginary line, repeating this start and end points as many times as you like
As long as you keep one finger in the screen, you're still constructing the paths
When you lift last finger, gesture definition is copied to clipoard
So you can define the '5 point ROM exploding thechnique' that reboots in recovery (borrowed from Kill Bill movie)
Actions
That's exactly what I have in mind, having a set of standard, browsable Androind intents, a set of predefined am , service, cat to config, etc, and a set of custom actions
Changing manually the script should be last resort for advanced users.
I like the idea of maintaining all the configs in scripts, and daemon also in script.
The idea of building a standalone service to replace it has come to my mind but i dislike it.
So far 100+ installs and no FC or bugs reports
I appreciate all the feedback from devs and users!
Version 1.5 On Google Play
Version 1.5 On Google Play
Changelog:
Version 1.5 [Nov 15 2012]
Allow changing of Gesture Number (1-30) from Settings
Should be updated in a few hours.
Enjoy!
Flint2 said:
Generate the scripts
I can support many configurations, i'm aware of:
- Yours original (/system/etc/init.d/S50GestureActions) , will need root for remount system and modify file
- DorimanX (/data/gestures_set.sh), no need to be root, only adequate permissions on file
I'm not aware of 3th method that you mentioned.
Do you know other devices besides S2 and S3 or kernels apart from Siyah and DorimanX that have your feature implemented?
If you want to split the config and actions in an alternate setup, I will support it to, these are my suggestions:
- Please keep the writeable config in /data , so no remount and root is needed
- Keep in mind the overhead of forking one more process on each gesture (modular overhead vs. current monolithic approach)
Click to expand...
Click to collapse
Good idea about having the definitions in scripts under /data rather than /system (/etc) so it doesn't require a remount when changing definitions only.
The "bootstrap" main script can be anywhere (even in /data, as long as it's triggered somehow) and the individual files can be in /data/gestures/ or whatever.
Your app should be able to change that, but on the other hand it can't be world-writable since it will be running as root. If anyone can write the definitions, it can hijack control of the phone.
Therefore, it might not be that easy to make it so that your app doesn't require root and still prevent other apps from controlling this sensitive configs.
The main script can be as simple as this:
Code:
GESTURES_PATH=/data/whatever_folder
# Load all gesture definitions, removing comments to reduce the total size
cat $GESTURES_PATH/gesture-*.config | sed -e 's/#.*$//' > /sys/devices/virtual/misc/touch_gestures/gesture_patterns
# Start loop listening for triggered gestures
( while [ 1 ]
do
GESTURE=`cat /sys/devices/virtual/misc/touch_gestures/wait_for_gesture`
# Launch the action script if it exists, not spawning a separate process
GESTURE_SCRIPT="$GESTURES_PATH/gesture-$GESTURE.sh"
if [ -f $GESTURE_SCRIPT ]; then
. $GESTURE_SCRIPT
fi
done ) > /dev/null 2>&1 &
That's it, a universal "bootstrap" script.
It can be installed once on /etc/init.d/S50GestureActions, on /data/gestures_set.sh, or whatever. As long as the bootstrap script is executed somehow, everything else can be handled by your app by editing the config and sh files under the decided $GESTURES_PATH.
As for which kernels do implement the gestures, I don't have a clue. It's easy enough to cherry-pick the code to any kernel, even to other devices, so perhaps the best way for you to check for support within the app would be to check if /sys/devices/virtual/misc/touch_gestures/ exists. If it does, probably it will work regardless of the kernel. The max gestures might not be 30, just to give an example, but the mechanism is there for sure.
Flint2 said:
Review gesture paths
- My idea is to paint every hotspot with finger color and display the sequence number in the path inside it
- Even if i will include parsing and displaying current gestures, for now I think is easy to redo the gesture than to edit or trim it (I can change my mind later on this subject)
- There is no need to keep your second or third finger in the screen all the time, you can just touch on the first point of you imaginary line, lift the finger, and touch on the end of the imaginary line, repeating this start and end points as many times as you like
As long as you keep one finger in the screen, you're still constructing the paths
When you lift last finger, gesture definition is copied to clipoard
So you can define the '5 point ROM exploding thechnique' that reboots in recovery (borrowed from Kill Bill movie)
Click to expand...
Click to collapse
I know, that's exactly the same logic I implemented in the detection code. As long as at least one of the fingers is down, it will still be tracking.
I meant the visual clarity of the path. If a single finger goes through the same hotspot multiple times, as in the example I stated, it might be a bit challenging to draw the hole path at once and still be able to understand it visually I guess it will take some prototyping to see how it works out.
Flint2 said:
Actions
That's exactly what I have in mind, having a set of standard, browsable Androind intents, a set of predefined am , service, cat to config, etc, and a set of custom actions
Changing manually the script should be last resort for advanced users.
I like the idea of maintaining all the configs in scripts, and daemon also in script.
The idea of building a standalone service to replace it has come to my mind but i dislike it.
Click to expand...
Click to collapse
If the bootstrap script + individual files per gestures idea that I presented before does work (if I'm not forgetting any important detail), then a service is not needed at all.
In fact, for the runtime part (the loop detecting gestures and launching actions), it should absolutely be independent of java apps and be solely script-based. Otherwise it will be subject to app lifecycle (stopping app of service depending on available mem), responsiveness of the task scheduler, etc.
Flint2 said:
Thank you very much for your feedback and suggestions!!
Generate the scripts
I can support many configurations, i'm aware of:
- Yours original (/system/etc/init.d/S50GestureActions) , will need root for remount system and modify file
- DorimanX (/data/gestures_set.sh), no need to be root, only adequate permissions on file
I'm not aware of 3th method that you mentioned.
Do you know other devices besides S2 and S3 or kernels apart from Siyah and DorimanX that have your feature implemented?
If you want to split the config and actions in an alternate setup, I will support it to, these are my suggestions:
- Please keep the writeable config in /data , so no remount and root is needed
- Keep in mind the overhead of forking one more process on each gesture (modular overhead vs. current monolithic approach)
I think DorimanX intention is to keep the script always working
May be later I will ask by PM or drop a question in his thread.
Review gesture paths
- My idea is to paint every hotspot with finger color and display the sequence number in the path inside it
- Even if i will include parsing and displaying current gestures, for now I think is easy to redo the gesture than to edit or trim it (I can change my mind later on this subject)
- There is no need to keep your second or third finger in the screen all the time, you can just touch on the first point of you imaginary line, lift the finger, and touch on the end of the imaginary line, repeating this start and end points as many times as you like
As long as you keep one finger in the screen, you're still constructing the paths
When you lift last finger, gesture definition is copied to clipoard
So you can define the '5 point ROM exploding thechnique' that reboots in recovery (borrowed from Kill Bill movie)
Actions
That's exactly what I have in mind, having a set of standard, browsable Androind intents, a set of predefined am , service, cat to config, etc, and a set of custom actions
Changing manually the script should be last resort for advanced users.
I like the idea of maintaining all the configs in scripts, and daemon also in script.
The idea of building a standalone service to replace it has come to my mind but i dislike it.
So far 100+ installs and no FC or bugs reports
I appreciate all the feedback from devs and users!
Click to expand...
Click to collapse
Hi,
my way is to shut gesture script on screen off, is for removing one more loop function, i have one that control many things, if i can do it, so why not
it's shut and start the gestures loop on need.
about GM suggestion to protect gestures loop script is to run it with
/sbin/busybox nohup /data/gestures_set.sh
then this script will never be killed from RAM.
if app run the script, app shell will be closed in time, and "child(our gestures loop script)" will be removed from ram, and stop working...
with the nohup it's has it's own shell that will never stop.
till force killed by:
pkill -f "/data/gestures_set.sh"
it's also NOT detected by
ps | grep "/data/gestures_set.sh"
only by:
pgrep -f "/data/gestures_set.sh"
then you see the PID.
so it's also good in case you will need to RELOAD the loop script via APP.
to use only nohup.
Thanks
dorimanx said:
Hi,
my way is to shut gesture script on screen off, is for removing one more loop function, i have one that control many things, if i can do it, so why not
it's shut and start the gestures loop on need.
Click to expand...
Click to collapse
What's your personal opinion about keeping gesture detection active even with screen off (optional of course), provided the touch screen is still powered, i.e., s2w is enabled?
I've been thinking about adding this optional behavior on the touch processing routine, and that would then require the loop to continue running in order to produce effects.
i was just thinking yesterday that this feature was useless for most of the people but u just made it easy
thanks man

Xposed Module to reduce the unlock area on Lockscreen

Lollipop brought a nice way of giving notification on the lockscreen but on G3, half of the area has been made useless for providing the area to unlock the phone.
Is there any Xposed module which can hide or atleast reduce it so that it can be used for notification?
I know there are lockscreen apps which can be used but I want to use knock code which is not provided by any of them. If any app provide such thing, please let me know.

Theming Omniroms system apk gone wrong?

So I decided to port Material 4.3 by FateNozomi to Omni 4.4..4 framework,UI and Settings,and everything went smooth (at least I thought).After porting,I recompiled all apps without any error.First time I signed them with testkeys provided with singapk.jar and system wouldn't install them,so later I found platform keys with which system would allow installation.
Short after I activated AD in Settings options to realize that I can't read notification nor unlock phone through AD (when ever I click on unlock button nothing happens).Also tried to change Lockscreen shortcuts but when I have to drag unlock ring to assign shortcut nothing happens (ring doesn't expand),and lastly when I activate contextual notif header it just get stuck on one image (if I activate it in morning ,morning.jpg will remain untill the next reboot,wont change throughout the day).
to decompile I used apktool 2.0.3 and as I told,I recompiled with 0 errors (except usual translation missing).
I didn't mod any of these options that are malfunctioning,I even stayed away from every xml that could potentially lead to breakage of any options (hah and in the end got breaks on options I regularly use).
If someone could help I'd be more than happy to listen as I've searched xda through and through and haven't found any bugs or problems that could cause this.
Could it be the platform keys?Apktool mistranslated some strings or resources I honestly have no ****ing clue and its driving me crazy.
Id really need some help being that this is my first "project".
Fixed Lockscreen but not AD
I cross referenced my modded Settings with original and found a miss match in dimensions that fixed LS shortcuts.
I had no luck with AD,so if someone is familiar with omnis active display Ill be more than happy to try any suggestions !!!!!
I also cross referenced modded SystemUI xml related to AD and all matched with originals.
Fixed AD
I found out that I did change some sensitive values for AD,which led to it breaking so I fixed it all.All things that were broken,broke because of my limited to non knowledge of android so I apologize to moderators for clogging this section.
Feel free to delete this thread!!

Categories

Resources