Database Develop

[SDK] Omni-SDK : An SDK of Omni ROM with all Omni APIs added to default Android ones

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.

[ROM] [Project ] Pure AOSP 5.0.2_plus Google Updates (2/1/2015) Mako Beta

The idea behind this project is to compile a Pure AOSP ROM. The difference is I have been little by little including and testing new commits added to the for the most part unstable staging master branch code from Google AOSP that has not yet been tagged for a future Lollipop update., hence the reason for 5.0.2_Plus name. The only change added to the code that was not committed first by Google is that the ZIP can be flashed in TWRP without replacing TWRP with the Stock Recovery and that is it. At the moment because of limited testing as I do not own a Nexus 4 and all changes have been tested on the Nexus 5 felt untill a few return performance reports best to call this a beta version. With that said the same changes have made some improvments and fixed a few issues experienced by Nexus 5 users using the oficial 5.0.1 update or compiled from the AOSP android-5.0.2_r1 branch. So if start receiving comments that all has been well on the Mako build or see say 100 download without a complaint reported will remove the beta tag. I suspect this will be the case as the commits are not device related.
I honestly started the project for the Nexus 5 with the idea that maybe as a community a few developers could help work on the project so everyone had an updated version of the latest release version that included the latest fixes and had not intended on compiling for the Nexus 4. After my second release another XDA member had asked if it would be possible to make a Nexus 4 port for a friend. At that point as there had been little interest in the project by other Nexus 5 Developers I would post the Mako ota package I compiled for the user who had asked for one. I also have my own Starship Rom and am part of a new developer team so again was meant as a community project and not intended to be released as my Rom or really even released at all with the intention of being a resource for other developers to either use as the base of whatever new AOSP Rom they may intend on developing or selectively picking pieces or fixes. So going with the same idea after compiling the asked for Mako version thought why just limit the idea to just the Nexus 5 as all Nexus devices share the same code from AOSP with exception of needing to add a different set of propriety vendor blobs and choosing a different lunch command for building. So the same goes as intended for the Nexus 5. If any Nexus 4 developers would be interested in joining in on the project Just let me know and I will grant full access to the Github account and create a new branch so we can test and insure the master branch is always %100 stable if it is going to be used by other Nexus developers..
A few examples of the commits that have been added.
https://github.com/Android-AOSP/And...mmit/20063610490eabc91db5ef13a550ecbdcdc6dc1a
https://github.com/Android-AOSP/And...mmit/16c0cfd5920c6d09824d13b7ee94436de87b37e3
https://github.com/Android-AOSP/And...mmit/b9e7a844fc751b9fdda7d452dee361f15815199b
https://github.com/Android-AOSP/And...mmit/18cca2773e4f3890e2ff9ca416400d48f62b98f5
https://github.com/Android-AOSP/And...mmit/a05556633ae5a6d1db164597b93f8b6cbbdf2608
https://github.com/Android-AOSP/And...mmit/e6beb1369165f97a4df24a1d1966c41e392c44e7
https://github.com/Android-AOSP/And...mmit/be42994b5a42914071adddfd5d989950e8e47bd9
https://github.com/Android-AOSP/And...mmit/0c89e1b9395093f71cf73508553d5e4058093ec0
https://github.com/Android-AOSP/And...mmit/4c53a7872b1f37ec184801f16d39584ca3b9bcce
https://github.com/Android-AOSP/And...mmit/9d2f14442f2e1d1507dbdc6cc7b9348513a907f9
https://github.com/Android-AOSP/And...mmit/905c6e72ecdc6e170744649b78e8fbb919f71efd
https://github.com/Android-AOSP/And...mmit/1a96e2b079e8007fe965bd30cd02cb191a613510
https://github.com/Android-AOSP/And...mmit/4fcbf285db7f9e20795783b676963d42499dbd64
https://github.com/Android-AOSP/Android-AOSP_bionic/commit/eaf5aa7d22bd2f6b2eae4c81a60950f89e2d7df4
https://github.com/Android-AOSP/And...mmit/74574e8aa5a2de32e10364fd2f495023fff2a267
https://github.com/Android-AOSP/Android-AOSP_build/commit/49657b7a459ee90b3635bef989f8f9728d564068
https://github.com/Android-AOSP/Android-AOSP_build/commit/1df3707a04651966ca17796f321d23ab3ed6ed2e
https://github.com/Android-AOSP/And...mmit/6fe9c73738e9da0192971576d120802d4c094556
https://github.com/Android-AOSP/And...mmit/44c1c3235d29095c4d987d19155c7260d1a33e0f
https://github.com/Android-AOSP/And...mmit/33baf53861712c3f84606a017943e36bdc680b50
https://github.com/Android-AOSP/And...mmit/a975a08cfb30ad6b2994647c0c6f09e2abd20e28
https://github.com/Android-AOSP/external_protobuf/commit/1a96e2b079e8007fe965bd30cd02cb191a613510
https://github.com/Android-AOSP/external_protobuf/commit/4fcbf285db7f9e20795783b676963d42499dbd64
https://github.com/Android-AOSP/frameworks_base/commit/cc50afe3bdcc3adfa0f4121bf461996996e69a3e
https://github.com/Android-AOSP/frameworks_base/commit/1be740dd60f4d95e1f9ac4aac7e4d6148e3b2dd1
https://github.com/Android-AOSP/frameworks_base/commit/1cca2282dc9a3b7ecc08729af201923842ddfc86
https://github.com/Android-AOSP/frameworks_base/commit/7db1192e72b45111556631dba125a635edff3235
https://github.com/Android-AOSP/frameworks_base/commit/b29136581cc3181e59193e0b6448f0c3f5990081
https://github.com/Android-AOSP/build/commit/de655233a4308340fc71490e86fd0f218cc7fec4
https://github.com/Android-AOSP/build/commit/ab6f841841a0930c7e178a949ada39152e24540f
https://github.com/Android-AOSP/hardware_libhardware/commit/9ede7f730bca338cd3ccad8962e253f28ae17976
https://github.com/Android-AOSP/hardware_libhardware/commit/d4f431fec4136f6eeee919ac3190762fba832942
https://github.com/Android-AOSP/hardware_libhardware/commit/898bcd96e3d80e99d9200cceb4af754bae6d5f4a
https://github.com/Android-AOSP/bionic/commit/d90f39af35c1f2a9972198f92e803e3ca73ac910
Downloads
Download Rom
aosp_mako-ota-ota-5.0.2_plus_r2.0_test.zip.zip - 184.51 MB
aosp_mako-ota-ota-5.0.2_plus_r1.0_test.zip - 184.52 MB
PA-Gapps
http://forum.xda-developers.com/par...apps-official-to-date-pa-google-apps-t2943900
So far I have been using the "Mini Modular package" for testing without any issues.
Root
Root is optional but recommend SuperSU
http://forum.xda-developers.com/showthread.php?t=1538053
Have had version 2.37 in storage and had been using without issue but updated to 2,40 with last test without any issues. What can I say Im lazy that way so unless having an issue just used what works but figured most would grab the latest so thought it best to give it a test before posting.
Kernel is %100 Stock but going with past experience if mrg666 has a Kernel availible for your device it should be the Kernel you are using.
Mirage Kernel for Stock Nexus 4
http://forum.xda-developers.com/nex...el-mirage-nexus-4-stock-rom-06-04-14-t2485368
Change Log 5.0.2_plus_r2
Removed the below commit "Add ip6-localhost to /system/etc/hosts."
https://github.com/android/platform_system_core/commit/25147416bb105914c3cdf8fd65ca7cc20dae0f3e
Looks like a few apps are not fans of having an ip6 entry for localhost. Transparent Weather Widget for example can not find the device location with the enty included.
In looking for the cause of the above issue also reverted.
https://github.com/android/platform_frameworks_base/commit/e4ec09da0b4a31e23f1a19bdd1ea99e0f87cadac
Honestly reverted looking for the cause and did not remember to restore once identifying the cause. Overall is an old commit and dont think will make any difference whatsoever or would have been tagged for use in a past release so not going to bother.
As usual I am not responsible for your device and you are using anything posted in this thread at your own Risk.
This is %100 AOSP with no extra theming at all including bootanimation so no screen shots, as a Nexus User are probably aware what AOSP looks like at this point.

