CameraKit finally comes to iOS!

Today, we’re launching CameraKit for iOS. This extends CameraKit to our most requested platform next to Android and sets the foundation for some really exciting cross-platform features.

Tens of thousands of developers and hundreds of companies like Expensify, GooseChase, Pega, and InLoopX use our open source CameraKit to power camera experiences on Android. Whether it’s simple photo and video capture or more advanced functionality, like augmented reality and barcode/QR scanning, CameraKit is the base layer to power these great camera experiences.

When we envisioned supporting our first platform outside of Android we wanted to hit the ground running…yet also wanted to remain flexible around the needs of our community. Based on that, we are excited to see what additional features developers would like and encourage everyone to post an issue or open a chat on Spectrum.

The initial release of CameraKit for iOS has a lot of great features and we hope everyone makes good use of them…

• ✅ Ability to extend and create custom sessions
• ✅ Image and video capture seamlessly working with the same preview session
• ✅ Automatic system permission handling
• ✅ Automatic preview scaling
• 📷 Ability to set a custom resolution for capturing photos
• 📹 Ability to set resolution/frame rate for capturing videos
• 👱‍ Built-in face detection
• 📐 Built-in overlay grid
• 👆 Built-in tap to focus
• 🔍 Built-in pinch to zoom
• 📸 Built-in flash toggle for both photos and videos
• 🤳 Built-in camera position toggle

CameraKit’s SDKs and abstraction engine help partners bring their apps into the camera-driven world and enables new types of engagements on a growing number of platforms. We help handle everything related to camera and are committed to creating the open source standard for developers building camera experiences. Our focus is and always will be on the developer, so we encourage you again to reach out to us on Spectrum or Github so we can learn about your needs. Thanks for your involvement and we look forward to continue growing CameraKit.

Announcing CameraKit for iOS was originally published in CameraKit on Medium, where people are continuing the conversation by highlighting and responding to this story.

I like trying new things. From the grocery store cereal aisle to cell phones, the intrinsic value of “latest and greatest” wins out in my mental arguments. This mentality then carries over to the software development world.

You know when you go to download software and all the versions show up? I wave away the warnings about possible problems and boldly select the beta version. I never know what’s new, but no chance I will be behind. And with web development, yarn package manager dangerously enables me to update everything at once with just one simple command: yarn upgrade --latest.

To redesign the CameraKit website, we wanted to go towards a component library that easily integrated with Next.js. The choices narrowed down to Google’s wonderful Material Design and the “enterprise-class UI design language and React implementation” of Ant Design. During that search, I was struck by a “NEW” badge.

Alright Ant Design, you win this time. I’ll check it out. Ant Design’s Landing greets you with a great landing page! Other documentation from Ant Design is nicely translated, but since Landing is still in early stages of development the effort of gracious editors haven’t gotten to all of the content yet. There are three other major categories to explore before we get to the editor.

Templates

There are currently eight templates to choose from. These are all well thought out websites that are easy to preview for both desktop and mobile. The first two can be edited with the all NEW landing editor! (More on that later.) The other ones are available to download from their respective GitHub repositories. These are ready-to-go react projects with testing and linting. npm i && npm start is all you need to get up and running.

Design Guide

The second category is a well laid out documentation page that is unfortunately not translated. The guide seems to lay out the foundation of how the user interacts with, and how a landing page will look. The content in these guides, however, is far from the depth of Material Design.

Sketch

Here you are able to download a Sketch file with all of the components available in the editor.

Editor

Finally the editor! It’s very similar to other WYSIWYG editors, but this editor tries to follow all of the Landing guidelines. Here is an overview of what it looks like.

What I like

The amount of styling options is fantastic. Changing the style happens instantly and there are well thought out dropdowns, button groups, and input fields for different properties. The output CSS is shown, but cannot be edited.

Moving around and adding templates is an easy drag-and-drop action with some pre-populated text and images for inspiration. You can choose from all of the components that are used to create the two sample sites.

Each individual node of the component can be edited and styled to give you very granular control of how each part of the site will look.

