CASUAL Ebonics Language Translation Started-April Fools

Here at CASUAL-Dev we make it our business to keep our software as user-friendly as possible. Until now we’ve supported English, French, Croatian, and Spanish speaking users. We have done our best to give credit to the translators and contributors as well as made them part of the team.

Today we’ve added a new Ebonics translation which will allow more users to experience CASUAL as intended, in their own language. We feel it’s best to never leave anyone out and we help out where we can. Starting today, you can use any CASUAL revision 1059 or higher in Ebonics. All that’s required is to set your computer language and CASUAL will do the rest.

As always, we accept contributions to all parts of CASUAL. If you’d like to make corrections, let one of the team know.

Share on Google+Share on FacebookTweet about this on TwitterShare on Reddit
jodinsite

JOdin3 web design by Logan Graham

Designing for Web 2.0, 3.11, 13.04, or whatever version we happen to be marketing this week, is difficult. The job of a web designer can never be credited enough. Most of the time, when a developer works on an application he gets his name in the “about” section. This is almost never the case with Web Designers.

Logan Graham’s JOdin3 page design is a work of art, and one that requires commendation. From the slide affect to the clean and minimalistic styling… from the color scheme to the window expansion, it’s some beautiful work. While we all take part in development, optimization, UI and design, I’d like to invite you to have a look at the page layout of JOdin3 and ping Logan Graham if you’d like him to take a look at your site.

Compare the video and picture below to see the difference Logan’s work has made.

jodinsite

Thanks Logan!

Share on Google+Share on FacebookTweet about this on TwitterShare on Reddit
6NcmF71

Français translation added by Jules Archinova

Whenever a new language becomes active in CASUAL core, more people are able to use CASUAL applications. Today Jules Archinova added French translation to CASUAL. This is awesome news for French users!

CASUAL’s language comes from three separate parts, the GUI, the Script, and CASUAL core. GUI and Script translations are not supported at this time, but The CASUAL core is the most important of these three. The CASUAL core provides troubleshooting tips and tricks when the user needs it the most. This provides assistance to CASUAL users in their native language.

As a quick recap of how to translate CASUAL core; You run CASUAL TLDR, copy the English.properties file to the filename specified by TLDR, and then begin translating. Once complete, you can contact us and we will add you as a contributor to the project so you can commit the code and get credit for it.

One thing to take note of though; When contributing a language that makes use of “Extended ASCII” characters such as those with accents, the translation must be converted to JavaScript Unicode format. You can see the original translation by Jules, then the Unicode converted translation. It’s simple enough to convert to JavaScript Unicode using various tools online, and performing this as a final step ensures the translator’s name gets attached to the work and not the person who does the Unicode conversion

Here are some images from the new French Translation courtesy of Jules Archinova!
M9C13m0

MtuOZH3

We will always accept contributions, especially translations. We will always make sure that proper credit is given as well! Thanks Jules Archinova!

Share on Google+Share on FacebookTweet about this on TwitterShare on Reddit
6a011570607d87970b0154341856ef970c-800wi

Get CASUAL to notify you in your native language

For around a year now, the CASUAL core has supported translations to different languages. XDA-Developers Senior Member gaich member was the first to successfully translate CASUAL to Russian. More recently, Karlo Vranjes translated CASUAL to Croatian. We would like to thank Karlo and gaich!

CASUAL, unlike many applications holds its translation values for all languages internally. This allows it to work universally across all languages with a single application. The first step in translating CASUAL is to identify the language which Java detects. The CASUAL system will automatically load translations from a file named “your language”.properties, where “your language” is the case-sensitive language detected by Java. While the world may know your language as many words, Java knows just one. So it is important that the translation file be named appropriately. This became apparent when Karlo tried to translate Croatian language which java knows as “hrvatski”. The only way CASUAL knows to find the Croatian language is in the hrvatski.properties file.

Here’s a link to the CASUAL Translation Language Detector Reader. CASUAL TLDR will automatically identify the language and therefore the filename which you need to use for your translation.

There are two key points to remember while translating:
1. Keep it short
People are less likely to read long paragraphs when they are stressed out. Most of the translations occur when CASUAL Core detects a problem. The Core provides feedback to the user in order to resolve the problem. The messages should be short so the user quickly understands what is going on.
2. Keep it informal
Users like to see Friendly words rather than formal words. Formal words, like “system has malfunctioned” , are generally less descriptive, less meaningful, and provide a higher level of stress to the user. It’s a much better idea to say, “There’s a problem”, or “This isn’t right”. Languages are dynamic and so are the translations, updates are always needed for user friendliness.

The most important part about translation is the formatting. For user-interactive dialogs, CASUAL uses a special “Title>>>Message” format to provide the most flexibility. Here is an example:

@interactionUnableToDetectDownloadMode=Check your cables>>>Heimdall is unable to detect your phone in Odin/Download Mode\nRecheck your cable connections, click OK when ready.

Whenever information is being conveyed to the user through logs or dialogs, if the character @ is seen at the start of a word, CASUAL will attempt to translate the word into a sentence. So, if @interactionUnableToDetectDownloadMod ” is seen, the text is replaced by “Check your cables>>>Heimdall is unable to detect your phone in Odin/Download Mode\nRecheck your cable connections, click OK when ready.

The “>>>” is further processed by CASUAL Interaction dialogs to be a separator between a dialog Title and a dialog Message. So, by the time it gets to the user, @interactionNeed8gigExternalSD turns into a dialog like so:
Title:Check your cables
Message:Heimdall is unable to detect your phone in Odin/Download Mode\nRecheck your cable connections, click OK when ready.

@interactionUnableToDetectDownloadMode=Check your cables>>>Heimdall is unable to detect your phone in Odin/Download Mode\nRecheck your cable connections, click OK when ready.

The CASUAL core is used throughout several projects on CASUAL-Dev and changes made to the CASUAL-Core translation system will assist users in their native language when they need it the most. For those languages which are untranslated, or missing translation values, English will be used by default. For translated languages, the users will know a whole lot more about what’s going on.

For those looking to translate CASUAL, you can find the original English properties file here.

Special thanks to those who have contributed to translations!

Share on Google+Share on FacebookTweet about this on TwitterShare on Reddit
IMG_20140204_105908

Security Issues on this site.

January has been hopping around these parts. We’ve released software, addressed security concerns, revamped the website, and more. I want to take a minute to talk about a few things and give thanks where it’s due.

Site Security
Cybersecurity is a huge issue here. Should this site be compromised, bad things could happen to our users. We take this threat very seriously and while discussing it one day CyanogenMod developer, Pen Tester, and all-around nice guy, Ryan Scott (aka ChiefzReloaded) offered his services to help secure the site. It took him nearly a week to finish up testing. He went above and beyond, signing up for various accounts on CASUAL-Dev, testing both planned and already implemented features. ChiefzReloade’s testing was thorough, and at the end of the day we can say we’ve addressed just about every potential security concern thanks to him.

Java Security
Security can only go so far from our end. Our site relies heavily upon Java. And in 2013, Java was the leading entry point for explicit malware on all computers. As of Java 7u51 (released two weeks ago), Java is no longer much of a security concern. Most existing malware will no longer run, and that which does can be kill-switched remotely after being reported. I know most users are running Java 7u21, have skipped 7u45, and haven’t yet updated to 7u51. So, I encourage you to click here and update. The latest release of Java requires that a trusted certificate authority verify an individual and issue him or her a signing certificate. This certificate is verified against OCSP and CRLs each time the application is launched. If it is determined that the individual who signed the application is a malware author, the signature can be revoked and the application will refuse to run on your computer.

While the latest Java update causes developers like us to have to jump through many hoops while addressing security concerns, I’d say the end result is worth it. CASUAL is 100% conformant with the latest update’s “High Security” settings. The updates to Java7u51 will not only invalidate most malware, they also cause malware authors to think twice about signing off on the malicious software in the first place and allow for remote kill-switching when any is discovered.

Something to think about
An issue was identified by security researcher Justin Case: We are training users that it is acceptable to allow a web application to ask for root permissions. I’d like to point out that this is 100% true. We use administrative access to install drivers for software that is used by CASUAL and Jodin3. We do this in the name of being user friendly and we’ve “earned” the permissions due to proper procedures and code signing of our applications. However, what can we do to address user training? Should we make a mandatory training class, or offer one? A video? A class? A test? Sound off below with your ideas.

Share on Google+Share on FacebookTweet about this on TwitterShare on Reddit
custom

Add a Custom Button to your Google+ Post.

This has absolutely nothing to do with CASUAL, but it’s a service hosted on this site. You can make your own custom Google+ post with a Call-to-Action button, using the form below. Change your selections, then submit the form. You can demo the form embedded below, but its recommended that you visit the form page directly because this page is not optimized for wide content.

You can use this form for any purpose.

‹!-- CASUAL-Dev Google+ Custom Post Form Code --›

‹embed type="text/html" width="700px" height="550px" src="//builds.casual-dev.com/plus.php" >
Share on Google+Share on FacebookTweet about this on TwitterShare on Reddit

CASUAL Features – Full Disclosure

We at CASUAL-Dev try to keep things in the open. Our releases are open source, and we maintain a hands-off approach to releasing software. This ensures consistency. We have hundreds of thousands of users, and we use tools built into the software to manage this. There are some things that could be a potential privacy concern, or otherwise undocumented features that should be publicly disclosed though. That’s what this post is about.