Don't mean to be rude, but you're still living in 2014, apparently. LOL . Classic mistake, I guess. Check the title dude.

Its cool, such a classic XDA first comment though. Could discover the holy grail and receive 15 comments about a spelling error. Adding I guess makes it that much better. Going to leave it in and see how many times your comment is over looked by someone so proud to have noticed it first, lol.

This is exactly what i have been looking for, we need more Roms like this. Thanks OP downloading now:good:

chairshot215 said:
Its cool, such a classic XDA first comment though. Could discover the holy grail and receive 15 comments about a spelling error. Adding I guess makes it that much better. Going to leave it in and see how many times your comment is over looked by someone so proud to have noticed it first, lol.
Click to expand...
Click to collapse
I hope you don't think it was something personal, man. Your title made my day. With all these exams, I've been all stressed out, and your title made reminded me of the time when I was sitting in bed with the laptop in front of me, thinking it's a long time till the exam session. LOL

Good rom so far, only thing was that data roaming was enabled by default.

dragos281993 said:
I hope you don't think it was something personal, man. Your title made my day. With all these exams, I've been all stressed out, and your title made reminded me of the time when I was sitting in bed with the laptop in front of me, thinking it's a long time till the exam session. LOL
Click to expand...
Click to collapse
I was just joking but still think it will be amusing to see how many skip past your post to point out the same. I actually test software for a living after it has been installed on an energy management diagnostic system both for new version testing and quality control before shipping and need to sign off that each system was checked out including the date. Had just recently worked on my birthday and was a highly unusually busy day but ended up signing off the date as 1976 (my birth year) on about forty systems. What is even more humorous is the amount of complaints from technicians who thought they received a system using a Nexus 7, now 9 for use as a portable User interface believed they had received software that had not been checked out since 1976. With that said most installers come from an HVAC technical school background and still use AOL as their contact email address. Lol!