You are able to save, preview, and download your site as well. When downloaded, the resulting file includes individual .jsx files for each component as well as a corresponding .less file.

For the astute readers, you have noticed the data.source.js file which is where the components get their data to display. For example, here is the footer data.

export const Footer00DataSource = {
 wrapper: { className: 'home-page-wrapper footer0-wrapper' },
 OverPack: { className: 'home-page footer0', playScale: 0.05 },
 copyright: {
 className: 'copyright',
 children: (
 <span>©2018 <a href="https://motion.ant.design">Ant Motion</a> All Rights Reserved</span>),
 },
 };

In the Footer0.jsx file, here is what the React component renders.

<div {...props} {...dataSource.wrapper}>
 <OverPack {...dataSource.OverPack}>
 <TweenOne
 animation={{ y: '+=30', opacity: 0, type: 'from' }}
 key="footer"
 {...dataSource.copyright}
 >
 {dataSource.copyright.children}
 </TweenOne>
 </OverPack>
</div>

As you can see, the component has no static data inside it, but instead uses everything in the dataSource object to set the className and content. Overall I do not know if this is better or worse, but is interesting nonetheless.

What I do not like

The style customization is nice, but this isn’t an editor for someone who isn’t already pretty familiar with CSS. Some of the options do not make sense to be put onto text, and other options do not make sense to put onto images. Settings like border will not appear to be working until you specify the width, color, and style which is confusing at first.

The amount of components you are able to add is only 24. There are three navs, four banners, fourteen different content containers and three footers. So not much customization there.

The editor does not allow any movement or addition of individual components on the pre-made templates. This leads to websites that are incredibly hard to differentiate from any other created by this editor. Also, when styling these components you can change the padding and margins around which seems to be at odds with the design principles in the first place.

What bugs me

When I was trying to create a landing page for our site to test out this editor, I spent a good amount of time adding, removing, and rearranging elements to get it just the way I wanted. I did not change any styling because I only wanted the complete layout to start with. There were some minor inconveniences along the way, but there was a huge problem.

After downloading and integrating the code within our existing development site, the output was of a version I previously had been working on. It seemed to not save anything I had done. Now this is clearly my fault — I should have done a better check of the files before blindly copy/pasting. This only wasted about an hour of my time, but I can’t recommend this for any serious work. I even tried downloading it again, but the same problem appeared.

This is still a work in progress

The direction this project is headed looks awesome! I know that eventually this editor will be great, but right now it will just be a very fun tech showcase!

Testing the intelligent, buggy Ant Design Landing Editor was originally published in CameraKit on Medium, where people are continuing the conversation by highlighting and responding to this story.

The last release of JpegKit, v0.2.0 introduced new wrappers for libjpeg-turbo. This was a major redesign to the JpegKit library. While these changes improved performance and readability of the code, it was incomplete for the scope of JpegKit functionality.

v0.2.2 un-deprecates the Jpeg class to be used until the wrappers are finalized in an upcoming release, v0.3.0.

Here’s what’s changed in v0.2.2 . You can see all the changes on the GitHub Pull Request.

Bug Fixes

• Fixed edge corruption when rotating a Jpeg
• Fixed JpegView render function

Deprecation

We’ve un-deprecated the following classes:

• Jpeg
• JpegKit
• JpegFile
• JpegImageView

JpegKit v0.2.2 was originally published in CameraKit on Medium, where people are continuing the conversation by highlighting and responding to this story.

CameraKit v1.0.0-beta3.11 is a bugfix and feature release of v1.0.0-beta.

Here’s what’s new in beta3.11

New Flash Methods

You can now call two new methods, hasFlash() and getSupportedFlashTypes() to determine if the device has flash support and the types of flash it supports! These methods are outlined in our documentation, camerakit.io/docs.

Bug Fixes

• CameraPreview starts more reliably
• Fixed error when starting CameraKit on devices with API levels 16 and 17

Give v1.0.0-beta3.11 a try. Be sure to let us know if you encounter any issues. Thanks!

