**Mandatory Naming Convention** - Paid Software Announcement and Discussion

Might I suggest a naming convention for posts here ?
Currently we mostly have Windows Mobile, Windows Phone and Android devices on this forum. As this "Paid Software" forum is not split up into different OS's (yet ?) we should have a naming convention.
I am proposing the following scheme, including OS, version number, and root status.
Windows Mobile
[WM 6.x] <appname>
For WM apps that run on all WM 6 versions
[WM 6.5] <appname>
For WM apps specific to WM 6.5 (or 6.0, or 6.1, etc)
Windows Phone 7
[WP 7] <appname>
Any WP7 app
Android
[Android 1.6+] <appname>
For Android specific apps that require at least Android 1.6
[Android 1.6-2.1] <appname>
For Android specific apps that require at least Android 1.6, but are known not to work on for example 2.2 and 2.3
[Android 1.6+, ROOT] <appname>
Same as [Android 1.6+], but requires root.
Release dates, versions
Some apps include release dates and version numbers, suggesting that the date follow the OS specification, and version number follows appname.
For example:
[Android 1.6+, ROOT, 2010.12.31] MyRootApp v1.3 - The greatest app ever!
This is just all just a suggestion. Feel free to comment. I just think it should be easy to see these app sepecifics in the listing directly.

Chainfire said:
Might I suggest a naming convention for posts here ?
Currently we mostly have Windows Mobile, Windows Phone and Android devices on this forum. As this "Paid Software" forum is not split up into different OS's (yet ?) we should have a naming convention.
I am proposing the following scheme, including OS, version number, and root status.
Windows Mobile
[WM 6.x] <appname>
For WM apps that run on all WM 6 versions
[WM 6.5] <appname>
For WM apps specific to WM 6.5 (or 6.0, or 6.1, etc)
Windows Phone 7
[WP 7] <appname>
Any WP7 app
Android
[Android 1.6+] <appname>
For Android specific apps that require at least Android 1.6
[Android 1.6-2.1] <appname>
For Android specific apps that require at least Android 1.6, but are known not to work on for example 2.2 and 2.3
[Android 1.6+, ROOT] <appname>
Same as [Android 1.6+], but requires root.
Release dates, versions
Some apps include release dates and version numbers, suggesting that the date follow the OS specification, and version number follows appname.
For example:
[Android 1.6+, ROOT, 2010.12.31] MyRootApp v1.3 - The greatest app ever!
This is just all just a suggestion. Feel free to comment. I just think it should be easy to see these app sepecifics in the listing directly.
Click to expand...
Click to collapse
This is a great start, but what about apps that are linked to a specific type of phone?
For example, there a hardware specific apps for the Galaxy S line which includes Fascinate, Captivate, Vibrant, i9000, etc.
What I'm thinking, and feel free to offer a counter to this, is that most phones can be boiled down to a 3-4 letter identifier, which obviously includes the OS.
For example, Samsung Galaxy S series is SGS. So if I have an app for SGS I'd expect it to be:
[SGS 2.2+, ROOT]
Also in some cases there's specific features of ROM needed, for example with the SGS series again, backlight notification. I'd expect this to part of the list with ROOT.
Finally, I'd put version numbers and/or dates at the end of the post, in ()
So:
[SGS 2.1+ ROOT|BLN] My Cool App (v1.0)
[And 1.6] My Other App (01/15/11)
Any thoughts?

I think this sounds spot on. We definitely need a good naming convention given the broad scope of this new forum. Thanks much

Those are good suggestions.
However, it does require the average reader to know what all that means, it possibly makes it all too complicated.
Something like SGS could be an addition, but I think it should still simply start with the OS and version denominator.
For example:
[Android 1.6+, ROOT, SGS, BLN, 2010.12.31] My App v12
This is too long, I know. However date is most commonly in front on XDA. This should also clear up for the WM/WP users that this is not for them. An SGS user will still spot the "SGS" and know it is for them. Non-SGS users might have to read the thread to see that is is "For Samsung Galaxy S devices only!"
We need something better, but removing Android from the title isn't it, I think.

Wow seems really complex. The more it is complex the less it will be followed by OPs.
While I think it's a nice idea to open a section for paid applications I would have created it in all forums that already have an "Application etc." forum. It would sound more logical IMO and it would show OPs that they have to choose between the 2 subfora (development ongoing / paid applications for advertising only).
Creating juste one forum for all OS, devices etc. will make it difficult to find information in it and I don't think people will have the reflex to go in General forum to find applications.
If the application is in HD2 forum for example no need to have a long title people will know that the application is for HD2 only.
Just my 2 cents

You are absolutely right there, but paid apps are not allowed to be posted in the device-specific sections

Chainfire said:
Those are good suggestions.
However, it does require the average reader to know what all that means, it possibly makes it all too complicated.
Something like SGS could be an addition, but I think it should still simply start with the OS and version denominator.
For example:
[Android 1.6+, ROOT, SGS, BLN, 2010.12.31] My App v12
This is too long, I know. However date is most commonly in front on XDA. This should also clear up for the WM/WP users that this is not for them. An SGS user will still spot the "SGS" and know it is for them. Non-SGS users might have to read the thread to see that is is "For Samsung Galaxy S devices only!"
We need something better, but removing Android from the title isn't it, I think.
Click to expand...
Click to collapse
Hopefully proper sub-forums, as listed here will make the OS portion not needed.
Then phone types would make sense at the start, followed by OS version.
Finally, I was suggesting the date at the end more as a general style that would flow better. Just like for the most part, we go from least specific to most specific when identifying things (for example, Android 1.6) it would make sense that the name would come before any version or date specifier.
While I realize this would break with the tradition some user's have started, at best it is applied inconsistently so standardizing in a well known and defined way seems like a good thing.

It seems indeed they are coming.
Let us then, for the few days we still have to wait, use the suggested format of simply adding the OS name and version in front of the release ?

Chainfire said:
It seems indeed they are coming.
Let us then, for the few days we still have to wait, use the suggested format of simply adding the OS name and version in front of the release ?
Click to expand...
Click to collapse
That seems more than fair.
People may want to hold off posting until the subforums show up, to keep the mods from having too big of a headache.

Great initiative Chainfire.
Once we have a reasonable naming convention, efforts will be required to ensure that it is adhered to.

We can set the App forums to require prefixes. Much like the optional "Is this a question?" adds [Q] at the start of a title.

NotATreoFan said:
We can set the App forums to require prefixes. Much like the optional "Is this a question?" adds [Q] at the start of a title.
Click to expand...
Click to collapse
Yeah I think we should.
We'll let the committee decide on final subject format, and then have it implemented, I guess.

Good idea.

there should be a set of prefixes to choose from, at the beginning of the "create thread title" in "create new post".
you can only use from standard list and no [ ] allowed in titles, custom prefixes with { }
XDA admins would also need to run script on thread titles to replace ALL current [ ] with { } for all prefixes not in list previously mentioned.
not terribly hard, would help a bunch.

nice nice nice

Related

Proper Gnu Tools ?