nibla101 said:
Good rom so far, only thing was that data roaming was enabled by default.
Click to expand...
Click to collapse
Will look into that I'm happy to know it is working out. I basically just took my N5 source added the Mako vendor blobs and compiled using a different lunch command. Will go back and see if data roaming being enabled by default is a result of my updates or is set in general aosp 5.0.2 after work. Even though intention is keeping as pure as can be should still be looked at.
Think it would be nice if we could get a few devs together from across the current Nexus devices lineup and do our best to keep an aosp Rom available adding in the latest updates and bug fixes into the most current release for all Nexus devices. Not just for users but for other devs to use in their own aosp based work. Beleive if we could get something like that going would be pretty sweet and not all that time consuming. Still lots of updates added by Google devs every day. Some a bit more complicated then what I have done that a small group could easily bang out and test. Everything comes from the Master aosp branch that can get messy with constant new commits around the clock but think if selective in adding into latest release could be a beneficial project. So using my phrase of the week with that said I am going to build and post a version for all the Nexus devices in an attempt at gaining interest in the project. Again with that said I am torn for tonight as can try producing thr first N5 version that is sprint compatible or build for my Nexus 9. I am very much looking forwored to trying it out with jusst Simple ol aosp but at the same time feal bad for the Nexus 5 Sprint users who are all stuck on stock because other Roms are missing the aditional files added in for the radio to work. Decitions, decitions, decitions.

chairshot215 said:
I was just joking but still think it will be amusing to see how many skip past your post to point out the same. I actually test software for a living after it has been installed on an energy management diagnostic system both for new version testing and quality control before shipping and need to sign off that each system was checked out including the date. Had just recently worked on my birthday and was a highly unusually busy day but ended up signing off the date as 1976 (my birth year) on about forty systems. What is even more humorous is the amount of complaints from technicians who thought they received a system using a Nexus 7, now 9 for use as a portable User interface believed they had received software that had not been checked out since 1976. With that said most installers come from an HVAC technical school background and still use AOL as their contact email address. Lol!
Click to expand...
Click to collapse
LMAO. That was funny