CameraKit v1.0.0-beta3.11 was originally published in CameraKit on Medium, where people are continuing the conversation by highlighting and responding to this story.

Oh hey there, nice to see you again.

We were made aware of an issue when capturing images in v0.13.4 by GitHub user Rodolfo. In v0.13.4 and running on API level 17 or below, CameraKit would crash with a loading error when a picture was taken. That issue has been resolved and published as v0.13.5!

You can see our PR here, and this issue first noted from Rodolfo here.

We love squashing bugs to improve the reliability of CameraKit across all devices. If you encounter an issue of your own, let us know on GitHub!

CameraKit v0.13.5 was originally published in CameraKit on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we’ve release v1.1.1, the latest release of BlurKit. It brings some small changes to help improve compatibility across devices.

Here’s the short list of changes, you can see entire pull request here.

Build and Gradle

• Lower minimum SDK version from 21 to 17
• Update Gradle to 3.3.0
• Update Gradle wrapper to 4.10.1

As always, if you encounter any issues or have particular feature requests open a ticket on GitHub. Thanks for reading!

BlurKit Release v1.1.1 was originally published in CameraKit on Medium, where people are continuing the conversation by highlighting and responding to this story.

CameraKit is a robust open-source platform for quickly adding camera functionality to your android applications.

At CameraKit we strive to empower our community to not only expand CameraKit usage, but build a better product along the way. We’ve discovered a few tactics for accomplishing our goal: be available and responsive, open to feedback and build the CameraKit our community wants.

We had the vision, now we needed the tool.

The First — GitHub.

CameraKit started on GitHub. GitHub is a platform to house code, track changes and post issues. Posting issues it the main method one can interact with other developers on GitHub.

Starting out, we didn’t have a need for lengthy communication. We had a small following of developers looking to use CameraKit and help in its development.

As CameraKit grew, our GitHub page was attracting a wider audience. We noticed our issue page filling up with all sorts of questions. From a developer creating his or her first Android application, or a seasoned Android expert looking into the intricacies of our library. We didn’t have a good way of separating these two styles of questions and ended up with a backlog of issues.

In order to keep GitHub project development focused, we needed another solution.

Pros:

1. Automatically set-up with our codebase hosting
2. Good for software development related issues

Cons:

1. Bugs and features mixed together with simpler questions.
2. Difficult notification management

The Second — Slack.

Our team used Slack internally. When we wanted another place for communication and questions, it seemed like the natural first choice. Slack is primarily a tool for well defined teams, but decided to give it a try in our community use case. We created a public channel and had people join.

Slack worked well at a small scale for CameraKit. People were able to ask questions and get quick responses. We posted updates and new feature ideas, and were able to get feedback right in slack. The chats had much more of a discussion feel, where people could get help or talk about their applications and camera needs.

However, slack is inherently built for teams and not for large groups of people. There is a bit of a barrier to entry with using Slack for this type of communication. One has to sign up through the 3rd party tool by link only, and download the client. Because of this link only invite, our group was not easy to find by searching alone. Slack is also not indexed online, so finding questions that someone’s asked before was not possible.

Pros:

1. Faster communication than GitHub
2. More discussion focused than GitHub

Cons:

1. Hard for people to join
2. Poor member management
3. Not indexed by Google for repeat questions

The Third — Spectrum.Chat

After searching for another tool to host informal CameraKit discussion, we came across Spectrum. Spectrum positions itself as “a platform for communities”, just what we had in mind.

Spectrum’s format for discussion is based on a question and comment system similar to GitHub issues. The questions are split up based on channels; e.g. feature requests or community help. This system makes it easy for someone to pick the channel they want, ask a question and get a timely response. On the homepage for our CameraKit group, there’s a helpful search feature next to different sortings of the questions. One can see the latest questions or what’s trending on CameraKit.

Spectrum is also easy to join and brings useful member management, analytics along with flexible team and administrator settings. We also have the ability to integrate Spectrum directly into our website.

