Database Info

[DEVS] Call for Android Developers to port your applications to Playbook

I realize the laughs, smirks, and shuns that the title of this thread may cause.
However, as the founder and community manager for bnxtreme.com, please hear me out.
I am posting this to clear up/clarify some misunderstanding regarding Android on the Blackberry Playbook.
NOTE: This thread is NOT about rooting the Playbook or completely replacing the QNX OS with Android or dual-booting. I will be creating separate threads for those, and hopefully, with enough traction, it could develop into its own section.
Click to expand...
Click to collapse
After DevCon 2011 in October, RIM released their BETA OS2.0 for the playbook.
Included in this release were several new tools for the SDK/NDK, support for additional programming languages, and of course, the reason I'm posting here, a native Android 2.3.3 run-time. Now developers have both on and offline conversion tools to recompile almost any Android APK for use in the BlackBerry PlayBook in BAR format using only a few clicks as shown on the following page:
http s://bdsc.webapps.blackberry.com/android/tool/​
Shortly thereafter, the various Blackberry forums throughout the web were abuzz about what could be done with this new BETA, how to get Android apps install, etc...
Within less than a day, the post appeared with very quick and simple directions for users to easily convert Android APK files to Playbook BAR files. Suddenly, the flood gates were now open and the list of applications being converted started to flood in, as did requests for those who 'got it' to do it for them. Less than 12 hours later, the list became too much for one person to manage alone, so a Google Doc was created based on a Google Form where visitors could submit their requests and updates. The list had taken on a life of it's own:
h ttp://bnxtreme.com/drupal/content/apk2bar-list​
As you can see from this list, individual PlayBook users have been actively collaborating and converting various applications to demonstrate just how easy the process is. It is hoped that this list of converted applications will help encourage developers to re-release their respective application on the BlackBerry Playbook.
IMPORTANT NOTE: If your application has been added to this list, it was done so because it was believed to be a free application on the Android Market, available as a free trial online, or offered for free through the Amazon Marketplace. If this is not the case, or for any reason you wish to have your application removed from the apk2bar list, please e-mail us at [email protected] and we will have your application permanently removed.​
Click to expand...
Click to collapse
Now, within the last few weeks, ported Android applications have already started to appear in the Blackberry AppWorld, being made available to anyone running the OS2.0 BETA
ht tp://crackberry.com/handster-android-app-market-begin-submitting-android-apps-blackberry-app-world-behalf-developers
ht tp://forums.crackberry.com/blackberry-playbook-f222/high-quality-free-android-apps-available-app-world-os2-users-679669/​
The purpose for this post is to call upon Android developers to start porting their applications and submitting them to the Blackberry AppWorld. Again, the process is extremely simple and will open your applications up to a whole new audience.
Additionally, I am also posting to offer our services. Our team is both willing to help test any early BETA builds or to continue any abandoned development projects on their port to the BlackBerry PlayBook operating system; all you have to do is ask.
For more information on how easy it is to develop your existing application for the Blackberry PlayBook, please visit:
ht tp://us.blackberry.com/developers/tablet/​
Thank you for your time to read this posting and we look forward to hopefully developing an active and healthy relationship with xda-developers.
Marc K.
Founder, Project Manager, and Community Manager for the BNXtreme Team.
@technomensch
ht tp://stayinginsync.info
ht tp://bnxtreme.com

I have just purchased a 32Gb Playbook and would love to support your objectives.
I am keen to use the PB on Android...I have little knowledge...but am keen
ANDREW

Why can't it be the other way? Blackberry Apps to Android? That seems to be better

Which API level to Target for new app development