flashed yesterday with nothing to complain until now
thanks for this build
edit: found first bug (maybe)
whle setting Chronus Weather and also Transparent Clock Widget
the phone couldn't find it's location.
Pop up on the screen stated....
"Cannot retrieve location!"
Network geolocation is disabled
Set a custom location or enable location
already try High Accuracy, Battery saving and Device only but it never show my location
the widget always appear with "Loading weather data"
If i choose Battery saving then Google Location Reporting will turn grey and not clickable, other two option made it clickable again but still my location show "Loading weather data"
maybe someone are having this too?
how to fix it please?
thank you very much

groovepeppy said:
flashed yesterday with nothing to complain until now
thanks for this build
edit: found first bug (maybe)
whle setting Chronus Weather and also Transparent Clock Widget
the phone couldn't find it's location.
Pop up on the screen stated....
"Cannot retrieve location!"
Network geolocation is disabled
Set a custom location or enable location
already try High Accuracy, Battery saving and Device only but it never show my location
the widget always appear with "Loading weather data"
If i choose Battery saving then Google Location Reporting will turn grey and not clickable, other two option made it clickable again but still my location show "Loading weather data"
maybe someone are having this too?
how to fix it please?
thank you very much
Click to expand...
Click to collapse
Think I got the fix and am compiling now. Hopfully have up by tonight if not morning. I am on the N5 though and have no issue with beatifull widgets finding my location or maps with navigation working which is my goto test apps along with GPS test. After reading your post tried Transparent Clock Widget and the app was not able to find my location. I did manage to fix this on my N5 so am rebuilding for Mako using the same source. Now have all the Mako Vendor proprietary blobs set up in vendor so can build either Hammerhead or Mako depending on lunch command. Still though will need testing on N4 as I am on the N5.

chairshot215 said:
Think I got the fix and am compiling now. Hopfully have up by tonight if not morning. I am on the N5 though and have no issue with beatifull widgets finding my location or maps with navigation working which is my goto test apps along with GPS test. After reading your post tried Transparent Clock Widget and the app was not able to find my location. I did manage to fix this on my N5 so am rebuilding for Mako using the same source. Now have all the Mako Vendor proprietary blobs set up in vendor so can build either Hammerhead or Mako depending on lunch command. Still though will need testing on N4 as I am on the N5.
Click to expand...
Click to collapse
will test it later
thank you for responding

groovepeppy said:
will test it later
thank you for responding
Click to expand...
Click to collapse
Know prob but had been unsuspectingly busy but compiling the what believe will fix the issue for the N4 and it comes down to the smallest commit.
Know prob but had been unsuspectingly busy but compiling the what believe will fix the issue for the N4 and it comes down to the smallest commit.
https://github.com/android/platform_system_core/commit/25147416bb105914c3cdf8fd65ca7cc20dae0f3e

libmmcamera_interface.so

Since at lease back in the 4.4 days of AOSP, the nexus 5 (and probably others) has had an issue with the camera when in video mode. There's a nasty green line that appears on the side of the video during playback.
It's an easy fix; just replace the file /system/lib/libmmcamera_interface.so with the one from the factory nexus image.
I have poured over the source code for this library, but I can't find out what it is that causes this anomaly nor why it is fixed in google's image, but not in the AOSP source. How can this have been an issue for so long? Am I the only one who runs self-compiled AOSP on my N5?
Anyway, does anybody have any idea what the cause is, or how to fix it in the source?

Hello!
I started searching to fix that issue this morning and i ran in to your post. Ive been building a while from aosp sources with minimal editing only, and i think this hasnt happened with 5.0.2 for me. Now that ive merged 5.1 into the source, i saw it happening again.
I checked few trusted developers vendors, blobs, etc. And i managed to make this:
https://github.com/sicknemesis/android_vendor_lge/commit/de6831773e3e083cef8d53f344f0a03f6a604268
As i write, im flashing and bootin a rom build with this commit and it seems its working correctly now.
All credits to original authors as seen in original commit! Hope this was the thing we are looking for and i see not lot of people check this Developer Discussion forum . I DO!
Gene Poole said:
Since at lease back in the 4.4 days of AOSP, the nexus 5 (and probably others) has had an issue with the camera when in video mode. There's a nasty green line that appears on the side of the video during playback.
It's an easy fix; just replace the file /system/lib/libmmcamera_interface.so with the one from the factory nexus image.
I have poured over the source code for this library, but I can't find out what it is that causes this anomaly nor why it is fixed in google's image, but not in the AOSP source. How can this have been an issue for so long? Am I the only one who runs self-compiled AOSP on my N5?
Anyway, does anybody have any idea what the cause is, or how to fix it in the source?
Click to expand...
Click to collapse