Spectrum is still not perfect. Its a relatively new company, and we have occasionally encountered bugs and stability issues on their site. The website can also be confusing to navigate on first glance.

However, spectrum was recently acquired by GitHub! This gives us hope that the Spectrum will only grow in popularity and continue to be updated for the foreseeable future.

Pros:

1. Easy to join
2. Helpful management tools
3. Robust search, and indexed online
4. Strong backing

Cons:

1. Still a young company: some bugs and stability issues
2. Interface can be confusing to navigate

The Winner — Spectrum!

We are fond of our new home on Spectrum. With Spectrum’s acquisition by GitHub, no doubt these issues will be ironed out and the system improved in the future. We much prefer the ease of management Spectrum provides over the discussion focused style of Slack.

So if you haven’t already check us out on Spectrum. Leave a question or comment and we’ll be sure to get back to you!

Thanks for reading and we’ll see you around.

An Open Source Community: How We Came To Use Spectrum was originally published in CameraKit on Medium, where people are continuing the conversation by highlighting and responding to this story.

While we are building video support in CameraKit v1.0.0, we will continue to maintain v0.13.X as the latest CameraKit version with video integration.

This latest release brings a few bug fixes and build improvements. You can see the full list of commits on our GitHub pull request. To view documentation, head over to camerakit.io/docs.

Here are the highlights.

• Lower minimum SDK version to 15
• Fix orientation of captured image with the front camera
• Revert back from AndroidX to Android support libraries

CameraKit relying on AndroidX forced developers to also use AndroidX if they included CameraKit in their applications. In an effort to leave developers with as much choice as possible, we moved CameraKit back to the standard android-support libraries. This will allow developers to use AndroidX or standard Android Support in their own applications.

As always, if you encounter a problem or have a request for a feature, drop us an issue on GitHub or a message on Spectrum!

CameraKit Release v0.13.4 was originally published in CameraKit on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last week we launched APK Inspector, a command line tool to determine dependencies and permissions from an APK file. Today we’ve released version 0.2.0 bringing new features and updates!

In version 0.2.0 you can now output permissions and dependencies to a JSON or text file. The default output is JSON, but you can change that behavior with the --output-type command line argument.

Here are the rest of the v0.2.0 highlights, you can see the entire pull request on GitHub.

Features

• Output permissions and dependencies to JSON or text file.
• Update default console logging behavior

Bug Fixes

• Better handling of user input to reduce errors

GitHub

• Add issue and contributing templates

APK Inspector v0.2.0 was originally published in CameraKit on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dissecting an APK: Permissions and Dependencies

I work at CameraKit, an open source platform to provide a reliable and easy to use Camera implementation in any Android application. We were recently interested in testing an APK to see whether or not it used CameraKit. Going one step further we wanted to test if an APK requested camera permissions.

We weren’t able to find a tool like this after a quick few Google searches so we decided to make our own!

Here’s what we learned about APKs along the way.

The Approach

If you want to follow along with this article, you can download an APK from APKMirror.com and use it with all the tools below!

We first turned to the Android Studio APK inspector to see what exactly makes up an APK.

There are a few different types of files; AndroidManifest.xml, assets, meta information, and .dex classes.

Looking into the AndroidManifest.xml file you see almost exactly what was written when the application was created: SDK and version information, and most importantly, permissions!

So that will provide the permissions, now what about dependencies? Selecting the classes.dex file expands to reveal something like this:

Dex files

.dex is the file extension of the byte code format read by the Android Runtime (ART). This runtime environment operates and runs the bytecode on Android devices. Dex files are not Java bytecode, but its own format with entirely different bytecode instructions. These files contain a translated version of all the code and classes of the application. Aside from the lib, classes.dex is the largest component of this APK.

Huzzah! Our package com.camerakit is there, along with all the other packages requested by the application. You can see things like Kotlin, Android Support and Java IO.

All that’s left to do is find a way to automate this process and extract those package names.

Automation

The goal of this project is to quickly analyze any APK. Opening the APK through Android Studio and manually searching the classes.dex is far from efficient.