Hi ALL,
I am starting the new app development (planning for game development also), I have doubt regarding target Version to be choose for new App.
Please confirm the below understanding:
1. The latest version of API, API level 17, recommanded for new development, but the app developed using this API will not be able to execute properly on older devices those having Gingerbread or older than Jellybean.
2. Currently as analytical Details, 39% market area is still using Gingerbread and JellyBean 28% and Icecreansandwitch 27%.
So majority is still with Version 3.3 gingerbread.
3. Then- one should go for Gingerbread and use API level 8 rather than the new one, as app developed in api 8 will be work on Gingerbread as well as all the above version after 2.3
4. using older API, mean we wont be able to use the new Features and the new enhancements introduced in latest APIs
5. but as market share is large for Gingerbread, we should target that Version.
6. once i develop app using latest API, i can not change the all code for older API straight forward but i have to do it from scretch.
7. is any easiest and fastest way to cross check the application develped in latest API is working on Older one. (I know Android SDK- AVD- Emulator but its very slow)
Please help me by clearing my doubts,
I will be posting my finding and Progress on the same thread.
Thanks & Regards,
Yogesh Dama

reserved
reserved

I use the latest API as the target and API level 4 as the minimum requirement.

do we have to pay for every app that we are publishing on Google Playstore?
nikwen said:
I use the latest API as the target and API level 4 as the minimum requirement.
Click to expand...
Click to collapse
Thanks for the answer,
I googled and found that cost require to publish the App on Google Play store is $25 -one time.
but some where i also found that after that $20 for each paid app we publish,
is this is true?
i have free time to spent on App Developement, if anyone want help or plans to work together for any project (ofcourse Free), feel free to PM me.
Thanks,

yogi.306 said:
Thanks for the answer,
I googled and found that cost require to publish the App on Google Play store is $25 -one time.
but some where i also found that after that $20 for each paid app we publish,
is this is true?
i have free time to spent on App Developement, if anyone want help or plans to work together for any project (ofcourse Free), feel free to PM me.
Thanks,
Click to expand...
Click to collapse
You do not need to pay for your apps. Just 25 $ once. This is ok in my opinion.

I always target the latest API, and usually set the minimum to 8, which allows me to capture all 2.2 and higher devices. A good amount of backwards compatibility can be gained using support packs published by Google, and 3rd party libraries, such as actionbarsherlock. Any devices running versions of android older than 2.2 probably don't have the power needed for many modern apps, and are many years old anyways.
As far as developer fees, it's a one-time $25 fee. That's all.

CyanogenMod for Archos Platinum 45??

Is there a cm rom version that will work on Archos 45 plat?? Or any other good rom??