Wow, so the N5 was never intended to use the AOSP version of that library. I never checked the qcom binaries nor noticed that it was included there.
Thanks for this!

The Boot2Gecko people have a source fix for it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1117662
https://github.com/mozilla-b2g/device-hammerhead/commit/c37663f828891cf7a49451a04f3f1ce7f7e5c054

Thanks. It appears that the same lack of patch exists in the M source. I'll try it when I get a chance.

Nexus 4 & 5 security vulnerability uncovered

A Security researcher andhacker, named John Gordon,has found an easy way to bypass the security of locked smartphones running Android 5.0 and 5.1 (Build LMY48M). Many of us use various security locks on our devices like Pattern lock, PIN lock and Password lock in order to protect the privacy of our devices. However, a vulnerability could now allow anyone to take your Android smartphone (5.0 build LMY48I) with locked screen, perform a "MAGIC TRICK" and as a result crash the user interface (UI) for the password screen and gain access to your device.
The vulnerability, assigned CVE-2015-3860, has been dubbed as "Elevation of Privilege Vulnerability in Lockscreen".
How the Attack Works?
The secret behind the researcher's "MAGIC TRICK" is as follows:
Get the device and open the Emergency dialer screen. Type a long string of numbers or special characters in the input field and copy-n-paste a long string continuously till its limit exhausts.
Now, copy that large string. Open up the camera app accessible without a lock. Drag the notification bar and push the settings icon, which will show a prompt for the password.
Now, paste the earlier copied string continuously to the input field of the password, to create an even larger string.
Come back to camera and divert yourself towards clicking pictures or increasing/decreasing the volume button with simultaneously tapping the password input field containing the large string in multiple places.
All this is done to make the camera app crash. Further, you will notice the soft buttons (home and back button) at the bottom of the screen will disappear, which is an indication that will enable the app to crash.
At this time, stop your actions and wait for the camera app to become unresponsive.
After a moment, the app will crash and get you to the Home Screen of the device with all the encrypted and unencrypted data.
Now without wasting time go to Settings > Developer Options > Enable USB Debugging and control the device by installing the Android Debug Bridge (ADB) utility.
In addition to this, if we notice the number of users with Android 5.0 and 5.1 with hardware compatibility as Nexus 4 and software installed as Google factory image - occam 5.1.1 (LMY47V) are less.
Therefore, the risk associated will affect those users only.
Furthermore, for those users we have a good news that is - the patch has released for the vulnerability and is made public by Google.
My question is, will it also affect other L users???

First off:
That text formatting,</thread> also, this will affect anyone running Roms with pretty much unaltered SystemUI based on 5.1.1_r8 (or lower)
Roms that alter heavily SystemUI (i.e samsung and lg stock roms) are unaffected. hence this issue didnt get a wide spread across news sites

opssemnik said:
First off:
That text formatting,</thread> also, this will affect anyone running Roms with pretty much unaltered SystemUI based on 5.1.1_r8 (or lower)
Roms that alter heavily SystemUI (i.e samsung and lg stock roms) are unaffected. hence this issue didnt get a wide spread across news sites
Click to expand...
Click to collapse
Thanks for informing me. But sure that WILL affect users of CyanogenMod, Cataclysm and other non-modded AOSP based ROMs.
Sent from my HTC Desire 616 dual sim using Tapatalk

MSF Jarvis said:
Thanks for informing me. But sure that WILL affect users of CyanogenMod, Cataclysm and other non-modded AOSP based ROMs.
Sent from my HTC Desire 616 dual sim using Tapatalk
Click to expand...
Click to collapse
Cm has already merged r14 so its safe, cataclysm is based stock roms, so if it has a version for the lastest, then its also safe.
any rom with code base post r8 its safe, which afaik should be a lot of them.RR, rastapop,omni,cm,chroma,D.U. are the ones i remember that has the fix
if you want a deeper look, see if the rom has this fix
https://android.googlesource.com/platform/frameworks/base/+/8fba7e6

