WinGoku

Back in July 2014 when I was doing my research work for the scholarly publication  of my Computer Systems Engineering graduation, I got intrigued by Android Wear watches. I remember watching the  Google IO in which they showed off the upcoming watches and the cool new ways we could interact with our phones. At the time of Google IO I didn't pay much attention to Android wear and focused completely on my research. However at the launch of Android wear, I saw LG G watch and Moto 360, the later was planned to be released a few months later. I was fascinated by the cool design of Moto 360 and got interested in wear development. I looked at the workings of Wear OS & to my surprise, Google didn't include a handy application launcher considering Android Wear was all about enhancing user experience and keeping us away from our phones when necessary. The only way one could launch an app was via voice, otherwise you had to dig deep into the system to get to list of installed apps.

If you are trying to test your app that has a ProgressDialog in it, STOP RIGHT THERE! You are gonna be in a world of pain, when your tests keep failing for no apparent reason after failing to find the progressDialog that is vividly visible on the screen. The problem isn't in your code. It's the shortcoming of the Espresso Testing Framework. The framework can't really handle the animations of the progress dialog. I am still digging around the exact reason, however from the little bit of research I have figured out that the drawable animation of the circle gives the impression of non idle state to the Espresso framework. So what does it mean? It means Espresso keeps waiting for the app to enter the idle state and as long as the progress dialog is visible on the screen, the app stays in the busy state. By the time animation ends, the progress dialog is gone. When the app enters the idle state and espresso comes out of the waiting loop to start running tests, it fails toex

All the modern browsers have implemented a security protocol that prevents the website to access files from the disk. It's a really important security measure that forbids the websites to snoop into your disk and steal your 'data'. However sometimes you want to load the files anyway. May you are developing a web app and you want to load libraries stored on your disk. This security protocol will hinder this action. You can use work arounds by setting certain flags of the browser that will disable these security fences but the catch is you will become vulnerable to the attacks. I don't advice disabling security in your browser. The workaround that I have found is very secure. So for example if you want to reference a Jquery file on your disk, trying to access it with src="file:///path/to/your/file.js" wont work. So the easiest workaround that doesn't require alot of effort is to serve these library files or any other file that you want to load by

Google is rolling out the new Camera app v 3.1 gradually via playstore. The update was long due and the Google's current offering was lacking in several areas, performance is the most the notable one. I got my hands on the updated app via APKMirror . The app is intended for devices running Android Marshmallow. So bad luck for lollipop users. From the early impressions, the app looks just an aesthetic overhaul. The app brings the UI from the Camera apps of Nexus 5x & 6P. However, it doesn't offer burst mode on neither Nexus 5 or 6. Not surprisingly the later has Auto HDR+ feature. Currently I have a Nexus 5, which is considered the best Nexus device Google has ever released. However the camera along the battery aren't the strong suits of the champ. Though the camera performance & picture qualities have improved plausibly since the inception of the device, the current release takes it to a whole new level. The latest Google's camera app has improved in bot

https://issues.sonatype.org/browse/OSSRH-14762 Project URL: https://github.com/wingoku/TickerTests SCM url: https://github.com/wingoku/TickerTests.git Proof for verification

Lately I have been working with MediaPlayer on Android. I went to Android docs, read the description of the apis. Great! Let's think a rough algo and start working on the app. I wrote a simple app which just streams a video and provided media player controls in the app for seeking, play pause etc. Pushed it on my device and goofed around with it. Play, pause working great. Video is streaming nicely. What about seeking? Let's seek to some X position. BAAAAM!!! The whole app became unresponsive. I couldn't interact with my device any more. I thought may be I am doing something wrong so I better review the code. After reviewing I couldn't find anything that I might have been doing on the main thread which could have caused this ANR. I searched the internet and found a few questions on Stackoverflow complaining about the same issue and guess what those questions were posted back in 2011 and 2012. I asked some of those devs and to my surprise they had the assumption of th

Yesterday I rooted my Nexus 5 running stock lollipop. I bought this phone about 3 weeks ago. Lollipop was supposed to improve power consumption of Android devices but the results I acheived were quite opposite of what Google has been claiming. I barely got 3 hours of SOT & I was facing mic issue as well, which means people at the other end couldn't hear my voice clearly & sometimes my voice was gone completely (during important calls offcourse). I knew it could be fixed by rooting the device & modifying the OS to my liking. So far the results & my findings are not that impressive after rooting & modifying the OS. I flashed ElementalX kernel with stock settings except I undervolted the CPU to 750 mV. I greenified the culprit apps & started to expect at least 5 hours SOT. However the results were quite below my expectations. I couldn't get more then 4 hours SOT with the following settings & usage patterns. Brightness ~25% Calls = none Gaming =