I'm just curious about something.
I recently moved from the iPhone to a Nexus One.
While I noticed there are a lot of ROM cookers etc (thanks for your great work guys) the development community seems kind of thin?
For example, on the iPhone there are full sets of all GNU tools. Anything you can use in Linux/Darwin they have for iPhone. There is a full apt packaging system will full console tools. The full OpenSSH suite has been made supporting all the wireless administration that I've come to love on my phone. Basically, it makes it feel like a full computer in my hand.
Now, I love this Nexus One, but I wasn't sure what the reasoning behind no one out there doing development on this kind of stuff. You'd think a phone running Linux with all code available would attract hordes of eager coders.
Instead we get weird crap like "dropbear" that has to be recompiled yourself to even work right, and even then...haha.
Not much as far as package management in the console, and our tools come from Busybox! Just seems very odd to me, but there must be reasons that I am not seeing.
This post is really not meant as an insult because I love this OS so far etc, but it just really suprised me that full sets of standard tools are not available.
Anyone know why?
Because you have to replicate the entire standard GNU/Linux userspace, which is a bear. Most of the work is done on the Android userspace instead, and you can find the fruits of those labors on AOSP Gerrit (http://r.android.com/) and the CyanogenMOD repository (http://github.com/cyanogen/android_vendor_cyanogen).
The best bet for getting a standard GNU/Linux userspace is to just boot Debian.
For future reference, this is probably not considered the correct forum for this discussion (probably Android General or the generic Android Development, not too sure.)
EDIT: Just to address some more specific points, Android has a package manager (those .apk files you see everywhere) and Busybox makes the most of the limited internal memory and provides enough tools to manage the Android userspace.
Sorry I thought the development forum would be the right place.
The iPhone 2g/3g have only 128mb of memory, and since gnu tools aren't resident in memory there is no problem having a full compliment of them on the phone.
The problem with debian is it is not really a nice UI for a phone. It would just be nice to have my phone, plus having the GNU tools underneath.
It isn't like its a dealbreaker, it just struck me as odd that all the proper tools have been built for the iPhone, and using it really feels like a full computer you're SSHing into, where as an open source Linux based OS on android basically is lacking all of it, minus the limited functionality provided by Busybox and Dropbear (like..dropbear really?).
These things have more memory and comparable processing speed to computers running windows 98 and early XP, so there is no reason not to have everything available to you when you need it.
I'm kind of a sideline commenter here as I'm not a coder, but it just struck me as odd.
Thanks for your reply!
anethema said:
Sorry I thought the development forum would be the right place.
Click to expand...
Click to collapse
NP, it's side discussion though. "Here's a complete set of native GNU tools" would be a dev forum topic.
anethema said:
The iPhone 2g/3g have only 128mb of memory, and since gnu tools aren't resident in memory there is no problem having a full compliment of them on the phone.
Click to expand...
Click to collapse
Nonono, not RAM. Flash memory. iPhone has tons of it. G1 (where most of the developers got started, mind you) has very little. Further, the partitioning left limited room for additional binaries. There's some ways around that (symlinks, mostly), but they aren't elegant, and are subject to wiping at inopportune times if you aren't careful.
anethema said:
The problem with debian is it is not really a nice UI for a phone. It would just be nice to have my phone, plus having the GNU tools underneath.
Click to expand...
Click to collapse
I'm curious about your use case. "It would be nice" is, well, nice, but is there a need you have that the existing tools aren't fulfilling?
anethema said:
It isn't like its a dealbreaker, it just struck me as odd that all the proper tools have been built for the iPhone, and using it really feels like a full computer you're SSHing into, where as an open source Linux based OS on android basically is lacking all of it, minus the limited functionality provided by Busybox and Dropbear (like..dropbear really?).
Click to expand...
Click to collapse
I'm not sure what's with the Dropbear hate. There are not many use-cases for SSH servers on a phone, so few people have worked on it. I'd think the Android-phone-powered robot guys are the most likely to need it. But again, Dropbear is going to perform a whole heck of a lot better on a G1 than OpenSSH, and the G1 is the origin of all this stuff.
Remember, Android is explicitly not GNU/Linux. You might call it "Android/Linux." The fact that the Android userspace is open-source means that the alternate (and exciting new) userspace is attracting development, instead of people trying to port GNU just so they can use their closed-source iPhone. This is, in fact, a Good Thing, because it can result in improvements for all Android users (via contributions to AOSP), not just that subset of geeks (read: us) who mod their phones.
Understanding this difference is key to understanding the development pattern. People aren't working on the GNU userspace for Android phones because the Android userspace supplants it. The tools we have do what is needed, nothing more. In fact, `am' and `pm' are more useful in the Android context than anything that's left out of Busybox.
anethema said:
These things have more memory and comparable processing speed to computers running windows 98 and early XP, so there is no reason not to have everything available to you when you need it.
Click to expand...
Click to collapse
Back to my use case comment above. What is it that you need?
anethema said:
Thanks for your reply!
Click to expand...
Click to collapse
No problem, it's a good discussion.
I guess it is basically that you don't know what you need until you need it. I treat my phones like this basically like little computers. Certainly on a laptop/desktop no one would bother questioning why you need general tools you use to get jobs done.
For the iPhone there was a need for unique certification to apples push servers so phones that were basically 'tricked' into activating could still get push messages via these servers.
I wrote a tool called Push Doctor with phone based scripts and with a donor style one server side. Basically I was generating these certificates and people could download them. The whole thing on both side is just a bunch of shell scripts. One running on the phone, one on my and cert donors computers. Now this may or may not have worked in busybox as I haven't tested it, but I just mean you never know what you are going to use stuff for, and having a nice standard set of tools across all Linux platforms can be nice to have for this reason.
As far as the space issue, I think that whole thing seems crazy as well. You're right there is a ton of space on the iPhone, but the G1 came out after it, and the Nexus One long after it, so its too bad 'space' is still an issue these days requiring ugly hacks to circumvent.
Regardless the tools could be distributed as part of several core apk's which people could install if they wish.
Like I said above, these are hardly embedded devices anymore. It's not like there's 4kb of ram and 5 mips CPU.
As far as dropbear, it isn't that I hate it, I just think even the G1 has comparable speed to the first iPhone (not in the Graphics/UI but certainly as far as the CPU is concerned) and running something as insignificant as OpenSSH should not be an issue. I've never personally heard of dropbear, and have no idea what their security track record is, but I do know OpenSSH's. It is a VERY widely used package with a lot of eyes on it making sure it is doing what it is supposed to be doing.
Apparently the default dropbear will authenticate any password if you enable passwords and you have to build your own from source run about 50 commands, all to get it going.
Where is the APK for a working dropbear, or apt-get install dropbear? Can you even have APK's for system level packages? Everything I seem to find tends to be a custom download from someones site whcih you have to 'push' to your phone, try to follow some 50 step guide to hopefully get going, etc.
I am loving a lot of facets of this OS, I'm just curious where the community is to work on this stuff, get it going, and make it easy. Android isn't really -that- young.
anethema said:
For the iPhone there was a need for unique certification to apples push servers so phones that were basically 'tricked' into activating could still get push messages via these servers.
I wrote a tool called Push Doctor with phone based scripts and with a donor style one server side. Basically I was generating these certificates and people could download them. The whole thing on both side is just a bunch of shell scripts. One running on the phone, one on my and cert donors computers. Now this may or may not have worked in busybox as I haven't tested it, but I just mean you never know what you are going to use stuff for, and having a nice standard set of tools across all Linux platforms can be nice to have for this reason.
Click to expand...
Click to collapse
Market Enabler is in that class of application, and, like other "rooted" apps relies on shell calls to Busybox on the backend--ugly, but keep in mind this is an attempt to explicitly defeat the Android security model. BB is sufficiently standard and POSIX conformant that it hasn't posed any difficulties for these kinds of applications.
anethema said:
Where is the APK for a working dropbear, or apt-get install dropbear? Can you even have APK's for system level packages? Everything I seem to find tends to be a custom download from someones site whcih you have to 'push' to your phone, try to follow some 50 step guide to hopefully get going, etc.
Click to expand...
Click to collapse
So-called "native"--that is, ARM binary--applications aren't supported by the Android platform in the conventional way. In mid-2009, Google released the Android NDK which permits ARM binary libraries to be intermingled with Android applications via JNI. Since Android is explicitly intended to be compile-once, run-anywhere (which is why apps run on a VM), this is only recommended for computation-heavy code. However, the Mozilla project is using the NDK to directly port legacy code (Firefox/Fennec) with a thin Java interface to the Android system, so such a thing is possible.
This doesn't really make sense for the GNU toolkit, though. The SSH case; you could certainly set up an SSH server to run as a system service using NDK+JNI to connect any SSH library you like. The fact that this has not happened leads me to believe that there is little demand.
In general, the needs of existing developers appear to be met by the tools available.
Based on everything you've mentioned--you may want to take a look at the Android Scripting Environment.

About Android-What is What? Work in Progress.....

Maybe some things are a lil bit old but everytime gold,lol.
Work in progress.......
------
What is a kernel?
If you spend any time reading Android forums, blogs, how-to posts or online discussion you'll soon hear people talking about the kernel. A kernel isn't something unique to Android -- iOS and MacOS have one, Windows has one, BlackBerry's QNX has one, in fact all high level operating systems have one. The one we're interested in is Linux, as it's the one Android uses. Let's try to break down what it is and what it does.
Android devices use the Linux kernel, but it's not the exact same kernel other Linux-based operating systems use. There's a lot of Android specific code built in, and Google's Android kernel maintainers have their work cut out for them. OEMs have to contribute as well, because they need to develop hardware drivers for the parts they're using for the kernel version they're using. This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working. Drivers written to work with the Gingerbread kernel on a phone won't necessarily work with the Ice Cream Sandwich kernel. And that's important, because one of the kernel's main functions is to control the hardware. It's a whole lot of source code, with more options while building it than you can imagine, but in the end it's just the intermediary between the hardware and the software.
When software needs the hardware to do anything, it sends a request to the kernel. And when we say anything, we mean anything. From the brightness of the screen, to the volume level, to initiating a call through the radio, even what's drawn on the display is ultimately controlled by the kernel. For example -- when you tap the search button on your phone, you tell the software to open the search application. What happens is that you touched a certain point on the digitizer, which tells the software that you've touched the screen at those coordinates. The software knows that when that particular spot is touched, the search dialog is supposed to open. The kernel is what tells the digitizer to look (or listen, events are "listened" for) for touches, helps figure out where you touched, and tells the system you touched it. In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen. Both the hardware and the software communicate both ways with the kernel, and that's how your phone knows when to do something. Input from one side is sent as output to the other, whether it's you playing Angry Birds, or connecting to your car's Bluetooth.
It sounds complicated, and it is. But it's also pretty standard computer logic -- there's an action of some sort generated for every event. Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device. With the kernel, all they have to do is communicate with it through the Android system API's, and hardware developers only have to make the device hardware communicate with the kernel. The good thing is that you don't need to know exactly how or why the kernel does what it does, just understanding that it's the go-between from software to hardware gives you a pretty good grasp of what's happening under the glass. Sort of gives a whole new outlook towards those fellows who stay up all night to work on kernels for your phone, doesn't it?
-----
What is a Nandroid backup?
If you've read about hacking or rooting your Android phone (or tablet, or media player) you've seen the word Nandroid used. When tinkering with your device, there's always a very good chance you'll be left with firmware that won't boot, leaving you in a bit of a lurch. A Nandroid backup can mean the all the difference here.
What it is, is a full backup of partitions on your device's NAND flash (NAND stands for NOT AND, a type of electronic logic gate -- it's like the hard drive of your Android device) storage. Think of it as a snapshot of the current running system, and it can be used to restore that that point at any time. Both user data and system files are backed up, and it's a far cry from what we think of when talking about a traditional backup from other software. In fact, it's something that many folks wish was part of the stock Android recovery. Yes, to preform a Nandroid backup you'll need a custom recovery on your device so that the executable files and scripts are there. These have been left out of the stock recovery, likely over issues that would arise if users can backup proprietary files.
Getting the custom recovery on your device is the hardest part, thankfully. Once installed backing up and restoring with Nandroid is simple, involving nothing more than choosing the option and verifying -- no wires needed. Even if you never plan to hack your phone, flashing a custom recovery and running a Nandroid backup is always a good idea. You can find more information about custom recoveries, as well as methods to install and use them, in the device-specific section for your device in the Android Central forums. Give it a look, and decide if it's something you're interested in doing.
-------
What is an IMEI?
The IMEI (International Mobile Equipment Identity) number is a unique set of 15 digits used on GSM phones to identify them. Because the SIM card is associated with the user and can be swapped from phone to phone, a method is needed to keep track of the hardware itself, and that's why the IMEI was developed. Math nerds will enjoy the way they are calculated -- the first 14 digits are decided by the GSM association, and the final check digit is computed using what's called the Luhn Formula -- crazy base-8 math that mere mortals like most of us don't understand, nor want to understand. You can see the IMEI of your Android phone by looking in settings > About phone if you're curious. (Or on the box if you still have it. Or under the battery or on the phone itself.
What is this number used for? That's the real question, isn't it. Like the MEID number on CDMA phones (think Sprint and Verizon), the IMEI is used for network control. It's not very common, but your mobile operator can block a phone based on it's IMEI in cases where it's been reported stolen or someone didn't pay the bill. Because it's not easy to change the IMEI of your phone (and maybe even illegal -- check your local laws) it's also used to keep track of phones that were involved in criminal activity, and the UK in particular has a handy database of phones used for these purposes. The IMEI number is also used to specify a phone for wiretapping by federal governments worldwide.
On a lighter note, Android apps can also use your IMEI number. The app will declare that it has access to your personal information, and the IMEI can be used to keep track of the device in a remote database. This sounds pretty scary, but it's an easy way (though not necessarily the best way) for app developers to keep a settings database online for your phone, in their app. Let's say you mark a bunch of favorites in a wallpaper app. Those favorites are kept in a small database file online, and when you reconnect to the app it reads your IMEI number to find your preferences. Not an ideal method, but it's easy.
One last thing -- now that we know a little more about IMEI numbers, they will soon be changing to IMEISV numbers. The use-case scenarios are the same, but the data structure and method of calculation is different. An IMEISV gets rid of the check digit (and its complicated Luhn formulated calculation) in favor of two digits used for software version numbering. Like everything else in the mobile space, network identification changes rapidly.
-------
What is a bootloader?
What is a bootloader? At its most basic level, your Android smartphone is like a hard drive, made of up several partitions. One of those partitions holds the Android system files, another holds all the app data you accumulate (which is how you're usually able to update without losing all your stuff), and others to do more behind-the scenes stuff.
Think of the bootloader as a security checkpoint for all those partitions. Because if you're able to swap out what's on those partitions, you're able to break things if you don't know what you're doing. Or, with a little hackery, you're able to run custom ROMs.
There's a lot of squawking about bootloaders being "locked." Actually, most phones shipped with a "locked" bootloader, including the developer-friendly Nexus devices. (Nexus devices and a couple tablets are easily unlocked with a single command.) No, more accurately, most bootloaders are locked and encrypted, meaning the traditional "fastboot oem unlock" command won't do a thing.
And that's a bone of contention for those who love a manufacturer's hardware and want to tinker with their devices. HTC and Samsung and Motorola -- just about everyone, really -- ships devices with locked and/or encrypted bootloaders. Tinkerers (we really don't like calling 'em "hackers") have to find a way around the encryption, usually with some sort of an engineering bootloader that wasn't supposed to be available to the general public. But in recent months, we've seen HTC provide a free tool that will unlock the bootloaders on a number of its devices, and ASUS just got on board, too. Sony Ericsson recently has provided unlocking tools. Motorola's promised to do so as well, but there's been little movement. LG and Samsung ship with unencrypted bootloaders.
Why keep a bootloader out of reach? Probably the biggest reasons are that the carriers and manufacturers don't want to have to support hacked phones. The other is that a lot of time and money is spent developing these things. HTC Sense ain't cheap. Neither is TouchWiz. But Samsung and HTC both have managed to find a middle ground with the modding community, and pressure is on other companies to do so as well.
-------
What is Dalvik?
What is Dalvik? We hear that word getting thrown around a lot on the Internet when talking about Android and its inner workings. While there's no easy explanation we can give in just a few paragraphs, we can cover the basics and point you in the right direction if you need to feed your nerdly side. In its simplest terms, Dalvik is a virtual machine that runs applications and code written in Java. A standard Java compiler turns source code (written as text files) into Bytecode, then compiled into a .dex file that the Dalvik VM can read and use. In essence, class files are converted into .dex files (much like a jar file if one were using the standard Java VM) and then read and executed by the Dalvik Virtual Machine. Duplicate data used in class files is included only once in the .dex output, which saves space and uses less overhead. The executable files can be modified again when you install an application to make things even more optimized for mobile. Things like byte order swapping and linking data structure and function libraries inline make the files smaller and run better on our devices. The Dalvik VM was written from square one with Android in mind.
Confused yet? Don't feel bad, geeky programming talk usually has that effect. Think of it this way -- when you build a Java application for your computer, a Java Virtual Machine runs the compiled output of the source code. This is why Java runs on just about any operating system. Dalvik is a mobile-optimized version of a Java Virtual Machine, built with code from the Apache Harmony project, which is open-source and runs better than a standard Java VM would on our limited hardware, designed so that you can run more than one instance of the VM at a time -- ie multitasking. Because Dalvik is open-source, it's also been ported to other operating systems, like the one on the BlackBerry PlayBook. It's pretty damn complicated, pretty damn cool, and Oracle (the company that bought Java from Sun) hates it.
Android uses Dalvik because while the license for the standard Java Virtual Machine is GPL2 (free and open-source), when placed in a mobile device and using the Java Micro Edition, it is not. The big dispute between Google and Oracle is all based around Dalvik. Google claims it was written in a "clean-room" environment without using any of Oracle's code, and Oracle disagrees. We claim to have no idea, we're just glad it works as well as it does.
For more on Dalvik, see the Google I/O website.
--------
LG's L-series
They made a big splash earlier this year at Mobile World Congress, and a few carriers in Canada jumped at the chance to sell them, but then they seem to have fallen off the map. I'll admit, even I have to look and see what we're talking about when we have potential news about the L3, L5, or L7. Let's have a refresh.
Imagine LG's Prada phone, but remade for folks who don't buy Prada. The L-series phones are all stylish (and really resemble LG's iconic Prada phones -- check out our look at them in Barcelona) and have an emphasis on good looks. The entry-level L3 competes with phones like HTC's One V and Samsung's entry-level Galaxy phones. It's running Gingerbread on a 3.2-inch display, but it looks nice doing it. Compared to something like the Motorola Defy Mini, you get good looks along with your dirt-cheap pricing. The L5 takes things up a notch to Ice Cream Sandwich and a 4-inch screen, placing it in the middle of the road where most people look first when buying a new smartphone. They'll see the L5, and notice the build materials and design. Finally, the L7 looks to compete with the big dogs of the Android world, with all the bells and whistles you would expect from a high-end smartphone, in a damn fine looking external shell. All three are eye-grabbing, and getting people to notice is the first hurdle. We're really not sure why we don't hear more and see more about them, but we're guessing a saturated market has something to do with it.
Maybe we'll see the L-series phones make their way into the spotlight, maybe we won't. But at least now we all know what we're talking about when we see them mentioned.
-----------
Multitasking
Multitasking is a word you'll hear a lot around here and at other places on the Internet that talk about smartphones or other tech. It doesn't mean what it used to, back when dinosaurs with long beards first dreamed up computers, but it still makes a very big difference for some folks and can be the deciding factor when picking a smartphone operating system. Let's have a look and see what the fuss is all about, and how it relates to Android.
A long time ago, in a laboratory far, far away, some Jedi masters decided that computers should do more than one thing at a time. They really already were doing plenty of things behind the scenes, but to the user it was a case of entering a command, and waiting for it to finish. Using threads and schedulers, and probably a little magic and a lot of luck, engineers were able to work up an operating system that could run more than one user command at a time, and multitasking was born. When you switch to a new VT (virtual terminal) on a Unix box with no GUI, you're multitasking. When you have more than one window open on your Windows or Mac or other computer that does have a GUI, you're multitasking. You're doing more than one thing at a time, and the computer is running more than one user task at a time. You can now read Android Central while your completely legal torrents are downloading in the background.
On a smartphone, multitasking is a bit different. We don't have the luxury of a 20-inch monitor, so showing more than one "thing" running at a time isn't a big deal. Samsung is testing the waters and trying it with the Galaxy S III with the Pop-Up Play feature, but for the most part whatever we're doing takes the whole screen to do it. We also don't have tons of RAM and video memory available and have to watch the power usage. This means smartphone multitasking has to be a bit, well, smarter.
Smartphones have been multitasking for a long time. All the mobile operating systems do it a bit differently -- some suspending all other apps in the background, some saving the state and closing the app itself, and others just letting everything run. The way Android does it is to let threads and processes run depending on their priority. If you're using Google Play Music, the processes that make the sound come out of the speaker have a high enough priority to stay running when you switch away from the app. Not all of it is running in the background, but enough of it is to keep the tunes playing. Other apps can be killed if they aren't being used, and some apps get "frozen" (for lack of a better word) and restore themselves when brought back to the foreground. What's important, and prioritized, is decided when the application is written and compiled so the end user doesn't have to worry about it. It's not perfect, but it follows the very strong multitasking model from Linux and tweaks it for Android. It's all open-source, so manufacturers and ROM builders can (and have) tweaked things to allocate memory the way they want it allocated. Sometimes the tweaks are great, sometimes not so much.
In the end, remember the next time you open an app and start up where you left off that you're seeing multitasking at work.
----------
Haptic feedback
It's one of those little things that can make a big difference, and something we never really think about. Simply put, haptic feedback (commonly referred to as haptics) is the use of touch feedback to the end user. You know how your Android phone vibrates a tiny bit when you tap one of the navigation buttons? That's haptics at work.
Since the screen on your Android phone or tablet is pretty much just a smooth sheet of glass of some sort or another, it's difficult to register any sort of tactile feedback to our fingers. When we type on a computer keyboard, we know when our fingers have pressed a key down. Our mouse (and some trackpads) do the same thing with a healthy click when we press the button. On a smartphone, we just have to trust we've done something, and wait for it to happen. Haptics helps here. The short and light vibration when typing out a message with an on-screen keyboard can make a big difference for many of us, and I can see myself being pretty frustrated if an on-screen button didn't let me know I had pressed it.
Haptics go beyond navigation and the keyboard though. They can be a very important part of mobile gaming. Gunning your way through an enemy horde is much more satisfying when you feel every shot from your rifle, and nothing lets you know you've hit the wall in your favorite racing game like a harsh vibration from your phone or tablet.
Probably the best thing about haptic feedback on Android devices is the way it can be customized. The OS itself is open, meaning OEM and developers can adjust things to get them just the way they like, including leaving the settings wide open to the user like we see in CyanogenMod ROMs. More importantly, application developers have access to the hardware controller to customize haptic feedback for their products. It goes one step further with the addition of things like the Immersion haptic SDK to the mix, where developers have an almost unlimited way to make their applications register with your fingers as well as your eyes and ears. Sometimes, the little things mean a lot.
--------
F is for Factory Reset
A factory reset is the ultimate cleansing of your Android device. It's usually either a last resort to fix a problem, done before you sell it, or because you like to flash ROMs. When you perform a factory reset you're essentially wiping out everything you've ever done to the phone and restoring it back to the basic manufacturer software. As we've mentioned before, it doesn't uninstall any software updates you've received from the folks who made your phone, but it does wipe out any core application updates you've grabbed from the Google Play store. The technical details are as follows:
/system is untouched, because it's normally read-only
/data is erased
/cache is erased
/sdcard is untouched
When your phone or tablet reboots, it's like it was when you opened the box as far as apps and user data goes, except for your data on the SD card partition (either a real, physical microSD card or a partition named sdcard).
Doing a factory reset is easy -- open the settings, do a little digging (different manufacturers put it in different places, but start with privacy or storage), select it and confirm. Your device will reboot into the recovery partition, erase everything, they reboot into the setup again. One thing to note though -- if you've rooted and ROM'd in any way, you should never do a factory reset from settings. Often times it works just fine, but some devices and some ROMs are so different once hacked that you'll end up with a bricked phone. We hate bricked phones around these parts. Follow the instructions from the folks who developed the software you're running instead, and use the reset method they recommend.
-------
End of life
End of life is a term none of us ever want to hear. We envision it means the death of our phone, and we should just throw it away and get a newer model. After all, it's at the end of its life, right? Not really. End of life means something different to carriers and manufacturers than it does to enthusiasts like us. The easy way to look at it is that when the folks in suits get together and decide that a phone isn't going to make enough money so it's worthwhile to keep producing it, it has reached the end of its life. That may mean a refreshed, newer model (like the Droid RAZR MAXX), or a shift to a newer model with new, and arguably better, features like the EVO 3D. We have to remember that the folks who make these phones do it so they can make money, and like any good business they want to maximize their profits.
But what does end of life mean in the real world? First off, it means that once the current stock sitting on the shelves is sold there won't be any more new ones to replace them with. There may be refurbished units floating around, but no more new phones of that model are being made. It doesn't mean that the phone is done getting updates, but don't expect too many new features to come along -- things are in maintenance mode and bug fixes and security patches are the only things that will be addressed. It also doesn't mean your warranty is affected in any way. Even if you were to buy a brand new phone that has already reached the end of life status, you'll still get the full manufacturers warranty.
Most importantly, it doesn't mean that the phone is going to stop doing anything it already does today. The HTC EVO 4G is a great example. It was a huge hit for HTC and Sprint, and actually stayed in production longer than any of us would have thought. Some places are still selling them new (although they're getting harder to find), and those EVO 4G's sold new today are every bit as good, and have the same warranty from HTC, as the ones sold in 2010. Sprint still offers customer service, and it's still one heck of a phone.
Don't be put off by the words end of life. While we wouldn't recommend you search out a new phone that's already been discontinued, they still perform as they should and you'll find lots of folks who still love them.
----------
DLNA
DLNA, or the Digital Living Network Alliance is an organization set up by Sony in 2003 that determines a universal set of rules and guidelines so devices can share digital media. The devices covered include computers, cameras, televisions, network storage devices, and of course cell phones. The guidelines are built from existing standards, but manufacturers have to pay to use them and have their device join the DLNA.
With DLNA devices, you can share video, music and pictures from a Digital Media Server (DMS) to your Android phone or tablet. A DMS could be your computer, a NAS (Network Attached Storage) device, a television or Blu-ray player, or even another Android device. Anything that has a DLNA server, or can have one installed will act as a DMS. Fun factoid: when a DLNA server is installed on a cell phone, tablet, or portable music player it's called a M-DMS -- the M stands for Mobile.
Once a DLNA server is in place, our Android phones usually have two functions -- to act as a Digital Media Player (M-DMP) or a Digital Media Controller (M-DMC). The player is easy enough to figure out, it finds content on a DLNA server and plays it back. A DMC will find content on a DLNA server, and push it to another connected player. For example, my television has a DLNA player, and my laptop has a server. With the right software, I could use my Android phone to find the content on my laptop and play it on my television. DLNA can really be fun if you have all the right equipment.
But chances are Android (and eventually other mobile devices) will be moving away from DLNA. With Ice Cream Sandwich, Wifi Direct is part of the operating system and has the potential to do everything DLNA can do, and more. We already have seen it replace DLNA streaming in the HTC One series with the Media Link HD receiver, which streams content from a Sense 4 device to a monitor with HDMI input. It uses native Wifi Direct, and by all accounts works really nicely. Or Samsung, who is using NFC to kick off a Wifi Direct session for fast data transfer on the Galaxy S III. We'll have to wait and see what manufacturers do with Wifi Direct, because having it built into the OS is a big plus -- even for a company like Samsung who makes millions of DLNA devices each year.
---------
Bloatware
When you think of Android phones, you think of bloatware. We wish it weren't so, and not every phone comes with, but the majority of Android phones out there come from carriers and are chock full of bloatware. We've complained about it, and found ways to remove it, but what exactly is it?
Most folks consider any applications that your carrier (or the folks who built your phone) pre-installed to the system as bloatware. Usually, these applications are a front end to some service or content that you'll have to pay for, and usually it's something you would never download and use on your own. All the carriers, and all the manufacturers, are guilty of including it, and we tend to hate it all equally. When you open the app drawer on your new phone, and see City ID staring back at you, just waiting for you to click it, you can't help but hate it.
But why is it there? It's one down side of Android's open nature. Google gives Android away to anyone and everyone, but realistically only a very few companies can afford to make cell phones. And they don't make them with you and me in mind as their customer. HTC, or Samsung, or LG (you get the picture) makes Android phones for the carriers. They work out deals to decide hardware and software they want to include, and part of those deals are these "value-added applications" we lovingly call bloatware. Verizon and HTC love you, but they still want you to click the app and send in the money. Because Google isn't involved and doesn't make any rules about it, they can include any app they like in your new phone. Nobody likes it, but it is the side effect of being open.
Thankfully, Ice Cream Sandwich brings along the ability to disable (most of) these apps without rooting or tinkering with the system files on your Android device, and that provides the best solution we can think of. Certainly there are some people who found a use for City ID or VZ Navigator, and they should have the opportunity to use those apps if they like. And we can disable and hide them, and forget they exist.
What is the AOSP?
AOSP is a term you'll see used a lot -- here, as well as at other Android-centric sites on the Internet. I'll admit I'm guilty of using it and just expecting everyone to know what I'm talking about, and I shouldn't. To rectify that, at least a little bit, I'll try to explain what the AOSP is now so we're all on the same page.
For some of us -- the nerdly types who build software -- the full name tells us what we need to know. AOSP stands for Android Open Source Project. The AOSP was designed and written by folks who had a vision that the world needed an open-source platform that exists for developers to easily build mobile applications. It wasn't designed to beat any other platform in market share, or to fight for user freedom from tyrannical CEOs -- it exists as a delivery mechanism for mobile apps -- like Google's mobile apps, or any of the 400,000+ in the Google Play store. Luckily, Google realized that using open-source software would ensure that this operating system/mobile application content delivery system is available for all, for free. And by choosing the licensing they did, it's also attractive to device manufacturers who can use it as a base to build their own mobile OS.
The premise plays out rather nicely. Google writes and maintains a tree of all the Android source code -- the AOSP. It's made available for everyone (you, me, manufacturers you've never heard of and not just big players like Samsung or HTC) to download, modify, and take ownership of. This means the folks at CyanogenMod can add cool stuff like audio profiles. It also means folks like HTC can change multitasking in ways that many of us don't like. You can't have one without having the other. The big players then use their modified version of this source to build their own operating system. Some, like Amazon, radically changed everything without a care to use Google's official applications and keep their device in compliance with Android guidelines. Some, like HTC radically changed everything yet followed the Android Compatibility Program (ACP) so they could include Google's core application suite -- including the Google Play store. Some, like the folks at CyanogenMod, enhance the pure AOSP code with additions but don't change the overall look and feel. Again -- that's how this open-source thing works. You can't have it without allowing folks to change it as they see fit, for better or worse.
Any of us can download and build the AOSP. We can even stay compliant with the ACP and contact Google about including their applications. Yes, any of us could build our own device using the AOSP code in our garage or basement with Google's full blessing. That's the beauty of the AOSP, and we wouldn't want it any other way.
--------
What is a widget?
What is a widget? In Android, the word widget is a generic term for a bit of self-contained code that displays a program, or a piece of a program, that is also (usually) a shortcut to a larger application. We see them every day on web pages, on our computer desktop and on our smartphones, but we never give too much thought into how great they are. Widgets first appeared in Android in version 1.5, and really gained traction thanks to HTC's Sense-flavored version of the operating system. Prior to the release of the HTC Hero and our first taste of Sense, widgets were functional, but pretty bland in appearance. Since then, OEMs and independent developers alike have done some marvelous things with widgets, and it's hard to imagine using Android without them.
Android widgets come in all shapes and sizes and range from the utilitarian 1-by-1 shortcut style to full-page widgets that blow us away with the eye-candy. Both types are very useful, and it's pretty common to see a widget or two on the home screen of any Android phone. A full-page widget, like HTC's weather widget for late-model Android phones, tells you everything you need to know about the current conditions, and is also a quick gateway to the weather application where you can see things like forecasts and weather data for other cities. At the other end of the spectrum, the Google Reader 1x1 widget watches a folder in your Google Reader account and tells you how many unread items there are, and opens the full application when pressed. Both are very handy, and add a lot to the Android experience.
Most Android phones come with a handful of built-in widgets. Some manufacturer versions of Android offer more than others, but the basics like a clock, calendar, or bookmarks widget are usually well represented. This is just the tip of the iceberg though. A quick trip into the Android Market will dazzle you with the huge catalog of third-party widgets available, with something that suits almost every taste. With Ice Cream Sandwich supporting things like higher resolution screens and re-sizable widgets, it's going to be an exciting year seeing what developers can come up with.
--------
What is tethering?
What is tethering? Besides the grounds for a giant debate about ethics (the kind that you can only find on the Internet) tethering, in this case, means to share the Internet connection from your phone with other devices. There are several ways to accomplish this -- connecting your phone to your computer via USB, setting up your phone as a wireless hotspot and router, and sharing a data stream over Bluetooth. All these connection types are built into Android, with native Bluetooth tethering new in Ice Cream Sandwich. Of course, different manufacturers can, and have, modified things so that these options are excluded -- at the behest of the carrier, of course. We'll talk more about why in a few minutes.
Tethering itself is pretty easily done. USB tethering involves installing device drivers (Windows only) and plugging in your phone to a high-speed USB port on your computer, then using your computer's built-in connection manager to use the phone or tablet as a USB modem. Bluetooth tethering will need the phone paired with the computer, and the connection type set up correctly in your computer's Bluetooth settings. Wifi is the easiest way -- you just turn it on and connect as you would any other wireless hotspot.
Except that many carriers, especially in the United States, have blocked tethering this way.
You see, your carrier wants to charge you a premium to use your data plan from any device besides your phone. Nobody likes it, but it's in the terms you agreed to when you signed up. They have all sorts of ways to block tethering on their end, and they are pretty diligent about it. Android hackers and developers also have found ways to work around these blocks, and it's a big cat and mouse game. An inside source with one the the biggest cellular carriers in the world has specifically told me that if your usage pattern draws suspicion, there is no current method that can't be detected by you carrier, including the newer VPN methods. If you do it a lot, without paying the extra fees associated with it, you'll get caught.
We're not going to judge anyone, and a few of us here at Android Central think charging extra for tethering is silly -- especially with data caps. Just know what may happen before you start so you don't get caught unaware.
---------
What is sideloading?
What is sideloading? It's a term you see a lot thrown around while talking about Android applications, and it's simple to explain. It means installing applications without using the official Android Market. What's less simple is how it's done and why you would do it. That's where this post comes in. Let's explain it, shall we?
How to do it is easy enough, so let's start there. In the Application settings on your Android phone, you'll find a check box to "Allow installation of non-Market applications." When it's checked, you can sideload. You'll also see a pop-up warning when you check this box letting you know that your phone is now more vulnerable to attacks from applications, and that you accept all the responsibility that comes with doing this. It makes sense -- you can't hold Google responsible for applications you didn't download through their service using their security methods.
Sideloading apps is easy to do as well. You download them to your phone, then use a file manager application to find them and "click" their entry. You'll invoke the app installer program, and it will install your app just as if it had came from the trusted Android Market. It won't be associated with your Android Market account, but it shows in your app drawer just like all the rest. It didn't used to be this easy for everyone. Under the guise of security, AT&T used to block users from sideloading by removing the Unknown sources field in the device settings. Whenever you tried to manually install an app, it would be blocked because it wasn't allowed. This could be circumvented by using adb from the SDK or by using a program like the Sideload Wonder Machine. Luckily, those days are past us and AT&T has re-evaluated their position, and now allows the installation of non-Market apps.
Why would you want to sideload. There are several reasons, one being that Google has allowed carriers to block certain applications based on the model and network your device is running on. We've seen carriers block apps that permit tethering without paying the extra associated fees, and some carriers have exclusives for certain apps and they aren't available for the others. That's a whole other mess that we'll tackle in another post -- just know that it happens. There are other reasons to need to sideload apps, too. Want to use a different appstore like the one from Amazon? You'll need to enable sideloading. The same goes for beta testing apps for developers, or even coding your own apps and testing them on your phone. There are a lot of legitimate reasons for sideloading. Of course, there's always the piracy aspect. If you want to steal from hard working developers you'll need to enable sideloading. You also suck. Sideload, but don't steal from developers.
--------
What is open source?
What is open source? Open-source software is software that makes the source code freely available, for anyone to see and use. There are different open-source licenses that have different use conditions, from the GPL (GNU General Public License) -- which allows "free distribution under the condition that further developments and applications are put under the same license" -- to more liberal licenses like the Apache License, which doesn't require modifications to be open and have the source code available. Android uses both of these licenses, and we'll have a look at them in turn.
The Linux kernel that is used in the OS is covered under the GPL. This means that any changes made to the source code must be made available when a binary (geek-speak for a compiled, executable piece of software) is released to the public. This means manufacturers like HTC, Samsung, Motorola and the rest must release the kernel source-code for any devices they sell at the same time they begin selling them. For the most part, hardware manufacturers are pretty good about doing so, but they often miss the time frame and release the source code a little later than we would like. These are the code releases you see us mention -- the kernel and other open-source "bits" that are covered under the GPL.
The Android OS source code is released mostly under the Apache License. Anybody is allowed to download the source code and change it however they like, but they are not required to make their changes available in source code form to the public. This is why we can't change and recompile things like HTC Sense or MotoBlur -- the changes to the base Android source code aren't available to us. While many folks (myself included) don't like this situation very much, it does make sense from a business standpoint. If manufacturers had to share all of their secrets, there wouldn't be as much monetary incentive to innovate, so the source was offered with a far more liberal license. It certainly worked, as we see devices from many major players in the electronics world.
---------
too,too
aaaaaand too
Good one buddy!
It's good for noobs!
And pro's!!
updated 2+3 post.
Awesome guide bro very informational
Can you emphatize in any way the questions ? Like bold it.
I try to read but i get lost easly x'D
Yeah i know what u mean,i do it with colors.
NERDIFIED TILL DEATH!!!
I like this so far. Please keep up the good work.

[Q] CLOSED: Android Studio -- Current Documentation?

I'm going through all the features of the current version of Android Studio (version 1.0.2) and am frustrated by the documentation. There is existing documentation at JetBrains, but much of it appears to be out of date. I've wasted a fair amount of time trying to follow some sections of documentation only to finally decide that they are simply incorrect; then, of course, I have to work through the system by trial-and-error.
My question is: Is there any comprehensive documentation for the current incarnation of Android Studio? The best I've found so far is the book, "Android Studio Development Essentials" by Neil Smyth. Even that, however, spends far more pages on Android development in general than on the Android Studio too.
As an example, take a look at https://www.jetbrains.com/idea/help/accessing-module-settings.html. The first step is to bring up the Project Structure dialog. That comes up fine, but appears to have been completely redone and the very next step, "click Modules", doesn't appear to be pertinent any longer. Furthermore, the "Modules page" that that should bring you to doesn't seem to exist any more (at least I couldn't find it anywhere). This (i.e., module) information seems to be retained in the app.iml file (the module is called "app"), but I don't see where it can be modified in the GUI.
I have a few questions about Android Studio (given the above), but will post them separately.
Thanks for any pointers .
Barry
-------------
UPDATE:
From IntelliJ Support:
Online documentation is for IDEA, not for Android Studio. Android Studio is a narrow tool for Android development, so it doesn't have all IDEA features.
Android Studio is based on IDEA core code, but it is developed by Google.
Closing this item out. (Although, not to put too fine a point on it, I still don't know where good/accurate/current documentation is for Android Studio (Google?).)

Linux head unit

Hi, this is probably in the wrong section.
Does anyone manufacture a head unit running Linux, something for which I can just download a debian ARM iso and install from a usb stick/sd card? From what I can find it seems not to be the case. Why not? Why is android so prevalent?
I also have a question. I just bought an E46 with an eonon GA5150 which is MTCB-KLD-v2.30. I updated from 4.2.2 to 4.4.4 with Malaysk's ROM, but not the MCU, and now audio doesn't work at all. How should I begin to troubleshoot this issue?
Thanks, to a community I should have joined many years ago.
Answer to the first question is...um...well Android is running a Linux kernal...so...you can make the case it's running Linux (or a forky version at least).
As far as running Debian ARM on the typical SoC in these head units, I think it's very likely possible...if you are willing to write the drivers or chase them down (if they exist). And configure the system...it's not a super mountain to climb, but I doubt it's something that already exist. At least in binary format that you could put on an a USB key and install.
In fact, you would have to create a custom Debian build, most likely, and use a bootloader that is normally setup for Android (guessing on that one) to install it. There is no technical reason it should not work, just no one has bothered to do it. We already have Android, what does Debian Linux buy us?
Why run Android? Well, it's because that's where the focus of the development effort is for the kinds of apps you would most likely want to use in a car. My opinion is that's why these head units exist in the first place. The vast number of really good (and admittedly incredible number of poor) apps already exist...let's tap into them!
If you really want to run Linux in the car for some reason or another, there are other options out there...might look for "carputers" or "car PCs". I think a lot of folks who are determined to run Open Source car computers are now running Raspberry Pi (or similar) SBCs..seems to be a lot of that type of projects on Google, when you do a search.
On the second question...about your head unit's ROM issues, I defer to the experts on here.
fortune80211 said:
Hi, this is probably in the wrong section.
Does anyone manufacture a head unit running Linux, something for which I can just download a debian ARM iso and install from a usb stick/sd card? From what I can find it seems not to be the case. Why not? Why is android so prevalent?
I also have a question. I just bought an E46 with an eonon GA5150 which is MTCB-KLD-v2.30. I updated from 4.2.2 to 4.4.4 with Malaysk's ROM, but not the MCU, and now audio doesn't work at all. How should I begin to troubleshoot this issue?
Thanks, to a community I should have joined many years ago.
Click to expand...
Click to collapse
Yeah, @tbd2k2 is right - Android IS Linux, albeit one that uses a very old Linux kernel (google is trying to rectify this but its gonna take years).
There are versions of Ubuntu (Debian based) that run on RK3188 devices, so I m sure someone who is experienced enough could make an Ubuntu ROM for MTCB/C units, but it would involve making all the MTC apps work with it too.
Thank you
What exactly are the mtc apps? What are they needed for? (Do you have a link I can read?) What kind of drivers would I need to write and how would I find what they are if I were to attempt something like this myself?
The reason I ask is that it seems to me that it's very difficult to update software on these head units. It takes a very specialised piece of software and it's impossible to keep up to date.
If these head units were just generic arm PCs then people could install whatever they wanted. I agree that most people would want to install android, but even then the situation would be simpler. Aren't these head units just 12V DC in, audio and video out with additional drivers for GPS, WiFi etc?.
fortune80211 said:
Thank you
What exactly are the mtc apps? What are they needed for? (Do you have a link I can read?) What kind of drivers would I need to write and how would I find what they are if I were to attempt something like this myself?
The reason I ask is that it seems to me that it's very difficult to update software on these head units. It takes a very specialised piece of software and it's impossible to keep up to date.
If these head units were just generic arm PCs then people could install whatever they wanted. I agree that most people would want to install android, but even then the situation would be simpler. Aren't these head units just 12V DC in, audio and video out with additional drivers for GPS, WiFi etc?.
Click to expand...
Click to collapse
Read the wiki in my signature, it will answer all your questions.
"Very difficult to update" ? - what makes you think that ? - its as easy as you like - put update on sd card go to settings/updates hit "update", or hold down power and reset, release reset, release power to get into recovery and install update by clicking on it, very easy.
Sorry, I didn't mean in that sense.
I mean that if you want to run something obscure, it's not possible. If you want to run an app that only runs on later versions of android, it's not possible. The actual installation is as easy as can be, but you are limited to a small selection of android ROMs.
I realise that it's the way it is for a reason and I'm very grateful to the community of developers here who have contributed so much. I'm just looking for something different and wouldn't mind a project for myself.
Thanks
EDIT: Also, recently Linux operating systems (Ubuntu), and even windows are moving toward touchscreens. There's a huge amount of present and future development effort we could tap into if our hardware was compatible.
I have been a Unix/Linux IT professional for more than 25 years, and it also happens that electronics is my hobby, and I have build many things in recent years powered by Linux using the great new small boards such as Rasbperry Pi's, Beaglebone, Orange, etc.. including weather stations, wall clocks/electronic displays, radio receivers, etc.
BUT, Even I would not use a generic Linux system in place of these purpose built android devices. Using android which has a wealth of high quality apps dedicated to mobile device use for GPS, Maps, media, etc is infinitely more practical.
fortune80211 said:
Sorry, I didn't mean in that sense.
I mean that if you want to run something obscure, it's not possible. If you want to run an app that only runs on later versions of android, it's not possible.
Click to expand...
Click to collapse
Are you talking about apps not showing up in the Playstore or not installing when sideloaded ?
fortune80211 said:
The actual installation is as easy as can be, but you are limited to a small selection of android ROMs.
I realise that it's the way it is for a reason and I'm very grateful to the community of developers here who have contributed so much. I'm just looking for something different and wouldn't mind a project for myself.
EDIT: Also, recently Linux operating systems (Ubuntu), and even windows are moving toward touchscreens. There's a huge amount of present and future development effort we could tap into if our hardware was compatible.
Click to expand...
Click to collapse
nixfu said:
I have been a Unix/Linux IT professional for more than 25 years, and it also happens that electronics is my hobby, and I have build many things in recent years powered by Linux using the great new small boards such as Rasbperry Pi's, Beaglebone, Orange, etc.. including weather stations, wall clocks/electronic displays, radio receivers, etc.
BUT, Even I would not use a generic Linux system in place of these purpose built android devices. Using android which has a wealth of high quality apps dedicated to mobile device use for GPS, Maps, media, etc is infinitely more practical.
Click to expand...
Click to collapse
I ve been using Ubuntu since 2009 and I ve been following the development of Ubuntu Touch for phones/tablets for a while as well - I d love it but until someone gets ART running on Ubuntu Touch so you can use Touch apps (which can also run on Ubuntu desktops) AND Android apps, I wont be using it (and I dont think many others will either) for precisely the reason that @nixfu says - I dont wanna loose access to all the apps available for android.
nixfu said:
I have been a Unix/Linux IT professional for more than 25 years, and it also happens that electronics is my hobby, and I have build many things in recent years powered by Linux using the great new small boards such as Rasbperry Pi's, Beaglebone, Orange, etc.. including weather stations, wall clocks/electronic displays, radio receivers, etc.
BUT, Even I would not use a generic Linux system in place of these purpose built android devices. Using android which has a wealth of high quality apps dedicated to mobile device use for GPS, Maps, media, etc is infinitely more practical.
Click to expand...
Click to collapse
Look at this one: https://www.stepstone.de/stellenang...d-Unit-f-m-Ulm-BMW-Group--4333376-inline.html
BMW is obviously trying to work on exactly that; trying to professionally use Linux for Car Entertainment
I've pulled apart the system image for the 2016 and 2017 Kenwood units and it's just a QT app on top of the Linux kernel.
Sony's XAV-AX100 is the same and i'm pretty sure the new Pioneers are the same now they've dumped Android.
Once you stop them booting into the GUI app and get a console, you've got a Linux system with good enough hardware to play with.
All three also have sites where you can get the code for things like the kernel that they have to make available.
leonkernan said:
I've pulled apart the system image for the 2016 and 2017 Kenwood units and it's just a QT app on top of the Linux kernel.
Sony's XAV-AX100 is the same and i'm pretty sure the new Pioneers are the same now they've dumped Android.
Once you stop them booting into the GUI app and get a console, you've got a Linux system with good enough hardware to play with.
All three also have sites where you can get the code for things like the kernel that they have to make available.
Click to expand...
Click to collapse
Sounds great, I guess you could even run Android apps on them as you can do that on a Linux desktop.
Google search i-carus (raspberry pi based)
Give that a go

Rom without or with minimal amount of bugs... recommendations for developer / users

Hi,
can any of you recommend the Rom to be fully functional and without any major bugs? Which of the basic normal functions must work and most do not work:
- enabling / disabling locations from the drop-down upper bar
- the ability to remove the search bar from the bottom of the background of the main screen and the date and time from its upper part (unnecessarily blocks the space, from this are the widgets)
- adaptation to fast charging, with a minimum current of 2000 mAh
- small date and watch with seconds on the upper beam
- list of connections as in older versions of android with a specific date and time, not in the type "3 days ago"
- dark background in the call list and sms messages
- software flashlight
- 8 shortcuts in one line (upper pull-down bar)
- main screen number of columns 8, number of lines 9
- working encryption
- average memory consumption max 1.5 GB
- security update status> March 2020
- advanced restart
- gallery with menu offering after the first click, e.g. image rotation, etc.
- installation file without Gapps and max 600 MB!
- rom created min 1-2 months ago, constantly updated
None of the following systems:
AospExtended-v7.0-santoni-20200309-1447-Dhruv-BUILDS (my favorite, No. 1)
crDroidAndroid-10.0-20200319-santoni-v6.4-LuisROM
Havoc-OS-v3.3-20200306-santoni-Official
Xtended-santoni-OFFICIAL-20200316-XQ-Rel-v7.0
RevengeOS-3.2-Q-OFFICIAL-santoni-20200319-0633
aicp_santoni_p-14.0-WEEKLY-20200328 (my favorite, No. 2)
RR-P-v7.0.2-20200213-santoni-Unofficial-LuisROM_9
AospExtended-v6.7-santoni-20200318-1847-Final_9 (my favorite, No. 3)
SuperiorOS-Phoenix-santoni-OFFICIAL-20200331-0941 (my favorite, No. 4)
can offer the above combined functionalities without the need to install additional software.
Worst of all, the developers do not respond to comments and submissions.
Some of them are almost perfect, but the grid density, hotspot, or the right number of columns settings are missing.
I was thinking about LineogeOs .. but this is a very limited rom in terms of personalization and settings. Practically like MIUI.
Table from a comparison of Roms:
https://docs.google.com/spreadsheets/d/1tCVfL3i3j6H9mWrmzM_q-erkzYRjm2PRzNjwmNyNTPE/edit?usp=sharing
How about you build your own ROM ? No offence. I've been thinking the same I too need the exact features you ask for. But I do not have any coding knowledge to build a rom. Tho I'm willing to learn but I don't find anything that would teach me lol. (searching YouTube too build a rom would be futile since some videos are either old that it's not the current format and or if it is the current format they talk as if we already have knowledge of what they're talking about). But otherwise lineage with nothing in it would make good empty cup to fill tea or coffee of your wish to fill in. But I know it's p.i.a to have additional softwares like magisk or apps, thus comes ROMs of other better developers but with one noticeable flaw that the ROMs are not customised to your liking. So the only option left for you is to build your own ROM. I guess lineage allows you to customise and share your ROM however you like it.
Lineage hasn't been updated in 7 days(usually within 5 days you'd have gotten an update) .. I think the official version is gonna jump from 16.0 to 17.1. if it did I hope the features you asked for would be there. Obviously except the gapps one.
Thanks for the message .. what are you not angry
I also thought to build my ROM, I have energy for it, but no time at the moment. I did not check how to build instructions ... if you do not need to be able to program it sure and it would do the trick.
In addition, Remi 4x is a bit old equipment, but still without a successor in these dimensions and with such a battery. So he'll probably live some more. I do not know to what extent the knowledge and rom prepared for a given phone can be used to transfer everything to a possible new phone model.
In my opinion, LineageOs is unnecessarily updated every day ... it's a waste of time - because no one updates the phone so often! Unless there are some patches from your phone by checking for updates (partial additions, like in Windows) that I don't know about?
Downloading 600 MB of data each time is also an unnecessary load on connections.
In fact LoS 17.1 may be showing up at any moment, but I am convinced that not much will change. Do not understand and understand that the community and developers completely ignore bug reports! I also do not understand the logs, since the applications are based on freshly installed software and ordinary uncomplicated, perfectly visible faults.
A lot of new ROMs are being created, but if I don't see earlier versions and the creator is little known then I will certainly not install such software. Unfortunately, I value privacy.
All in all, I prefer a ROM with minimal additions, embellishments, etc. but with lots of settings. The Rom remix was such, but from June 2019 it is not updated.
In addition, I see a lot of duplicate settings not needed from several places on the system. Elementary deficiencies in the ergonomics of use. I have the impression that Android was built for the first time and in addition they were students ... and yet it already has several editions. How much time has passed and how much discussion was about dual-sim, and yet it was a standard that was obvious.
Developers are developers, but certainly Google itself is extremely mixed in all this. Probably, if not for the huge number of devices and even more subcontractors, something could be created that would be fully open to the benefit of all users, such as Firefox, Openstreetmaps or Linux Manjaro.
Probably I will return into Los:
https://forum.xda-developers.com/li...c-settings-t4083435/post82298887#post82298887

Categories

Resources