Open Source
First off, we aren’t hiding anything. The CASUAL project is a totally Open Source and Open Build project. We strictly adhere to GPLv3 standards and maintain our releases on this site and http://goo.im/devs/AdamOutler. Anything downloaded from these sources is guaranteed to be created 100% in the open.

It all starts at the android-casual.googlecode.com Subversion server. Upon receiving a commit, GoogleCode notifies our Jenkins server that a new version of code is available. This triggers a build of Project CASUAL. A successful build of Project CASUAL causes several things to happen, including testing, building CASUALs with GUIs, uploading to various servers, and the rest of the jobs you see on this page http://jenkins.casual-dev.com/view/All/. Certain software, like JOdin3, is only built when a button is pressed.

In the event that we are contracted to write or work with others to write Closed Source software, the GPLv3 Copyright is waived and legal documentation is provided and kept on record here at CASUAL-Dev. Various parts may be added and removed from the software. We won’t disclose this information to our users, and you will never encounter any such software from the sources listed above (public WiFi networks under ARP spoofing attacks excluded). Everything on this site is built in the open. The only information we don’t share is our private code signing keys and log in credentials. We cannot share these keys for obvious reasons. However, we can point you at our Code Signing Certificate Provider, Certum.

Error Reporting

CASUAL features a “pastebin” or “report error” button in almost all forms. The point of this is to encourage users to use Pastebin rather than spam a 10 kilobyte log on the forums or Google+. This feature is really useful for determining problems in CASUAL. However, most users simply never report problems. In order to fix the problems, or even be aware of them, we need feedback. In order to compensate for a lack of user reporting, certain forms of CASUAL examine their own logs for keywords (like “error” or “failed”) upon shutdown. If these keywords are found, the CASUAL may send off an anonymous log to Pastebin. This all depends on the version of CASUAL, if it’s running in jar form, if it’s a known CASUAL developer (we don’t want our debugging logs.. If your computer username is Adam or Jeremy, we won’t be getting logs from you) , and the keywords we are monitoring. The “Anonymous Log” contains only an error report. User information is stripped out. The user’s name is replaced with “CASUALUSER,” and the user’s home folder is replaced with “USERHOME.” We use this data to search for and fix recurring problems. Currently, the only Anonymous Log Reporting that occurs is in the traditional CASUAL Java Desktop application. This way, we are generally aware of any problems and can stay on top of things.

If you’d like to read these logs, check out the CASUAL-automated pastebin here:http://pastebin.com/u/CASUAL-automated

Hit Counting
When CASUAL loads up, it searches for a CASPAC. And from within the CASPAC, it loads a script. The CASPAC is a package that can stand alone in ZIP or .CASPAC form, as well as serve as the contents of the CASUAL /SCRIPTS/ folder inside a JAR. Upon loading a Script, the UniqueID or other arbitrary factor is used to increment a counter at http://counter.casual-dev.com/?UniqueID.

Conclusion
As a CASUAL user, you should know that we use this information to improve your experience. As a CASUAL script developer, you can use this information to track usage and error statistics and make improvements. These statistics are considered vital information for this project, and we can make corrections using it. We strive to maintain the anonymity of our users and clients. If there is a problem with our methods, please raise a concern. CASUAL is in its infancy and will continue to grow over the years.

Share on Google+Share on FacebookTweet about this on TwitterShare on Reddit
jodin3

JOdin3, Web Browser Or Offline Flashing Tool

Today marks the day CASUAL brought Odin flashing to Linux, Mac and Windows. It’s called JOdin3 and it’s a Java implementation of Odin. Just as you’d expect, it looks acts, feels, tastes and smells like Odin on the surface, but it is powered by a full open-source stack of software under the hood, namely CASUALcore and Heimdall, utilizing open-source LibUSB drivers.

You may be asking yourself, can’t we already do this with Heimdall? No. Heimdall cannot handle Odin files. You must decompress the files and write a shell script or use an interface to customize flashing parameters for Heimdall. JOdin3 allows you do put your tar.md5, tar.gz, tar.md5.gz, or just plain tar into the app to be flashed using the same logic that Odin does.

So what are the differences between Jodin3 and Odin3? The major notable difference between JOdin3 and Odin3 is that JOdin requires, and offers to obtain, a PIT file before flashing. This is due to a current limitation in Heimdall which does not allow for resume capabilities. Aside from that, the JOdin3 application allows operability on Linux, Mac, Windows, and Raspberry Pi, using Java7 and is able to account for problems and install drivers if required. JOdin troubleshoots problems and gives more information than Odin. On top of that, the modal dialogs are just frickin’ awesome, and its totally Open Source!
modal

The goal of this project is to show the flexibility of the CASUALcore. It can be adapted to nearly any circumstance and will run on all major operating systems. This allows for full and complete customization of a firmware flashing experience… After all, it’s not called the Cross-platform Android Scripting, and Unified Auxiliary Loader for nothing.

