I have seen other methods of removing the gesture or pattern lock but with this method you can remove the lock temporaley and apply it again without knowing the key.
Check it out here http://sud0x3.net/?p=5
What... you mean this: http://forum.xda-developers.com/showthread.php?t=536352
???
Nice find, just a little late.
lbcoder said:
What... you mean this: http://forum.xda-developers.com/showthread.php?t=536352
???
Nice find, just a little late.
Click to expand...
Click to collapse
I did do a few searches, but only found the method that changes settings in the sqlite3 database.
Suppose the method of recovering the pattern from gesture.key file is on here somewhere too then.
sud0x3 said:
I did do a few searches, but only found the method that changes settings in the sqlite3 database.
Suppose the method of recovering the pattern from gesture.key file is on here somewhere too then.
Click to expand...
Click to collapse
As far as I know, it is encrypted.
However, should be fairly easy to brute force given the low number of possible combinations.
lbcoder said:
As far as I know, it is encrypted.
However, should be fairly easy to brute force given the low number of possible combinations.
Click to expand...
Click to collapse
There are a lot of combinations and im not sure how you would go about brute-forcing it, unless you mean by making a comparison list of common gestures then referencing it.
sud0x3 said:
There are a lot of combinations and im not sure how you would go about brute-forcing it, unless you mean by making a comparison list of common gestures then referencing it.
Click to expand...
Click to collapse
This research could be of use but i cant get it to work yet http://moshe.nl/android/
My idea was to hex a load of key files, store them in a db and then compare. But this guy may have really cracked it.
sud0x3 said:
There are a lot of combinations and im not sure how you would go about brute-forcing it, unless you mean by making a comparison list of common gestures then referencing it.
Click to expand...
Click to collapse
Think about it;
There are precisely 9 points. You can't cross a point more than once, and each point you connect to has to be adjacent to the previous one. Each gesture can therefore be mapped to a tree, which you can traverse recursively until the proper pattern has been identified. You identify the proper pattern by encrypting the current pattern using the same encryption used by the phone (which we have source for and therefore KNOW), and comparing that against the contents of gesture.key.
Implementation:
We number each point 1 through 9.
From each point, you can go on to specific "next" points, which include all the adjacent points to that point except for any point that has already been traversed. You recursively test each of the possible next points until all possibilities are exhausted.
Lets say that point 1 is the upper left, counting across (3 is upper right), and then down (4 is below 1), etc.
Your function will basically do this (pseudocode):
Code:
boolean test(gesture_list){
if (encrypt(gesture_list)==gesture.key){
print(gesture_list);
return true;
} else {
for (nextmove in potential_next_moves){
if (test(gesture_list+nextmove)) return true;
}
return false;
}
Do you see how that works?
This is a simple brute force algo for this problem.
The main thing left to you in this is the computation of potential next moves. You can do this manually using a table. The value for potential_next_moves will be the contents of the table MINUS any point that is already within (gesture_list).
I believe that given the small scope of the problem, this will probably take under one second to brute force any key.
What makes this problem much easier for brute forcing is that there are a finite number of possible NEXT values, and this list of possible next values decreases very quickly as the gesture gets longer. For example, when you have 7 spaces filled, there may be AT MOST 2 possible next moves (as few as ZERO -- for example, using this gesture: 1,4,5,6,9,8,7 -- there are no possible next moves from there, so if that gesture doesn't compute, that branch will immediately return false without trying anything further.
Take a more complex brute force.... you have a 512 bit key, then you have 2^512 possible keys to test. Thats 1.34x10^154 -- an unimaginably big number. Even if your CPU could run 1 key per cycle (which it can't, not even close) at 2GHz, that would take you 6.7x10^144 seconds = 2x10^137 years!!! http://en.wikipedia.org/wiki/Brute-force_attack
But again, we have the advantage of no repeated numbers and a fixed/finite selection of next_steps.
sud0x3 said:
This research could be of use but i cant get it to work yet http://moshe.nl/android/
My idea was to hex a load of key files, store them in a db and then compare. But this guy may have really cracked it.
Click to expand...
Click to collapse
Ha ha. Yes. Nice find.
He's doing exactly what I said right above.
BTW: It works perfectly.
And as I predicted, takes under a second to compute.
You will note one thing about it though; if you throw in random data, it will calculate a gesture that is impossible. This is because he is ignoring one of the characteristics that I mentioned: adjacency! It would be much more efficient if he included this characteristic.
lbcoder said:
Ha ha. Yes. Nice find.
He's doing exactly what I said right above.
BTW: It works perfectly.
And as I predicted, takes under a second to compute.
You will note one thing about it though; if you throw in random data, it will calculate a gesture that is impossible. This is because he is ignoring one of the characteristics that I mentioned: adjacency! It would be much more efficient if he included this characteristic.
Click to expand...
Click to collapse
If i were to write something to recover the gesture i would probably either md5 the keyfile or the hexcode then generate a kind of rainbow table list.
example
md5:1234
md5:2345
md5:5321
Then you could compare md5 hashes to find the correct key. This would eliminate the problems in the script above.
lbcoder said:
Think about it;
There are precisely 9 points. You can't cross a point more than once, and each point you connect to has to be adjacent to the previous one.
Click to expand...
Click to collapse
You can cross a point more than once, I do it in my unlock.
Related
Hi,
I NEED TO ACCOMPLISH THE FOLLOWING
Displaying a series of random images during a shake,
Activate the accelerometer and timer on button click
increase the speed random images are displayed with the increased speed of shaking
HOW WOULD I ACCOMPLISH THESE?/WHAT IS THE SYNTAX FOR THESE?
thanks
Did you have a question?
Gene Poole said:
Did you have a question?
Click to expand...
Click to collapse
Mod edit: flaming and personal attack removed
OP, can you stop making personal attacks against another member.
I had to remove your edit reason for what you said to someone replying, and a personal attack against him.
XDA doesn't tolerate this, and we ask that you do not do this again.
isn't the accelerometre on all the time?
I can check to see what the coding would be for this in the app inventor, (gonna have to figure out how to make it do just that first, but should be alot easier than manually coding it, right?)
OK well i have completed almost all of this except for activating the onSensorChanged by a button click. As well as initiating a timer on the button click that will stop the onSensorChanged listener when time is up.
EDIT: Feb 14 / 2012 - Wow. It has been a while. I pre-ordered one of the original DVPs, went on the roller-coaster ride of trying to get it SIM unlocked, returned it to Dell and took the 15% restocking hit, then watched in agony as a simple "just email Dell" free unlocking solution came available about a month later. I've had a second-hand HD2 through most of 2011, running various builds of WP7 and Android, until the digitizer bit the dust. Just snapped up a DVP on eBay - I'm back baby! Time to update this thread.
Whether you're a DVP owner, future owner or still on the fence about a purchase, it might be useful to have a single thread listing the known issues with this model (and any discovered fixes, workarounds, etc.). I'll try to keep this up-to-date based on comments below. Have I missed anything?
Compass driver broken by Mango update
Much-discussed; interop unlock or custom firmware would allow a fix (i.e. flashing an unsigned cab could potentially put the old driver back)
No HSPA or roaming triangle indicators
Diagnosis: software issue... can't get an "H" or triangle symbol to appear in the relevant contexts.
Apparently this is only an issue on TMO-US branded units, and it is entirely cosmetic. Interop unlock would allow us to make the necessary registry edits to bring back the HSPA indicator.
Camera: slow shutter speed = blurry indoor shots
Partially improved in successive firmware updates
Flaky reception
Somewhat improved, according to user reports.
Cell radio: drops connections when switching from 2G to 3G
Fixed by Dell in new units.
WiFi: some devices can't connect to secure networks
Fixed by Dell in new units.
SIM: error
Fixed by Dell in new units.
Windows Phone 7 general issues
No copy & paste
Fixed in NoDo
Email: forwarding from non-Exchange account uses .eml attachment instead of inline text
Fixed
Camera: issues with retaining settings
Fixed
Headphone jack: curved, bad connection?
I don't think the headphone Jack poor connection is explicitly caused by the curved jack. Checking out my friends HTC desire, I noticed that it too has a curved jack that doesn't completely cover the headphone plug.
jcoob said:
Headphone jack: curved, bad connection?
I don't think the headphone Jack poor connection is explicitly caused by the curved jack. Checking out my friends HTC desire, I noticed that it too has a curved jack that doesn't completely cover the headphone plug.
Click to expand...
Click to collapse
Thanks. I'm partly basing this on a youtube video from a DVP owner who demonstrates how the earphone jack won't plug all the way in, because of the curved design.
Can any actual DVP owners comment on this? Is the problem widespread?
RE: SIM locking of Dell Venue Pro
Note: the following threads discuss DVP-US frequencies, possible SIM-locking to T-mobile (even for off-contract, paid-in-full devices), etc.:
http://forum.xda-developers.com/showthread.php?t=858181
http://forum.xda-developers.com/showthread.php?t=857572
http://forum.xda-developers.com/showthread.php?t=838105&page=51
Awesome thread, love the idea & I haven't really heard much of the issues listed here but its great that you put it out there.
Hopefully many get fixed in the upcoming update in January or even the new devices.
Many don't seem to apply to me like the camera since I rarely ever use the camera but the 2G to 3G one is pretty big.
The camera was bad in the first phone I received (Engineering Sample) but in the next phone the Cam was alright. This unit didn't have that slow shutter problem
The images were comparable to HD7.
benjaminries said:
Whether you're a DVP owner, future owner or still on the fence about a purchase, it might be useful to have a single thread listing the known issues with this model (and any discovered fixes, workarounds, etc.). I'll try to keep this up-to-date based on comments below. Have I missed anything?
Camera: slow shutter speed = blurry indoor shots
Reported here: http://forum.xda-developers.com/showthread.php?t=841391
Diagnosis: since the camera EXIF reports that it is the same hardware as the iPhone 4, hopefully this can be fixed via software patch
Solution: might have been fixed in updated device ROM? (thanks eyan15 - http://forum.xda-developers.com/showpost.php?p=9552249&postcount=6 - can somebody confirm?)
Camera: issues with retaining settings
Reported here: http://en.community.dell.com/dell-b.../19/where-we-are-with-the-dell-venue-pro.aspx
Diagnosis: software bug
Solution: unknown
Cell radio: drops connections when switching from 2G to 3G
Reported here: http://forum.xda-developers.com/showthread.php?t=839051
Diagnosis: radio firmware issue?
Solution: unknown
Headphone jack: curved, bad connection?
Reported here: http://en.community.dell.com/dell-b.../19/where-we-are-with-the-dell-venue-pro.aspx
Diagnosis: hardware design flaw?
Solution: unknown
WiFi: some devices can't connect to secure networks
Widely reported
Diagnosis: firmware bug
Solution: these units can be exchanged at their source
SIM: error
Reported here: http://www.electronista.com/articles/10/11/23/dell.venue.pro.sim.card.flaw.among.many.issues/
Diagnosis: firmware bug or hardware issue
Solution: these units can be exchanged at their source
Windows Phone 7 general issues
No copy & paste
Widely reported
Diagnosis: missing feature
Solution: OS update in January 2011 will add clipboard functionality
Email: forwarding from non-Exchange account uses .eml attachment instead of inline text
Reported here: http://wpcentral.com/windows-phone-7-email-bug-discovered-when-forwarding-non-exchange-accounts
Diagnosis: software bug
Solution: unknown
Click to expand...
Click to collapse
Might want to add these to the Windows phone 7 list:
1) No real multi-tasking support to speak of in phone 7, even the "back" button doesn't bring you back to an active program in most cases, but the program has to re-initialize.
2) No support for mobile hotspot function in phone 7
3) No true "live tile" support for 3rd party apps (like twitter etc...); more like dead tiles.
I am concerned that the speed of WP7 is dependent on only having 1 app running and therefore MS doesn't want multi-tasking.
sureloch said:
Might want to add these to the Windows phone 7 list:
1) No real multi-tasking support to speak of in phone 7, even the "back" button doesn't bring you back to an active program in most cases, but the program has to re-initialize.
2) No support for mobile hotspot function in phone 7
3) No true "live tile" support for 3rd party apps (like twitter etc...); more like dead tiles.
I am concerned that the speed of WP7 is dependent on only having 1 app running and therefore MS doesn't want multi-tasking.
Click to expand...
Click to collapse
This stuff crosses over into general criticisms of the OS. I'm trying to restrict bugs to things that were obviously overlooked or have been announced as upcoming fixes - not new features or disagreements over design.
This is an Windows Phone 7 bug, all devices suffer from this. So while this is an issue nonetheless, you should not decide not to get the Dell Venue Pro based on this 'bug' alone. If you want a Windows Phone 7 device, you will have this problem, hopefully Microsoft will fix it in the next update.
Camera: issues with retaining settings
Reported here: http://en.community.dell.com/dell-bl...venue-pro.aspx
Diagnosis: software bug
Solution: unknown
Click to expand...
Click to collapse
KilZone said:
This is an Windows Phone 7 bug, all devices suffer from this. So while this is an issue nonetheless, you should not decide not to get the Dell Venue Pro based on this 'bug' alone. If you want a Windows Phone 7 device, you will have this problem, hopefully Microsoft will fix it in the next update.
Click to expand...
Click to collapse
Thanks for the correction; I was under the impression that each OEM made their own customized Camera app. Curious if they all suffer from the same problem - hopefully that means it will be fixed in the January update.
eyan15 said:
The camera was bad in the first phone I received (Engineering Sample) but in the next phone the Cam was alright. This unit didn't have that slow shutter problem
The images were comparable to HD7.
Click to expand...
Click to collapse
This is the only thing preventing me from ordering this phone. Can anyone else confirm this issue has in fact been resolved?
seatown1two said:
This is the only thing preventing me from ordering this phone. Can anyone else confirm this issue has in fact been resolved?
Click to expand...
Click to collapse
We might not get this confirmed until late December - as far as I can tell by the forums, many of the early birds who got their DVPs from the Microsoft Stores are still waiting on replacement units. Hopefully one or two other people who have already got a good replacement can chime in here, but I fear we won't know the status of these issues until the big wave of online orders start shipping out.
Call me crazy, but I think that if this is a simple software issue, Dell will fix it. In the alternative maybe we'll see some homebrew camera apps next year that we can sideload
sureloch said:
Might want to add these to the Windows phone 7 list:
1) No real multi-tasking support to speak of in phone 7, even the "back" button doesn't bring you back to an active program in most cases, but the program has to re-initialize.
2) No support for mobile hotspot function in phone 7
3) No true "live tile" support for 3rd party apps (like twitter etc...); more like dead tiles.
I am concerned that the speed of WP7 is dependent on only having 1 app running and therefore MS doesn't want multi-tasking.
Click to expand...
Click to collapse
1. That is the fault of the developers of the apps. The OS supports save states so when you go back it resumes where you left off. You can see this in OEM apps like IE, but the 3rd party browsers don't do this.
2. Not sure if that is in the works
3. Since when? Weatherbug, weather channel, flixter, beez twit app all support live tiles.
nrfitchett4 said:
1. That is the fault of the developers of the apps. The OS supports save states so when you go back it resumes where you left off. You can see this in OEM apps like IE, but the 3rd party browsers don't do this.
Click to expand...
Click to collapse
This is an interesting one. I agree with you that a lot of this is developer-related, but I think Microsoft will still end up making some adjustments to multitasking next year. Remember that the internal system apps (like IE) are permitted to do true background multitasking by the OS, while 3rd-party apps aren't.
I have read that the save state thing is kind of tricky because apps often don't get a warning that they are about to be put to sleep - the OS just responds instantly when you hit "back" or "home". So the only apps that can take advantage of this feature are the ones that are saving their state all the time - which is only practical for some app designs. A 3rd-party music or video app might make a record of whatever song or video you're watching, but must it save the elapsed track time every second? Every 10 seconds? Whatever granularity is chosen will be the state you can return to after the app loses focus.
MS needs to allow true background multitasking/threading in a few limited situations:
- the app loses focus, receives a "save your current state" message from the OS, and is allowed to save its state in the background
- the app sends a tiny bit of data to the cloud every 5 minutes (i.e. Google Latitude) - MS could maybe impose a "maximum lines of code" on this upload function?
- the app does a tiny bit of processing with the push data it gets from the cloud, without necessarily getting user interaction
I believe allowing these three types of multitasking would really open up possibilities for developers.
What you say is not entirely true. Applications do receive a warning when the system is going to navigate away from the application, just the way like you suggest it as the first option. However in practice it is a little more complicated than that.
There are 4 events in Windows Phone 7, Launch/Close and Activated/Deactivated. The first two are just the startup and closing of the two while the latter is the tombstoning warning and retrieval event. So when your application receives it's 'deactivated' message, it is allowed to do some final saving of it's state (there is a time limit, but it's rather flexible). Windows Phone will navigate away even though the save state hasn't been completed yet, so that part of 'multi-tasking' is implemented.
The problem you all mention comes from the fact that 'home' and 'back' are not the same for 3rd-party applications (and even some internal ones). Back is generally seen as 'back one page' and 'home' as 'go to the start screen'. However if you are 1 page away from the home screen, the 'back' button will act as 'close' button... So it will sent a 'close' event to the application, rather than the 'deactivated' event (and not allowing the application to tombstone itself). This way, the next time you boot the application it will restart as it will receive the 'launch' event and not the 'activated' one. Easiest 'solution' is to use the 'home' button instead, however this will mess up your 'back'-botton behaviour a little.
benjaminries said:
[...]I have read that the save state thing is kind of tricky because apps often don't get a warning that they are about to be put to sleep - the OS just responds instantly when you hit "back" or "home". [...]
Click to expand...
Click to collapse
Basically I think Microsoft needs to 'fix' the 'back'-button acting as 'close'-button, as no-one thinks it will act this way.
KilZone said:
What you say is not entirely true.
Click to expand...
Click to collapse
LOL, it sounds like I was pretty darn close for a lay-person. I don't have a WP7 device yet, but tell me, how often to do you navigate away from an app OTHER than by going to the homescreen? The only other way I can imagine is by accepting some kind of toast push notification, pressing the Search button or the Camera button.
The bottom line is that MS intended to do this better - but as you have said, apps are often losing focus in a way that doesn't even allow the app to save its state, even if it has been designed to do so. Apps should be given a chance to save their state whether they're being minimized or closed, so they can return to the last state whether they're being woken up or started fresh.
You were quite close indeed and you're right that this is quite an irritating bug (Microsoft might say it's a feature, but let's keep it at a bug for now). Mostly because as a Windows Phone user you have no idea when an application 'closes' or 'tombstones'...
benjaminries said:
LOL, it sounds like I was pretty darn close for a lay-person. [...] The bottom line is that MS intended to do this better - but as you have said, apps are often losing focus in a way that doesn't even allow the app to save its state, even if it has been designed to do so.
Click to expand...
Click to collapse
Agreed, I think you have a valid point there. It certainly would increase the multi-task-experience (even though it is not true multi-tasking) as all applications would seem as if they were running next to eachother (as was the idea initially). It might be nice if an application could implement 'tombstoning' when it receives the 'close' command, which is not available right now (no access to the tombstoning service).
benjaminries said:
Apps should be given a chance to save their state whether they're being minimized or closed, so they can return to the last state whether they're being woken up or started fresh.
Click to expand...
Click to collapse
nrfitchett4 said:
1. That is the fault of the developers of the apps. The OS supports save states so when you go back it resumes where you left off. You can see this in OEM apps like IE, but the 3rd party browsers don't do this.
2. Not sure if that is in the works
3. Since when? Weatherbug, weather channel, flixter, beez twit app all support live tiles.
Click to expand...
Click to collapse
I hope you are correct as I have ordered thte dvp, but though the suspend/resume multi-tasking sounds like a good idea, it seems extremely weak in practice.
Here is a clip showing the types of behaviors that concern me including the live tile issue.
http://www.youtube.com/watch?v=DNfpPrto07Q&feature=related
WP7 is a very elaborate and beautiful operating system which must require heavy resources to accomplish. Perhaps we will have to wait for dual core devices before we will see WP7 multi-tasking like we would hope. But it seems like the caching and accessing current tasks to preserve resouces could be done more effectively, and would definitely improve the user experience.
KilZone said:
Agreed, I think you have a valid point there. It certainly would increase the multi-task-experience (even though it is not true multi-tasking) as all applications would seem as if they were running next to eachother (as was the idea initially). It might be nice if an application could implement 'tombstoning' when it receives the 'close' command, which is not available right now (no access to the tombstoning service).
Click to expand...
Click to collapse
The App Style Guide is clear about the 'right' app behaviour, and I'm sure Microsoft consider it a feature, not a bug. It enforces a set of rules that they just expect users to get used to:
1) Switching away from an app (e.g. hitting search or launch) should leave the app in a state where you can come back to it (and pick up again from where you left off) by pressing the back button.
2) The way to terminate an app is to 'back out' of it. Once you have terminated an app, you can't come back to it.
3) Whenever you launch an app from the menu, it will start from scratch.
Microsoft's own apps follow this pattern.
These rules are intended to give the feeling of 'all apps existing in a stack' (like the stack of navigations you move through when using a web browser). I think that represents a conscious design decision on Microsoft's part ... maybe a bad design decision, but not a bug as such.
By the way, an app can trap and modify the behaviour of the 'back' key. Actually, the developer has to do this, to ensure that the app does the right thing in all cases (for instance, if the app has a popup dialog open, the 'back' key will close the popup dialog, not back out of the app). This does give the app a chance to respond to the 'back out' action, by saving state or by putting up a 'do you really want to quit?' message. But Rule #3 above means that when the app is restarted, it has to look like a new instance of the app, not a continuation of the instance that the user terminated.
Jim Chapman said:
But Rule #3 above means that when the app is restarted, it has to look like a new instance of the app, not a continuation of the instance that the user terminated.
Click to expand...
Click to collapse
Interesting. It would be nice if there was at least some subtle little toast or something like "do you want to pick up where you left off?", maybe just for apps that are super-complex, at the developer's discretion.
Whatever MS and developers did, I'm glad that MS appears to recognize that users aren't super happy with the outcome - I believe we'll see a change in the second update of 2011.
okay, so apparently SCEF02 FW users r stuck with video recording fps drop when recording in low light conditions (and no official solution from samsung yet)
more about the problem here:
http://forum.xda-developers.com/showthread.php?t=1443658
the only FW that seems to fix the problem is the SIEG03, which indicates that the problem is software related and CAN be fixed
however it disables flash in video recording mode & LED torch
so can't the devs figure a way to edit SIEG03 firmware to give us flash support?
links that may help (thanks bartekaki for providing it):
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
personally, I'll pay 10$ if it happens (or more if necessary)
who else???
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
suzaku said:
https://github.com/GalaxySII/samsung...a/video/m5mo.c
Click to expand...
Click to collapse
Dude, you can't even copy/paste links from others's posts...
I'll chip another 10$.
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
bartekaki said:
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
Click to expand...
Click to collapse
thx man
radkor said:
Dude, you can't even copy/paste links from others's posts...
Click to expand...
Click to collapse
I thought that since I linked to the original whole thread then it's ok...sorry I'll fix it
karendar said:
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
Click to expand...
Click to collapse
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
suzaku said:
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
Click to expand...
Click to collapse
SIEGE03 is a firmware. This firmware is required to run the camera... To access the camera functions, we need a driver. This driver is compiled from source code which is what the link above is...
What probably happened here is that the Infuse uses the same camera module and interface. The flash though might use a different register or address scheme in the source code of the Galaxy S2 to interface with the firmware. So someone would have to figure out the difference between the m5mo.c source code from the Galaxy S2 and the I997 to see if it can be fixed through driver. Otherwise we'd have to reverse engineer the firmware which is too much energy wasted.
The problem with this method is that we'll need to compile a new version of the camera driver. And that, I am not the person to do it.
Another solution would be to pull the camera driver from a stock I997's ROM and overwrite it on our phone to see if it works.
I got a galaxy s2 here last friday (coming from a htc desire), and this week i got around to using the camcorder function. Immediately noticed the stutter issue, checked the forums and the current firmware situation, and switched out my SCEF02 for the SIEG01. Of course it fixed the stutter but broke the flashlight, so i spent an evening looking into fixing it. Here's how far i got...
The firmware binary
First of all the SIEG01 firmware binary itself. I did a hex compare with SCEF02 and there are so many differences (hundreds when set to 16 byte difference comparison) it'd be almost impossible to find the incorrect memory address for the flashlight function control (at least in my limited ability).
Next up i tried looking for seperate sections within the firmware to frankenstein a fix. There was only one certain boundary i found with an identical address, that's around the 166FF area, where both files are padded with FF's to the same position (following is ASCII denoting the firmware version). That's a pretty clear indicator that it's a seperate part of the rom, so, i switched out the bottom half of SCEF02 into SIEG01. The result was no stutters, no flashlight. Likewise replacing the bottom half of SCEF02 with that of SIEG01 resulted in stutters and a working flashlight.
So in short, regarding the firmware itself, the section controlling the flashlight function is somewhere before 166FF in the binary. Everything in that first half of the firmware is reasonably similar between the two firmwares, but not identical. Mostly it's single byte changes (probably just the same variables stored in different addresses), and most of the similar sections are offset by roughly a word of data or more. I didn't spend hours looking through to discover where the extra words of data crept in though.
The driver
You could spend weeks tinkering with values within the first 1300KB of the binary trying to find the flashlight section alone, never mind the specific variable/register for the flashlight mode itself, so i moved on to checking the right values were being set by the driver (m5m0.c).
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
the relevant function appears to be m5mo_set_flash on line 858, and the function works pretty simply. First there's a case switch to set the values of two variables called flash and light which will be sent to the firmware. The final case is the one for the flashlight function, and needs flash to be -1 and light to 0x03:
Code:
case FLASH_MODE_TORCH:
light = 0x03;
flash = -1;
break;
If flash is less than 1 then no control command is sent to the firmware for the flash, so we can disregard that (i think). That just leaves the light function. i'll just quote the code here:
Code:
m5mo_writeb(sd, M5MO_CATEGORY_CAPPARM,
M5MO_CAPPARM_LIGHT_CTRL, light);
m5mo_writeb is the function sending (writing) the command to the firmware, sd i believe is the device itself, M5MO_CATEGORY_CAPPARM and M5MO_CAPPARM_LIGHT_CTRL are describing where to send the value of light to, on the device. I think it's safe to say M5MO_CATEGORY_CAPPARM is correct since the flash works fine and the same constant is used for the flash control code directly below the light code. It's also used for a bunch of other functions such as capture size etc.
In C code, variables that're defined in all uppercase are usually constants, so you need to go into m5m0.h to find the value for M5MO_CAPPARM_LIGHT_CTRL. line 272 will show you "#define M5MO_CAPPARM_LIGHT_CTRL 0x40". For the sake of being sure, line 180 also has "#define M5MO_CATEGORY_CAPPARM 0x0B".
Time to check out the Infuse source code and compare...
https://github.com/Entropy512/linux_kernel_sgh-i997r/tree/master/drivers/media/video
first of all m5m0.c, line 1411 you'll find m5m0_set_flash. The layout of the function is slightly different, it's still a switch case, but instead of using temporary variables to hold the values to send the flash and light, the values are just sent within the cases themselves. Anyhow, the light control section:
Code:
case FLASH_MODE_TORCH:
err = m5mo_writeb(client, M5MO_CATEGORY_CAPPARM, M5MO_CAPPARM_LIGHT_CTRL, 0x03);
CHECK_ERR(err);
break;
Again no command is sent to the flash, only the torch, and that value is 0x03 again. The same function and arguments are being sent as with the i9100 code earlier, so all that's left is to check the constants being used. Time to hop to m5mo.h for the infuse.
Line 183 "#define M5MO_CATEGORY_CAPPARM 0x0B" matches our i9100 driver. Line 282 "#define M5MO_CAPPARM_LIGHT_CTRL 0x40" matches our i9100.
Now there are some differences between the m5m0_set_flash functions and also in the m5m0_writeb functions for the two devices, but the values they're using to control the light are the same in both cases.
One thing of interest is that the infuse doesn't support autoflash which is light 0x04 and flash -1. However if you hook up the phone to your pc, run ADB and use the camcorder in low light or any flashlight apps, you can use dmesg to verify 0x03 is being sent, as the dmesg output will contain "m5m0_set_flash: E, value 0x03".
Essentially i think this rules out it being a driver issue. I mean i could be wrong, but it looks like the flashlight control values are identical for both devices. It seems like the issue is within the first section of the firmware binary, somewhere.
Hopefully this is of some use to anyone looking into a fix for the SIEG01 flashlight problem.
Thanks for share your investigation Myshkinbob. Very interesting.
I do believe is an "easy" firmware fix too.
As you did, i compared both firmwares binaries and took the hope for finding the flash part in the code. Without a reference there is too many unknown data for a trial and error. I mean i tried to copy-paste some code differences in the firmwares but no succes.
Since nothing looks broken i will keep trying...
It'd be good to get SGS II simulator on Windows. Without it, it's PITA to load every time APK into phone and reboot it to test one variable lol
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
wish i could help somehow...
Myshkinbob said:
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
Click to expand...
Click to collapse
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
suzaku said:
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
Click to expand...
Click to collapse
I'm pretty sure that's how samsung codes anyway, we're just lending them a hand in doing so. haha
how's it going guys? any news?
wish I could help but I'm a complete noob
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
blunted09 said:
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
Click to expand...
Click to collapse
Well this firmware really improves the overall quality of the pics but in shooting vids it really shines. Only thing so far missing is flash light during video capturing.
I would have moved to SIEG03 if it had had support of LED
me too, flashlight is a little bit to important for me
Unfortunately Niantic contacted me to abort this mod. More info: http://forum.xda-developers.com/showthread.php?p=42027875#post42027875
TL;DR version: I have created an Ingress app mod, it is awesome and will make you coffee. You can download it below.
OVERVIEW
Hi,
after more than a 2 years of inactivity in the modding field I'm back with a new mod. This time it's Ingress app. I think and hope it'll be much greater and more advanced than Google Maps mod. There are a lot of things to improve and I think some of them won't be ever added by Niantic, so it's a good idea to mod this app.
First I want to clarify I will never add any kind of cheating to this mod. My goal is to make Ingress game more enjoyable, not less. Questions about location faking, items cloning, etc. are not welcome here. I'm serious. Still if you think this mod is a bad thing and/or if you're from Niantic then please read a section about my motivations below and feel free to ask, suggest or criticize. I make it for Ingress players and I'm very interested in their opinions.
DOWNLOAD
First: you do this at your own risk! I'm sure it won't brick your phone, but remember you may be banned by Niantic. My mod doesn't do any kind of cheating behavior, it doesn't do anything that original app doesn't do, but there is always the risk.
Also if you downloaded apk from different site then check sha1 of this file to make sure it's ok. Unfortunately such mods create good opportunity to inject some malware, because users search for an application in the internet and anyone can redistribute it. I sign this app with my own keys, so if you have installed my mod earlier, now you have downloaded newer version from the internet and Android says it has different certificates then don't install it!
"Mute" variant has all sounds removed, so apk is ~2.5 times smaller and most likely it uses less memory.
ingress-1.26.1-broot-0.2.0-mute.apk
SHA1: 976342081c963998f8a6e56b735fe97581ab335f
ingress-1.26.1-broot-0.2.0.apk
SHA1: dce5399802c8f11287a7cf399c1bb5265f8251e2
Older versions:
ingress-1.26.0-broot-0.1.0.apk
SHA1: ea95d8e36324c6c4a175e0cf254cd65a4797049f
If you have original Ingress app installed then you have to uninstall it first. Same if you want to install original app over a modded one.
FEATURES / TODO LIST
I know simplifying and automation of too many things may be considered cheating, so I have divided all features into several categories: from the most "innocent" ones to some smart assistants. As I stated above, if you think some of them are just too much then feel free to write about it. For me features up to 3. category are ok. Category 4. may be controversial and I'm not sure if I want to implement it. I'm glad for your opinions. Some features (e.g. 2.11., 3.7.) aren't actually related to category descriptions, but I "feel" them as category 2., 3., etc.
I don't want to force people to use every modification, I'll try to make them all opt-in, so modded app will work exactly as the original one until you change this in the mod menu. If you see e.g. "Fullscreen" feature below then read it as "An option to enable fullscreen mode".
Below is just a list of features to make it clear. Descriptions, notes, statuses, implementation proposals, etc. are here.
Legend:
green - completed
orange - not sure about it
red - rejected
black - waiting / todo
1. Changes strictly technical and/or 4fun - they don't affect gameplay at all:
UI for small screens, but this is never ending task
Disable some graphics effects to make it less GPU consuming:
portal particles
xm particles
Fullscreen.
Remove globe intro.
Change colors of factions.
Exit confirmation dialog - it's good for low memory devices.
Keep sceen on.
Disable vibrator.
2. UI changes: new screens, shortcuts, etc. - it makes things easier, but it won't do anything for you:
New screen with mod settings, credits, etc.
New inventory screen with items presented as a clear table.
Number of all items in the inventory - it's very important because of items limit.
New portal keys screen.
Remove original items screen.
Shortcuts to various actions from the main screen.
Modify chat to make it easier to read and harder to accidentally send private message to public channel.
Link to portals from system messages in the chat.
Real-time distance to portal on details and upgrade screen - its necessity is obvious to anyone who played Ingress
Additional info about the portals directly on the map screen.
Logging and statistics.
Circles around the player similar to one at 40m - just for better feeling of the distance.
Number of keys on portal info, upgrade and linking screens.
Config: update interval.
Config: maximum scanner zoom out.
Deploy button uses highest available resonator, not lowest.
3. Automation of some more complicated or repetitive tasks - it delegates multi-clicking to the squad of highly trained monkeys, but it won't think for you:
Dropping/recycling multiple items of the same type at once.
Firing multiple XMP
Picking up all items in the range - with above it's very easy to give items to other agents.
Hacking all portals in range - not very useful because of timers
Auto deploy resonators using a template.
Templates specific to a portal.
Other agents presence detector.
4. Smart assistants:
Hacking timers for each portal: both 5m and 4h ones.
Auto hacking portals in range while moving (using timers).
Smart auto-deploy.
XMP damage assistant.
Linking assistant for optimum CFs in a specific area.
Continuous linking assistant.
Bugs:
The maps are gray when submitting new portals or reporting bad ones.
NEWS
v1.26.1-broot-0.2.0 has been released!
2013.05.26
Updated Ingress to 1.26.1.
Added layouts for small screens: Eugene's 1.26.0.20130526
Added mute version - for smaller size and likely smaller memory usage.
Added fullscreen mode.
Added option to disable portal particles and xm particles.
Added restart button - it's useful for reloading UI changes (fullscreen mode, layouts, etc.).
Fixed gray maps problem.
v1.26.0-broot-0.1.0 has been released!
2013.05.22
Initial version.
New screen with mod settings, credits, etc.
New inventory screen with items presented as a clear table.
Number of all items in the inventory.
CREDITS
Eugene Kartashov - layouts for small screens.
Of course Niantic Project for this awesome game!
Thanks!
FEATURES DESCRIPTION AND NOTES
1.5. Change colors of factions.
I did this before and it's kind of cool: https://plus.google.com/u/0/106080343103638200670/posts/a9krpWApjz5
2.4. New portal keys screen.
I have some ideas, e.g.:
keys grouping/tagging
group/tag keys manually or automatically by their location, name, etc.
filters and sorting by: name, distance, level, owner, etc.
, but I think Niantic want to improve keys management, so I wait for their move.
2.5. Remove original items screen.
For now even if you prefer new items screen the original one is still needed to access portal keys. We can wait for 2.4. or at least add an option to limit original items screen to portal keys and rename it accordingly.
2.6. Shortcuts to various actions from the main screen.
I think it's one of the most important additions, so it has to be well designed. I see it as a HUD-like buttons similar to "FIRE XMP" when you long-press on a map, but much smaller, probably square with icons. Things to consider:
toolbar at the top or the bottom of the screen - I think it's better than left/right
fixed with 5-6 icons (4" screen) or scrolling horizontally
fixed icons or customize them and their positions
an option to open a full semi-transparent menu with all available actions
Actions could be:
fire last XMP
fire highest/lowest XMP
fire XMP of specific level
same for power cubes
hack portal - click button then click portal. This way you don't have to enter portal details screen which is faster and you don't lose the map.
link portal - same as above
set target? It's in a long-press menu already, but we can add it here for consistency and maybe to remove long-press menu.
actions from other mod additions
2.7. Modify chat to make it easier to read and harder to accidentally send private message to the public channel.
Current problems are:
is there anyone who has never sent a private message to the public channel? Is there anyone who did this only once or twice?
it's hard to read conversations between agents, especially public ones, because they're mixed up with system messages
I was considering adding some kind of filters to select which types of messages you want to see, but it doesn't fix first problem. Now I think of something else - 4 tabs/channels:
faction - as normal
public - public conversation only, so system messages won't disturb you and you don't accidentally respond [secure] messages
system - you can't send a message here
all - all above, so it's similar to current "All", but you can't send a message here - you have to choose proper channel intentionally. It can have additional filters to select messages to show.
This feature may be hard to do or even impossible, because most probably Ingress server doesn't have API to filter messages as above. Of course I can read "All" channel and filter it on the app side, but it may not be that good.
Also I won't be surprised if Niantic itself will redesign chat in the near future, because it's definitely wrong.
2.10. Additional info about the portals directly on the map screen.
E.g.: level, if you have a key (how many?), etc. It could be customizable and there could be a shortcut to toggle showing this info.
2.11. Logging and statistics.
I love this one I can log all kind of actions like: hacking, attacking, dropping and picking up items and XM, deploying resonators and portal mods, adding custom "snapshot points" to organize above, etc. and then create a lot of various statistics:
how many hacks did you do (faction, enemy, neutral) today, in last week or month?
how many items did you get from these hacks?
what were the levels of hacked portals and items?
how many XM did you get?
how did you spend this XM?
how many resonators did you deploy and what were their levels?
how many resonators did you destroy, how many portals did you capture?
how many links and CFs did you create/destroy, what were their MU values?
which portals do you hack/attack/build most often?
how much time you was playing?
what items did you spend to build up a farm and what items did you get from it?
Statistics could be tabular, graph, pie and very flexible. I'm also considering two things:
sending some of above statistics to my server to create global statistics for all users. It would let us do some research, e.g.: what is the probability to get L7 item from L6 portal, etc. Of course sending these statistics would be fully optional, you would have to enable it by yourself.
optional paid application to read these statistics - in addition to the free one. It could let you remove ads or just say "thank you" (i.e. it would be the same as free one), but I don't want to piss off someone in Niantic. I think it would be fair, because statistics app would be quite complicated and time consuming and there will be free version, but you never know what's the opinion of other people.
What do you guys think about above two things?
3.5. Auto deploy resonators using a template.
Agent can configure multiple templates and choose one of them when doing an auto-deploy. Template could be defined by:
its name
minimum and maximum level for each resonator
prefer lower/higher level for each resonator
Examples:
"Lowest portal" - each resonator set to L1-L8 and prefer lower for all - it's the same as clicking "deploy" 8 times.
"Highest portal" - L1-L8 and prefer higher for all
"Highest <L7" - L1-L6, prefer higher for all
"Standard L4" - L1-L6, L1-L4, L1-L5, L1-L4, L1-L6, L1-L4, L1-L5, L1-L4, prefer higher for all - it's standard 4xL4 2xL5 2xL6 and it'll use lower resonators if you don't have all of them
another "Standard L4" - same as above, but L6-L6, L5-L5 and L4-L4 - it won't automatically downgrade resonators, but warn you about the lack of resonators
Also some templates could be predefined by default.
It won't work well with existing resonators, it won't choose optimal way to upgrade them, but this is how it should be - it's just: "do it using a template", not: "Calculate optimal situation".
3.6. Templates specific to a portal.
Extension to above: sometimes you know that e.g. NE resonator of some portal is harder to destroy, so you want to place highest resonator there. You can create a template specific to a portal, so it won't mess up main list of templates and it will be auto selected when doing auto deploy for this portal.
3.7. Other agents presence detector.
It read system messages log to find the last actions and positions of other agents (actually positions of portals they've built/attacked). This information could be used to e.g.:
show last position and action of specific agent
show a list of nearby agents: allied or enemy
alert if some other agent will show up below specific distance from you
4.3. Smart auto-deploy.
E.g.:
calculate max level of a portal that you can build alone - depending on your inventory and already deployed resonators
deploy minimum number and optimum resonators to get to specific portal level
prioritize excess resonators and save scarce ones
deploy high and low resonators evenly to make attacking a little harder
if upgrading existent resonators, prefer to upgrade ones with low XM
4.4. XMP damage assistant.
E.g.:
approximate damage dealt using specific XMP in current position
calculate the best spot to fire XMP of some level
4.5. Linking assistant for optimum CFs in a specific area.
You select a group of nearby portals, assistant build links and guide you through place to get as many CFs and AP as possible.
4.6. Continuous linking assistant.
You see an icon near the portal if it's possible to create a link(s) from it to create a CF. It let you create this CF with few clicks.
It may be not possible to do, because it would have to scan big area to know if there are a link between remote portals.
MOTIVATIONS AND FEW WORDS TO NIANTIC
As I stated above my goal is to make Ingress game better and more enjoyable for people. If you think it's evil then please read my motivations and explanation below:
There aren't and never will be features for cheating: location faking, sending same action several times, automatic passcode submitter, etc.
As I said above I have divided mod features into categories of different "dirtness level". I focus on "clean" features and I'm open to suggestions or criticism from players or even from Niantic itself.
I don't share my code and I obfuscate it to not make Ingress easier to hack by other people.
A whole game and world of Ingress is about hacking and reading between lines. I think my mod fits this world perfectly. There are some people who leak Ingress app from NIA and there is some guy somewhere in the internet who tries to get even more from it. It makes perfect sense
I think there are many good features that will be never added by Niantic. I see several reasons: statistics won't be added because it doesn't make much sense for storyline. Why NIA would add such feature? Intro skipping or new items screen won't be added because these features prioritize quick access over a nice look. Niantic can't do the same because Ingress would look like a game for nerds. But there are many people who don't care about the look because... they're nerds ;-P
And finally: I won't fight Niantic, so if they don't like my mod and decide to react then there will be no mod anymore.
If you're from Niantic then please think what is the best for Ingress users. If you don't like one or two of my features then I'll remove them and keep the valuable ones. If you still think this mod isn't good and it's a matter of time before you react then please do it sooner, not later. Mod won't be very popular yet, Ingress players won't be disappointed so much and I won't lose a lot of my time
FINAL NOTES FOR USERS
Once more: feel free to suggest new features or changes to existent ones. You can also criticize a whole mod idea. I want to know what do you guys think about it.
If you get a force close then post a logcat and mod version here.
If something doesn't look ok then post a screenshot. I have a 320x480 and 480x800 devices, but I can't test it on 240x320 and >480x800 resolutions.
You can also report language faults in the app or even here. English isn't my native and I often write something that doesn't seem natural even to me. I would be happy if someone would suggest better names or descriptions for configuration options, etc.
Of course you can redistribute this mod, but please don't do that if you don't have a good reason. I just want to know how popular it is. Also if you redistribute it then please add a link to this thread to give users a full context.
If you want to make a donation then link is in my signature, but remember that this mod may be killed by Niantic at any time.
[RESERVED]
[RESERVED2]
Very amazing
I'm gonna try it out on a new account just to be safe, but I love the work and holy cow you did a lot and I can't believe it.
Niantic better sit down and learn some must needed features and options. The globe one for sure
Sent from my MI 2 using Tapatalk 2
Keep up outstanding work. I just installed this mod and I confirm that it works flawless.
I'm looking forward to future updates.
iBotPeaches: I did a lot? But you have noticed that above features list is mostly a TODO and for now there are just new items screen and intro skipping? I'm not sure if this is clear from above posts.
I wanted to release it early to get some ideas from people.... or be banned
What about a nosound version? It reduces the app size and removes the annoying sounds for people that are tired of hearing those squeaks
Please find attached a nosound version prototype.
it will be possible to have screen: "exit. are you sure?" when accidentally using back button?
Brut.all said:
iBotPeaches: I did a lot? But you have noticed that above features list is mostly a TODO and for now there are just new items screen and intro skipping? I'm not sure if this is clear from above posts.
I wanted to release it early to get some ideas from people.... or be banned
Click to expand...
Click to collapse
Ahh, I thought you did all that stuff that was bolded in the features list Guess I didn't read it well enough.
Hi, on mine HTC Desire it crash suddnly..
EDIT: Reinstalled, work like a charm..
One thing possibly worth pointing out: I think this version will not handle the new push messages, as I believe those are restricted by the certificate used to sign the app. Are you able to confirm this?
Otherwise, very cool work
phyreskull said:
One thing possibly worth pointing out: I think this version will not handle the new push messages, as I believe those are restricted by the certificate used to sign the app. Are you able to confirm this?
Otherwise, very cool work
Click to expand...
Click to collapse
They do work for me, at least the "@" notifications
Needs further testing.
Jackos said:
What about a nosound version? It reduces the app size and removes the annoying sounds for people that are tired of hearing those squeaks
Click to expand...
Click to collapse
Usually more variants = more problems, but I think mute version may be worth it. It's almost 3 times smaller and space is crucial on many devices. It might also use less RAM and start up faster, because sfx are usually preloaded into memory. I'll do some benchmarks.
ataru said:
it will be possible to have screen: "exit. are you sure?" when accidentally using back button?
Click to expand...
Click to collapse
Sure, but what for? If you accidentally exit application, you can return to it in no time.
phyreskull said:
One thing possibly worth pointing out: I think this version will not handle the new push messages, as I believe those are restricted by the certificate used to sign the app. Are you able to confirm this?
Click to expand...
Click to collapse
I'm not sure about it. I got comm notification today, but I was using Ingress just moments earlier, so it might be background service, not push. We'll see.
Brut.all said:
Usually more variants = more problems, but I think mute version may be worth it. It's almost 3 times smaller and space is crucial on many devices. It might also use less RAM and start up faster, because sfx are usually preloaded into memory. I'll do some benchmarks.
Click to expand...
Click to collapse
Exactly my point of view
However it's a pity that the app uses this same amount of RAM. It might get better if you remove corresponding baksmali lines, I just removed the sound files.
Brut.all said:
Sure, but what for? If you accidentally exit application, you can return to it in no time.
Click to expand...
Click to collapse
I guess it's because on low ram devices the app gets closed instantly. So a back fail-safe button would save him the app loading time.
Impressions and suggestions
Nice mod!
I am an addicted Ingress player and I really appreciate your work!
The new item tab is awesome!!
I only want you to know that there is a G+ user that is modding Ingress too:
Have a look here.
He did a version even for 240x320 screen.
Maybe you can have a look at his work
I hope you can keep this up to date
Works perfectly!
I'll keep an eye on that, your features list sounds extremely promising!
ingress-1.26.1-broot-dev1.apk
It's muted and should work on all screen sizes. Layouts for 240x320 and 320x480 were created by Eugene Kartashov (thanks!), but I have integrated them into single universal apk. It's just ~0.5MB larger than Eugene's separate apks. I can't test it on 240x320 because I don't have such device. Please confirm if it's ok or not. I'll add fullscreen feature before 0.2.0 release, so upgrade button won't overflow on some devices.
Also I can confirm sounds are loaded on demand, they aren't preloaded, so muted version shouldn't boot up faster. It should take less memory though.
Is there anyone who miss these sounds? As I said I would like to avoid fragmentation and I think muted version is just better.
And if you have 240x320 device then please tell me if new items screen looks ok, especially if you have 100+ items of one type. 320x480 seems to be ok.
So I was messing around with the fingerprint scanner and found that if I use multiple fingers in one ID, I can unlock the phone with not just five fingers but 12 fingers per ID. And with five IDs you get 60 fingers. Is this really possible? Can others verify this? Isn't this a loophole? And should this be possible?
Thanks in advance.
Using Moto G⁴ Plus, 16GB.
It is possible and correct. If you add five users to the phone, they all need to be able to access that phone...
As for the number of "fingers" that's irrelevant. Each "finger" consists of multiple snapshots of one finger anyway. I am using left and right thumbs for example. But some might want to have all 10 fingers with the most used ones taken twice for better resolution. So, yes, 12 is conceivable that would be useful for some.
If you worry about that, just don't add the users.
What I'm trying to say is that a "finger" may not necessarily be multiple shots of a single finger. The scanner takes about 12 shots for each "finger" and the user can place 12 fingers in one "finger" thereby increasing the number of fingers that can actually unlock the phone. I must have mislead you when I said ID. I meant to say a "finger" when I said ID.