ZuEma said:
Is there a cm rom version that will work on Archos 45 plat?? Or any other good rom??
Click to expand...
Click to collapse
In case you might want to give it a try, you could start with rooting according to this thread:
http://forum.xda-developers.com/showthread.php?t=2573743
NOTE:- Archos 45 Platinum too has similar device specifications. The same CWM version worked for @best98 who is using an Archos 45 Platinum.
Click to expand...
Click to collapse
I guess there is a need now to step up to KitKat or newer, if the Webos security hole is not hashed out by other ways on devices running JB 4.3 or lower
Tod Beardsley
Google No Longer Provides Patches for WebView Jelly Bean and Prior
Gepostet von Tod Beardsley in Metasploit auf 12.01.2015 00:19:38
Over the past year, independent researcher Rafay Baloch (of "Rafay's Hacking Articles") and Rapid7's Joe Vennix have been knocking out Android WebView exploits somewhat routinely, based both on published research and original findings. Today, Metasploit ships with 11 such exploits, thanks to Rafay, Joe, and the rest of the open source security community. Generally speaking, these exploits affect "only" Android 4.3 and prior -- either native Android 4.3, or apps built with 4.3 WebView compatibility. sadjellybeans_t.png
WebView is the core component used to render web pages on an Android device. It was replaced in Android KitKat (4.4) with a more recent Chromium-based version of WebView, used by the popular Chrome browser.
Despite this change, though, it’s likely there will be no slow-down of these Android security bugs, and they will probably last a long time due to a new and under-reported policy from Google's Android security team: Google will no longer be providing security patches for vulnerabilities reported to affect only versions of Android's native WebView prior to 4.4. In other words, Google is now only supporting the current named version of Android (Lollipop, or 5.0) and the prior named version (KitKat, or 4.4). Jelly Bean (versions 4.0 through 4.3) and earlier will no longer see security patches for WebView from Google, according to incident handlers at [email protected].
Up until recently, when there's a newly discovered vulnerability with Android 4.3, the folks at Google were pretty quick with a fix. After all, most people were on the "Jelly Bean" version of Android until December of 2013. Jelly Bean's final release was just over a year ago in October of 2013. This is why this universal cross-site scripting bug was fixed, as seen in the Android changelog and Rafay's blog, Rafay Hacking Articles.
Google on Patching pre-KitKat
However, after receiving a report of a new vulnerability in pre-4.4 WebView, the incident handlers at [email protected] responded with this:
If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves, but welcome patches with the report for consideration. Other than notifying OEMs, we will not be able to take action on any report that is affecting versions before 4.4 that are not accompanied with a patch.
So, Google is no longer going to be providing patches for 4.3. This is some eyebrow-raising news.
I've never seen a vulnerability response program that was gated on the reporter providing his own patch, yet that seems to be Google's position. This change in security policy seemed so bizarre, in fact, that I couldn't believe that it was actually official Google policy. So, I followed up and asked for confirmation on what was told to the vulnerability reporter. In response, I got a nearly identical statement from [email protected]:
If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves but do notify partners of the issue[...] If patches are provided with the report or put into AOSP we are happy to provide them to partners as well.
When asked for further clarification, the Android security team did confirm that other pre-KitKat components, such as the multi-media players, will continue to receive back-ported patches.
Sorry, Jelly Bean, You're Too Old
Google's reasoning for this policy shift is that they "no longer certify 3rd party devices that include the Android Browser," and "the best way to ensure that Android devices are secure is to update them to the latest version of Android." To put it another way, Google's position is that Jelly Bean devices are too old to support -- after all, they are two versions back from the current release, Lollipop.
On its face, this seems like a reasonable decision. Maintaining support for a software product that is two versions behind would be fairly unusual in both the proprietary and open source software worlds; heck, many vendors drop support once the next version is released, and many others don't have a clear End-Of-Life (EOL) policy at all. (An interesting side note: neither Google nor Apple have a published EOL policy for Android or iOS, but Microsoft and BlackBerry provide clear end of life and end of sales dates for their products).
Most Android Devices Are Vulnerable
While this may be a normal industry standard, what's the situation on the ground? Turns out, the idea that "pre-KitKat" represents a legacy minority of devices is easily shown false by looking at Google's own monthly statistics of version distribution:
As of January 5, 2015, the current release, Lollipop, is less than 0.1% of the installed market, according to Google's Android Developer Dashboard. It's not even on the board yet.
The next most recent release, KitKat, represents about two fifths of the Android ecosystem. This leaves the remaining 60% or so as "legacy" and out of support for security patches from Google. In terms of solid numbers, it would appear that over 930 million Android phones are now out of official Google security patch support, given the published Gartner and WSJ numbers on smartphone distribution).
The Economics of Upgrading
Beside the installed bases, I posit that the people who are currently exposed to pre-KitKat, pre-Chromium WebView vulnerabilities are exactly those users who are most likely to not be able to "update to the latest version of Android" to get security patches. The latest Google Nexus retails for about USD$660, while the first hit for an "Android Phone" on Amazon retails for under $70. This is a nearly ten-fold price difference, which implies two very different user bases; one market that doesn't mind dropping a few hundred dollars on a phone, and one which will not or cannot spend much more than $100.
Taken together -- the two-thirds majority install base of now-unsupported devices and the practical inability of that base to upgrade by replacing hardware -- means that any new bug discovered in "legacy" Android is going to last as a mass-market exploit vector for a long, long time.
Here Come the Mass-Market Exploits
This is great news for penetration testers, of course; picking company data off of Android phones is going to be drop-dead easy in many, many cases, and I fully expect that handsets will be increasingly in-scope for penetration testing engagements. Unfortunately, this is great news for criminals for the simple reason that, for real bad guys, pretty much everything is in scope.
Open source security researchers routinely publish vulnerability details and working exploits with the expectation that this kind of public discussion and disclosure can get both vendors and users to take notice of techniques employed by bad guys. By "burning" these vulnerabilities, users come to expect that vendors will step up and provide reasonable defenses. Unfortunately, when the upstream vendor is unwilling to patch, even in the face of public disclosure, regular users remain permanently vulnerable.
Roll Your Own Patches?
It's important to stress that Android is, in fact, open source. Therefore, it's not impossible for downstream handset manufacturers, service providers, retailers, or even enthusiastic users to come up with their own patches. This does seem to happen today; a 4.3 vulnerability may affect, say, a Kyocera handset, but not a Samsung device with the "same" operating system.
While this is one of the core promises of open source in general, and Android in particular, it's impossible to say how often this downstream patching actually happens, how often it will happen, and how effective these non-Google-sourced patches will be against future "old" vulnerabilities.
The update chain for Android already requires the handset manufacturers and service carriers to sign off on updates that are originated from Google, and I cannot imagine this process will be improved once Google itself has opted out of the patching business. After all, is AT&T or Motorola really more likely to incorporate a patch that comes from some guy on the Internet?
No Patches == No Acknowledgement
To complicate matters, Google generally does not publish or provide public comment on Android vulnerabilities, even when reported under reasonable disclosure procedures. Instead, Android developers and consumers rely on third party notifications to explain vulnerabilities and their impact, and are expected to watch the open source repositories to learn of a fix.
For example, Google's only public acknowledgement of CVE-2014-8609, a recent SYSTEM-level information disclosure vulnerability was a patch commit message on the Lollipop source code repository. Presumably, now that Google has decided not to provide patches for "legacy" Android WebView, they will also not be providing any public acknowledgement of vulnerabilities for pre-KitKat devices at all.
Please Reconsider, Google
Google's engineering teams are often the best around at many things, including Android OS development, so to see them walk away from the security game in this area is greatly concerning.
As a software developer, I know that supporting old versions of my software is a huge hassle. I empathize with their decision to cut legacy software loose. However, a billion people don't rely on old versions of my software to manage and safeguard the most personal details of their lives. In that light, I'm hoping Google reconsiders if (when) the next privacy-busting vulnerability becomes public knowledge.
Click to expand...
Click to collapse