opssemnik said:
Cm has already merged r14 so its safe, cataclysm is based stock roms, so if it has a version for the lastest, then its also safe.
any rom with code base post r8 its safe, which afaik should be a lot of them.RR, rastapop,omni,cm,chroma,D.U. are the ones i remember that has the fix
if you want a deeper look, see if the rom has this fix
https://android.googlesource.com/platform/frameworks/base/+/8fba7e6
Click to expand...
Click to collapse
Whew. Now as I think, I remember my cousin's N5 getting a ~100 MB FOTA update, maybe that includes the r14 fix.
Sent from my HTC Desire 616 dual sim using Tapatalk

Mod Edit
Thread Closed at OP request
ronnie498
Senior Moderator

(DEV-ONLY) discussion about implementing fingerprint when compiling from source code

This thread is so more information about our fingerprint issue when building from source code can reach more devs and enable them to start off without having to research any and all the information that we already have.
The main goal is to share what each one of us knows so far and discuss what may work and won't work.
Share our ideas and thoughts on the subject.
First question is
how many of you still have these files in these locations after flashing source built rom?
system/vendor/lib64/hw/goodix.fingerprint.sdm845.so
system/vendor/lib/hw/goodix.fingerprint.sdm845.so
system/vendor/lib64/hw/goodix.fod.sdm845.so
system/vendor/lib/hw/goodix.fod.sdm845.so
system/vendor/lib/libgoodixfingerprintd_binder.so
system/vendor/lib64/libgoodixfingerprintd_binder.so
system/vendor/lib/[email protected]
system/vendor/lib64/[email protected]
lets start here.

Reserved

This one too

Maybe one more

I'm running the latest havoc, and these are the only fingerprint files I have

To understand the problem you have to understand how it works in the first place. The fingerprint sensor is actually working, so its not a blob issue. The issue(from what I am seeing at least) is that stock aosp source cannot differentiate between the fingerprint sensor touch vs the regular display touch. After digging through oneplus systemui you will notice that there is quite a few proprietary things in there pertaining to the touch system for fingerprint. All of which is missing from aosp source.
We currently have 2 options for getting FP working. Either OP releases the fingerprint source or someone reverse engineers the code from oneplus(like what was done with the slider).
EDIT: Since it will be asked anyway how i know its not a blob issue... If the fingerprint sensor was not working correctly Roms would not even have the fingerprint option available or it would crash on load.

me2151 said:
To understand the problem you have to understand how it works in the first place. The fingerprint sensor is actually working, so its not a blob issue. The issue(from what I am seeing at least) is that stock aosp source cannot differentiate between the fingerprint sensor touch vs the regular display touch. After digging through oneplus systemui you will notice that there is quite a few proprietary things in there pertaining to the touch system for fingerprint. All of which is missing from aosp source.
We currently have 2 options for getting FP working. Either OP releases the fingerprint source or someone reverse engineers the code from oneplus(like what was done with the slider).
EDIT: Since it will be asked anyway how i know its not a blob issue... If the fingerprint sensor was not working correctly Roms would not even have the fingerprint option available or it would crash on load.
Click to expand...
Click to collapse
Thanks for the input.
I believe we have a long road ahead but we have to start somewhere.

me2151 said:
To understand the problem you have to understand how it works in the first place. The fingerprint sensor is actually working, so its not a blob issue. The issue(from what I am seeing at least) is that stock aosp source cannot differentiate between the fingerprint sensor touch vs the regular display touch. After digging through oneplus systemui you will notice that there is quite a few proprietary things in there pertaining to the touch system for fingerprint. All of which is missing from aosp source.
We currently have 2 options for getting FP working. Either OP releases the fingerprint source or someone reverse engineers the code from oneplus(like what was done with the slider).
EDIT: Since it will be asked anyway how i know its not a blob issue... If the fingerprint sensor was not working correctly Roms would not even have the fingerprint option available or it would crash on load.
Click to expand...
Click to collapse
I'm in agreement on this. My LG G5 has a fingerprint sensor and when the battery was getting bloated it was actually lifting the power/fingerprint button off the connector. When it got bad enough the phone just stopped showing the option for the sensor because it no longer detected the presence so even if the files are there Android is smart enough to hide the option if it doesn't see a working sensor.