JOdin3 is available online from inside a web browser here: jodin.casual-dev.com
You can download a copy of JOdin3 to run directly on your computer here: goo.im/devs/adamoutler/JOdin3
Support is available on XDA-Developers here:http://forum.xda-developers.com/showthread.php?p=49133090
You can compile it yourself here: CASUAL Open-Source Repository
Follow CASUAL on Google Plus here: google.com/+casual-dev

Share on Google+Share on FacebookTweet about this on TwitterShare on Reddit
cdev

new Commands, Streaming Firmware Flashes, networking

Much development has come as of the last few weeks.  The UI has been optimized and separated from the source.  New commands have been added, and a full new branch was started by our own Loglud(Logan Ludington).  Also, if you’d like to find out what needs to be done in the code or items required to be addressed, you can check out our auto-generated todo list.

The $IFCONTAINS and $IFNOTCONTAINS commands received an upgrade.  Any time one of the IF commands are run, the rest of the line is parsed for &&& as a delimeter.  Each &&& which is found will denote a new CASUAL command to be run if the original expression is true.

The Command Delimiter ;;; was added to CASUAL Language.  In combination with the command-line option –execute or -e allows for a full CASUAL script to be executed from the commandline.  Any &&& chains will be broken by ;;; and anything following the ;;; delimeter will be executed as though it were a new line.

java -jar casual.jar -e $ADB push update.zip /sdcard ;;; $ADB reboot recovery

The $FLASH,  and $PULL commands were added to the CASUALcore source.  These commands directly flash or pull Block/Char devices and files on a mobile device.  The system works by monitoring both the device and the CASUAL client, establishing a netcat server on the device and checking for proper shutdown.  Utilizing SSL, Error Checking,  EOFconfirmation, retries, and more, we feel confident that this is the most secure flashing mechanisim ever created.   If you come up with a great idea for CASUAL, or just want to assist in brainstorming new ideas,  Get involved.

Loglud has started working on a new, unnamed device detector. The detector will serve as a splash-screen before CASUAL is loaded and an interface.   Upon launch it will:

  • detect the device
  • install drivers if required
  • download a new version of CASUAL
  • detect available packages
  • present a list of options to the user
  • execute CASUAL

We’ve created a massively multi-threaded search tool which will take in a device’s build.prop file, search through the folders on builds.casual-dev.com, and return all available packages.   It works by searching for new folders via special APIs, examining the b.prop if available in the folder and verifying if it can use the files and folders contained within, then starts new searches on each of the available folders.    This tool is still in testing phase and we will begin migrating away from the standard download-a-CASUAL and focusing more on using CASUAL as a package manager.

The new device detector will provide everything which CASUAL cannot currently handle, including upgrading CASUAL, downloading new pacakges, and database integration with multiple sources.    This fledgling project requires more work.  Would you like to share expertise?  Get involved!

 

Share on Google+Share on FacebookTweet about this on TwitterShare on Reddit
CASUALLong

Whats a CADI?

Overview

CADI or CASUAL’s Automated (USB)Driver Installer is an integrated part of CASUAL, which is designed to streamline the CASUAL process on Windows. CADI has its has its own Open Source repository and you can find stand-alone binaries there.  CADI was created by jrloper(Jeremy Loper), aka. “Looper”.  While CASUAL initially used a semi-automated generic driver installer bundled with Heimdall, due to the overwhelming amount of users requiring assistance with this tool, a more reliable & automated system would be required to continue Windows support. CADI was initially conceived in C++ for Samsung devices only, using the same back-end (libwdi by Pete Batard) as the original semi-automated tool; this however, only introduced new problems to work around. Ultimately libwdi was dropped and CADI was ported to java to become part of the CASUAL engine.

Current functionality

Single/Mass device installs
Single/Mass device uninstalls

CADI is currently comprised of:

In order to avoid native calls from java, a customized version of the Microsoft Devcon utility (MS-LPL) is used to make all necessary SetupDi API calls. CADI uses REGEX to parse commandline output from Devcon, and determine the next applicable step.

Its important to note, CADI (in its current state) cannot be run independently from CASUAL. Independence is possible, though no implementation is currently planned.

Driver Details

CADI uses libusbK, which is a generic WinUSB compatible driver for libusbx communication with Heimdall. Two sets of drivers are used (each containing an x86/x64 variant), one built with WDK 7.1 (allowing for XP support) the other built with WDK 8.0 (for Windows 8 support). All driver components are built & digitally signed by Jeremy Loper.

CADI has its own Open-Source repository separate from CASUAL so you can find stand-alone non-java Windows-executable distributions there.  Also, expect more driver awesomeness from jrloper and the rest of us in the future.

Share on Google+Share on FacebookTweet about this on TwitterShare on Reddit

CASUAL Development