http://www.androidpolice.com/2016/0...s-undergoing-major-layoffs-may-pivot-to-apps/
The layoffs most heavily impact the open source arm of the Android ROM-gone-startup, which may be eliminated entirely (not CyanogenMod itself, just the people*at*Cyanogen Inc. who work on the open source side).
Related
Was thinking, given that Microsoft Window's 8 is based partly on Window's phone 7/7.5 etc, and Mac OS is also based on the ios software, when Android releases Ice cream sandwich, would it be possible to produce a PC version? Kind of like a linux version, open source etc seeing as it contains a linux kernel.
Given that it would only run on ARM to start would mean limitations, but surely there would be a way to build a new boot system or kernel to work on non-ARM devices? Sure, it would be a lot of work etc but it could be tied in to the android market, and offer lots more flexibility to the system.
Seeing as Google released the chromeOS, why couldn't the android devs have a crack, I don't know, just rambling on. Let me know what you think below and get a few ideas rolling
Sure.
zm15011992 said:
Was thinking, given that Microsoft Window's 8 is based partly on Window's phone 7/7.5 etc, and Mac OS is also based on the ios software, when Android releases Ice cream sandwich, would it be possible to produce a PC version? Kind of like a linux version, open source etc seeing as it contains a linux kernel.
Given that it would only run on ARM to start would mean limitations, but surely there would be a way to build a new boot system or kernel to work on non-ARM devices? Sure, it would be a lot of work etc but it could be tied in to the android market, and offer lots more flexibility to the system.
Seeing as Google released the chromeOS, why couldn't the android devs have a crack, I don't know, just rambling on. Let me know what you think below and get a few ideas rolling
Click to expand...
Click to collapse
There is android x86 already. it works well. if I'm right is android having a cursor and everything. its just hidden.
Windows 8 contains Windows Phone like Elements Yes.
and iOS on iDevices is like a ripped version of MAC OSX.
As you might have seen. Intel and Google are making phones together now.
With an x86 Intel Atom CPU If I'm right. also will ICS Have 32Bit Support.
Haha about 10 minutes after posting this just found the x86 version, will have a look at it, see what can be done with it and just play
Follow this guide=> http://www.androidsim.net/2011/08/how-to-37-install-android-on-virtual.html
WiFi works also if you know how to set it up
the x86 version of Android is still fall off to be use-able
it is fund, but most of the apps in Market are not compatible
so you have to basically port all the apps that you want to use to run on a x86 architecture instead of ARM architecture
Does anyone have a publicly accessible EBS snapshot of android repository for cyanogenmod to start off from. It seems much better than each individual cloning from main github repositories each time. One could then just create EBS volume from same and start using immediately.
Is there any loophole to doing this and why this would not be a good way to go (besides needing to get updates from repository as it becomes stale)
Hey!
There has been a change for the new saucy releases:
In the original porting guide, we had Android as the main OS, having Ubuntu separated in a container. We had that as our first solution as it's easier to just boot Android and bootstrap Ubuntu once Android is up and running (which was a base requirement for Touch). This architecture was traditionally called 'unflipped', and it's part of the raring and first saucy images we produced.
As we continued developing the platform, more issues we found with such architecture, making it harder to improve the quality for the Ubuntu side (ueventd x udev, full control of the services, upgradability of the compat layer, etc). So to be able to further improve the Touch images, we decided to flip the systems, making Ubuntu as the main host, and separating Android in a container, getting us to what we call 'flipped' images.
Click to expand...
Click to collapse
wiki.ubuntu.com/Touch/Porting
So it seems like just few of the ports are working at the moment! Help is needed to port the new images again.
I ask myself if i'm able to make a new port for the Samsung Galaxy Tab 2 7.0 (3110). How difficult is it?
Greetings,
jochenh
One of the things that I have been feeling is that the custom ROM community is growing at very high rate.
Going by the stats counters of various ROMs, we can peg CM, AOKP and Paranoid at 8mil, 4mil and 2mil each. There is also 1mil users of the mashup PAC-Rom.
Considering Omni is a huge project, this will race up to few millions soon. With a diaspora of 15-20 million users out there, we pretty obviously have a niche market of apps for these custom ROMs out there in the wild. In fact there are a lot of apps which are made specifically for custom ROMs.
For people who want to develop apps for these devices though, they are constrained to work with the AOSP SDK. But the custom ROM community has over the years made the the Settings and all Provider databases run on steroids with huge additions to them which can be brilliantly used to make more powerful apps.
Building an the SDK is in fact trivial
Code:
. build/envsetup.sh
make -j8 PRODUCT-sdk-sdk dist
or another way is
Code:
. build/envsetup.sh
lunch mako-userdebug
make -j8 sdk
The guys over there at Replicant already do make their own SDK with every release they make. I personally feel since at omni we are doing a great job of supportting so many devices, so many features and doing it in a well maintained way, we definitely should have our own SDK too.
I am a device maintainer at AOKP, and currently I am working on creating AOKP SDK too. (It does need pruning of the whole source a lot. Since the sdk building process validates the existence of each PRODUCT_PACKAGES call and does not ignore javadocs warnings)
http://goo.im/devs/kxp/android.jar
This here is a modified android.jar that can be replaced at sdk.dir/platforms/android-18/android.jar to support building apps using AOKP's custom variables and APIs.
Also such a venture helps building and testing of ad-hoc packages like AOKP's ROMControl or omni's OmniGears on studio/eclipse.
Sounds awesome
So what would be the effect in daily omni dev?
Are there things we should consider to make creating an SDK
as easy as possible?
maxwen said:
Sounds awesome
So what would be the effect in daily omni dev?
Are there things we should consider to make creating an SDK
as easy as possible?
Click to expand...
Click to collapse
I do not have a local copy of the omni source to be honest
I will sync up omni this weekend and start off with this. Will see what problems I face, and what can be done to keep the sdk always buildable.
SDK can be built out of pure AOSP source usually always.
Modified sources like that of a custom ROM often hacks with the build system (things like BUILD_PREBUILT and overriding LOCAL_MODULE etc as you know) which makes building sdk off the source of a custom ROM not that straight forward. right now i am in fact fighting with the AOKP source and trying to figure out what are the various things that need fixings.
Also in the framework packages, presence of lint warnings and other non-standard '@modifiers' like for eg. @hid makes sdk unhappy.
Replicant is an excellent examply of an Android fork that is always buildable for both devices as well as for the sdk.
As far as release cycle is considered, we can do that something like once a month or so ? The fully built zip of the sdk is ~350mb usually.
maxwen said:
Sounds awesome
So what would be the effect in daily omni dev?
Are there things we should consider to make creating an SDK
as easy as possible?
Click to expand...
Click to collapse
I do not have a local copy of the omni source to be honest
I will sync up omni this weekend and start off with this. Will see what problems I face, and what can be done to keep the sdk always buildable.
SDK can be built out of pure AOSP source usually always.
Modified sources like that of a custom ROM often hacks with the build system (things like BUILD_PREBUILT and overriding LOCAL_MODULE etc as you know) which makes building sdk off the source of a custom ROM not that straight forward. right now i am in fact fighting with the AOKP source and trying to figure out what are the various things that need fixings.
Also in the framework packages, presence of lint warnings and other non-standard '@modifiers' like for eg. @hid makes sdk unhappy.
Replicant is an excellent examply of an Android fork that is always buildable for both devices as well as for the sdk.
As far as release cycle is considered, we can do that something like once a month or so ? The fully built zip of the sdk is ~350mb usually.
Thanks for the tip! This is actually really nice.
We might build one as part of nightlies, that could come in handy. One thing to remember though is that the APIs we add to framework aren't meant to be used by apps directly as they are highly versatile and likely to change from day to day. We also enforce permission checks on everything we do to avoid any sneaky app.
XpLoDWilD said:
Thanks for the tip! This is actually really nice.
We might build one as part of nightlies, that could come in handy. One thing to remember though is that the APIs we add to framework aren't meant to be used by apps directly as they are highly versatile and likely to change from day to day. We also enforce permission checks on everything we do to avoid any sneaky app.
Click to expand...
Click to collapse
@XpLoDWilD
The @hide identifier is there precisely for the same reason
API's that should not be generated as stubs for android.jar should be under @hide
AOSP itself used @hide to keep some api's hidden which is not supposed to be used the by the casual app developer. (for example most provider apis are hidden only in sdk)
So if there is something that is REALLY volatile or something that should not be exposed into SDK (hacked up stuff ), they can be taken of using @hide
championswimmer said:
@XpLoDWilD
The @hide identifier is there precisely for the same reason
API's that should not be generated as stubs for android.jar should be under @hide
AOSP itself used @hide to keep some api's hidden which is not supposed to be used the by the casual app developer. (for example most provider apis are hidden only in sdk)
So if there is something that is REALLY volatile or something that should not be exposed into SDK (hacked up stuff ), they can be taken of using @hide
Click to expand...
Click to collapse
Which, so far, has usually been a case of "@hide everything" for most custom firmwares so as not to cause compatibility issues.
Changing this would require some pretty serious thought and would need to be done very carefully.
Entropy512 said:
Which, so far, has usually been a case of @hide everything" for most custom firmwares so as not to cause compatibility issues.
Changing this would require some pretty serious thought and would need to be done very carefully.
Click to expand...
Click to collapse
Okay as far as providing regularly updated APIs to app developers is concerned that would involve some thing like this
lunch a buildable device (full or sdk-eng will also do, or just simple lunch omni_mako-userdebug)
Code:
mka core; mka framework;
the following files
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes.jar
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/core_intermediates/classes.jar
(preferably renamed to core.jar and framework.jar) can be released then.
These, if added to external libraries in studio/eclipse (and has to be put higher in order of inclusion than android.jar from the sdk) can allow people to work using custom-added APIs of omni.
P.S. These libraries have stubs of @hide methods too. The @hide quantifier is not respected, and all APIs are exposed.
Entropy512 said:
Which, so far, has usually been a case of @hide everything" for most custom firmwares so as not to cause compatibility issues.
Changing this would require some pretty serious thought and would need to be done very carefully.
Click to expand...
Click to collapse
Okay as far as providing regularly updated APIs to app developers is concerned that would involve some thing like this
lunch a buildable device (full or sdk-eng will also do, or just simple lunch omni_mako-userdebug)
Code:
mka core; mka framework;
the following files
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes.jar
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/core_intermediates/classes.jar
(preferably renamed to core.jar and framework.jar) can be released then.
These, if added to external libraries in studio/eclipse (and has to be put higher in order of inclusion than android.jar from the sdk) can allow people to work using custom-added APIs of omni.
P.S. These libraries have stubs of @hide methods too. The @hide quantifier is not respected, and all APIs are exposed.
hacked this up
http://gerrit.aokp.co/#/c/14129/
anyone can feel free to port this for omni too. should be a matter of just changing the CUSTOM_NAME variable.
I'm trying to understand modules in Android Studio 1.0.2. How they are configured, edited and stored.
It's easy enough to create a new module (File->New Module) and the information gets stored in the module's iml file (e.g., app.iml).
However the documentation regarding about editing a module (https://www.jetbrains.com/idea/help/modules.html) seem to be out-of-date and I don't understand if/how facets are used (and/or are applied).
Can modules be edited in the UI?
Are facets still used in this version of Android Studio (1.0.2) and, if so, how are they viewed/edited?
I'm new to Android Studio so that may be part of the problem -- e.g., I'm not familiar with modules and facets in the earlier implementations.
Thanks!
Barry
-----------
Update:
-----------
From IntelliJ Support:
This description is for IDEA projects. AS doesn't have facet (it uses only one facet - Android).
Android Studio is based on IDEA core code, but it is developed by Google.
I'm still not sure how modules may or may not be pertinent for Android Studio, but apparently facets aren't (other in the degenerate case mentioned above) and it doesn't appear that there is any current documentation that is specific to Android Studio (at least, not yet -- hopefully Google is working on some (?!)).
Closing this out.