Yep. A lot of times when device bringup is being done if you haven't done fingerprint yet android will just not show the fingerprint options(in setup or in settings). Usually won't until it sees the fingerprint hardware actually working and connected.

me2151 said:
Yep. A lot of times when device bringup is being done if you haven't done fingerprint yet android will just not show the fingerprint options(in setup or in settings). Usually won't until it sees the fingerprint hardware actually working and connected.
Click to expand...
Click to collapse
Since you said something about the system Ui I decompiled it.
It looks like everything is in there even the green light.

twinnfamous said:
Since you said something about the system Ui I decompiled it.
It looks like everything is in there even the green light.
Click to expand...
Click to collapse
Yep. Even the code for the face unlock is in there.

me2151 said:
Yep. Even the code for the face unlock is in there.
Click to expand...
Click to collapse
So in a sense all it takes is someone capable enough to take the decompiled files and modify the system ui apk source code in the rom they are building?
I have the files if anybody needs them there on afh

me2151 said:
Yep. Even the code for the face unlock is in there.
Click to expand...
Click to collapse
So in a sense all it takes is someone capable enough to take the decompiled files and modify the system ui apk source code in the rom they are building?
I have the files if anybody needs them there on afh

twinnfamous said:
So in a sense all it takes is someone capable enough to take the decompiled files and modify the system ui apk source code in the rom they are building?
I have the files if anybody needs them there on afh
Click to expand...
Click to collapse
Yes and no. The main problem is the fact that the code is proprietary. If you release it as is or share it as is you could face legal action from one plus. It has to be completely rewritten. Hence the reverse engineering part. But the yes to it is it just needs someone capable.

few Devs have the code already ..
But unfortunately can't post a rom with fingerprint fix , cause is proprietary or get DMCA'd
So they're working on a fix that's open source to share it...

cultofluna said:
few Devs have the code already ..
But unfortunately can't post a rom with fingerprint fix , cause is proprietary or get DMCA'd
So they're working on a fix that's open source to share it...
Click to expand...
Click to collapse
Did any dev even got the fingerprint to work?

Electric1447 said:
Did any dev even got the fingerprint to work?
Click to expand...
Click to collapse
Not yet

cultofluna said:
few Devs have the code already ..
But unfortunately can't post a rom with fingerprint fix , cause is proprietary or get DMCA'd
So they're working on a fix that's open source to share it...
Click to expand...
Click to collapse
Systemui in source built roms have fingerprint files in them. May be easier if someone running a open-source rom pulls the apk and decompiles it then edit and put back in device to test? Just a thought but I've been going through everything the only thing I seen so far we need to add is the fingerprint location values and add files to show on screen.
We shouldn't have to rewrite completely as most files are all ready open source and in systemui of aosp source code.
I've been caught up in building a source code rom and trying things but there are far more people that have more experience than I do at the .apk part.
Hope any of this helps.

twinnfamous said:
Systemui in source built roms have fingerprint files in them. May be easier if someone running a open-source rom pulls the apk and decompiles it then edit and put back in device to test? Just a thought but I've been going through everything the only thing I seen so far we need to add is the fingerprint location values and add files to show on screen.
We shouldn't have to rewrite completely as most files are all ready open source and in systemui of aosp source code.
I've been caught up in building a source code rom and trying things but there are far more people that have more experience than I do at the .apk part.
Hope any of this helps.
Click to expand...
Click to collapse
This what I thought someone should do. Even if someone uses copyrighted code he could still test and see if it works.

I want to continue research on this topic. I'll take a look at systemui and framework-res and try to just test if I can get OP code working on AOSP. Then I'll go from there.
Edit: From a quick glance, FP code seems to be also present in framework-res, so that likely will also need to be worked on.