How do I get a striped down version of Android.

Hi everyone,
Here is a little history first. In 2014 I helped develop a traffic counting app for an engineering buddy. I designed the UI's, the flow charts and wrote the 275-page illustrated, developers manual. The developer had it working in less than 6 weeks, thanks to, as he said, "to the awesome documentation provided". The app has been in use since then and has worked flawlessly on the original 24 tablets I originally purchased for him.
Recently, we have been asked to bring the app to a wider audience so, my question is, "Is there a way to prepare an image of the Android OS containing only the setup we need, and then clone it to the new tablets?" The app is designed as engineering tool and is not listed through Google Play and as such, it does not require most of the bloatware found on the new tablets. The app does require the use of photos, some file management along with network connectivity to send and receive the various data files required and produced by the app.
I have limited experience in rooting, but I have been successful when I done it on my Samsung phones.
As a certified Graphics Designer/Windows and Mac tech/COVID-19 survivor (nearly killed me, literally...LOL), I am aware of the amount of work that goes into aiding people with their "little" projects. Any help or direction in this matter would be deeply appreciated.

The future of android

Hi, as some will obviously know, google is forcing a change in android development to be more like ios. Some developers and users wont even notice or care. Others may find the changes fundamental and devastating.
Some of the changes have come about in version 11 but will be fully implemented by 12-13. These changes are going to limit access to android file system. The way apps work and limit what you can install, copy, write to external usb etc. Others will mean total lockdown of security from installing apps and google spyware controlling what you can change.
Over the years we have all seen many versions of android in countless devices with as many custom iterations and mods. In a way. Us users and the developers have shown what's possible with imagination skill & ingenuity and happily let google lead us down the garden path making billions in revenue from our devoted support. Not everyone could see the control manipulation, development and exploitation. Not everyone even cared.
But it seems now that free reign google has given us in ability for hacks & mods and and the devices android can can be used on is coming to an end. Google is yanking its chain and reeling us in.
If you think scoped storage, or more play store control will just be an inconvenience think again.
Developers and genuine android experts will know this and will probably already be aware of some solutions. I hope so. As the thread count and discussions on this balloon maybe some will consider a fork of huawei's stripped down versions of android might be an option, however we feel about china. Let's hope some options will come to light soon.