Unzipping

After further investigation I learned that APKs are a specific type of zip-format archive file. APKs are based on the Java Archive (JAR) format that’s used to compress Java class files and resources. APKs are also signed with an SHA1 Digest and a certificate. Both of these components are contained in the META-INF directory.

With these special considerations, renaming the file to .zip and unzipping it with a standard unzip tool most likely will not work. But we tried it anyways.

The result looked promising:

But opening any of the files confirms our suspicion.

����������.�����������������������������(���4���L���j���������������������������4��Z�����������������������2��x��������(��l��������8������������\�������2��F��X���������������t�h�e�m�e����l�a�b�e�l����i�c�o�n����n�a�m�e���

�d�e�b�u�g�g�a�b�l�e���

Simply unzipping the package leaves the files encoded resulting in unreadable text. Another method is needed to unpack and decode the APK.

APKTool

From their GitHub:

A tool for reverse engineering 3rd party, closed, binary Android apps. It can decode resources to nearly original form and rebuild them after making some modifications. It also makes working with an app easier because of the project like file structure and automation of some repetitive tasks like building apk, etc.

APKTool does just what we wanted, unzips and decodes the APK turning the files into human readable text. Now opening the same APK with APKTool gives the following output.

The output includes an assets folder, and something called smali. We’ll get back to that in a second. AndroidManifest.xml is now readable and contains exactly what we saw from the Android Studio APK Analyzer.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:compileSdkVersion="28" 
android:compileSdkVersionCodename="9" package="com.example.emerson.camerakittest" platformBuildVersionCode="1" platformBuildVersionName="1.0">

<uses-permission android:name="android.permission.CAMERA"/>
<uses-permission android:name="android.permission.RECORD_AUDIO"/>
...

Reading the permissions is as easy as loading AndroidManifest.xml and grabbing all of the <uses-permission> lines. The dependencies will take a tad more effort.

Smali

As you can see in the above screenshot, the smali and smali_classes2 folders contain the same packages we saw in the classes.dex of the Android Studio APK Analyzer. Wouldn’t you know it our com.camerakit package is right there!

What is smali? Smali is the product of running a disassembler on a .dex file. Smali is a human readable but maintains the procedural structure of the dex file format. The process of converting dex to smali is called “backsmaling” and is done with APKTool by way of this GitHub repository.

Here’s an example of a smali file.

.method public getFacing()I
 .locals 1

.line 674
 iget v0, p0, Lcom/camerakit/CameraKitView;->mFacing:I

return v0
.end method

If you compare it to the Java source code you can see the close resemblance for a simple function like getFacing().

@CameraKit.Facing
public int getFacing() {
 return mFacing;
}

However the contents of the smali file are not important for this project. All we need is the names of the folders, formatted as com.camerakit. This can be achieved by traversing through the folder structure, saving the names of the above directories to create one final package name. The package name is made up of all the directories that came before the folder containing smali files, which is most often the final name of the package.

For example the structure:

Turns into:

androidx.versionedparcelable
com.camerakit

APK Inspector

With access to both the permissions and packages used by the application, we created a command line tool APK Inspector to wrap it all up.

The main function is to run APKTool on a specified APK to reveal AndroidManifest.xml as well as the smali folders. From here, APK Inspector searches through AndroidManifest.xml for permissions and outputs them to the console. Then our program recursively iterates over the smali folders, concatenating the folder names into package names.

There are some basic options for the tool that you can see on the README. One can output permissions only, dependencies, or search for a specific permission or dependency.

Future Improvement

This is only the first draft of the project and I’m looking to keep making improvements to increase the speed and functionality. We’re open to feedback and love to hear your ideas, but we plan to refine APK Inspector to our own needs as we go forward.

As we continue to development, keep your eye out for more blog posts on the topic of APKs, how to deconstruct them, and possibly even other application formats.

Thanks for reading!

Finding Permissions and Dependencies in an APK was originally published in CameraKit on Medium, where people are continuing the conversation by highlighting and responding to this story.